Why Your Retrospectives Have Become Unproductive?

Retrospectives provide teams with an opportunity to reflect. They’re an opportunity to discuss what is working and what isn’t with the goal of iterative improvement. The meetings should create a safe environment for team members to share and discuss processes and practices constructively so they could come up with actions to resolve problems or improve how the development team functions.

Yet, often this isn’t the case — retrospectives break down, become unproductive or just don’t happen at all.

Here are 3 core failings with retrospectives, along with potential causes and remedies:

1. Retrospectives That Don’t Lead to Real Change

The desire for continuous improvement is at the heart of retrospectives. The feedback gathered during the meetings should result in action items. These action items, upon completion, should deliver positive change. But if the action items aren’t completed or the true cause of problems is not identified, then the faith in the process can wane.

This can come about for a few reasons:

  • Too many action items

It’s important that you don’t try and tackle too much and fail to make real progress with any of them.

  • Items are vague or have no clear resolution

The action items you create need to be specific and have a definitive end point. Items like ‘improve test coverage’ or ‘spend more time refactoring’ lack specificity and need to be quantified. Concrete action items provide demonstrable results — allowing the team to see and feel the improvements achieved by following the process.

  • A lack of responsibility for actioning items

Often the facilitator can end up with all the issues or items are assigned to groups of people. This is a mistake — each item should have a dedicated owner who is in charge of ensuring to get it done, even if a team would be completing them.

  • Too much emphasis on technical issues

Working with tech is what we do so identifying problems about systems, servers, libraries and tooling are easy. But you need to ensure that you give just as much attention to working practices, communication, and people problems. Otherwise, these key impediments to improvement will hold you back.

Whatever the reason is, it’s important that you’re completing the action items. So prioritize them and focus on just a handful of items that you know can be done before the next retrospective. Break down larger issues so that you can begin to make progress with them too. Track items raised at previous retrospectives and review results in each session. This sense of momentum helps to build and maintain a belief in the process and fuel future improvements.

2. Retrospectives That Don’t Occur Often Enough

If retrospectives don’t happen often enough, it can cause a number of knock-on effects:

  • Too much to go over in any one retrospective

This results in meetings that fail to get to the cause of issues. Or due time isn’t spent on issues important to attendees, which can be disheartening.

So much has changed since the items were identified that the issues raised are no longer a priority. This doesn’t mean they aren’t important. More often, it just means you’re compounding them with others and you’re missing an opportunity to improve.

3. Lack of Participation in Retrospectives

This can often happen if the meetings aren’t managed effectively:

  • Sessions are long-winded

You should decide on the agenda before the meeting to avoid straying off the topic and unfocused discussion. You might want to consider time-boxing sections of the meeting. This helps to ensure discussion on one section or type of problem doesn’t consume all available time and attention, and that all areas get adequate attention.

  • Sessions have become stale

Change things up. Try removing seating for one session, so people don’t just sit back and switch off mentally. Or change the format so you aren’t just repeating the same old questions. There are plenty of different techniques: from the Starfish and 4Ls to FMEA if you decide to deep-dive on a specific issue. Or just pair off and discuss items to bring back to the group. Some people open up better in smaller groups. And one-to-one force a conversation, otherwise, things get awkward.

  • There’s a lack of trust

A lack of participation can also result from a breakdown in trust. You should only invite team members to take part. Observers, especially management, despite noble reasons for attending, should be dissuaded from doing so. It may seem to make sense to share feedback so that other teams can learn from it too. But the specifics should be kept in the room. People might not contribute if they know there will be a long-term record of it, or if attributable comments are shared. Just share the action items or areas you’re looking to improve.

  • Sessions are too negative

Retrospectives should encourage introspection and improvement. But this doesn’t mean it’s just a time to moan. It can be too easy to focus on the things that aren’t working or you failed to do. So it’s important to make an effort to highlight improvements, and not just from the last iteration but over time too.

With a few changes and a renewed commitment to the process, retrospectives can be a great way of ensuring you’re constantly improving. They can be an important part in making the working lives of your developers better and more productive.

Getting Started with Iteration Planner for Agile and Sprint Planning

Iteration Planner unlocks the power of the project management software as an Agile planning tool for software development. With it, you can combine sprints and milestones to graphically group cases into the scope of work that you’ll complete in each sprint. You can also balance the allocation of resources by dragging and dropping cases from one assignee to another. Iteration Planner is a lightweight way to plan work and manage teams using FogBugz.

Here are a few key suggestions to help you apply priorities in your projects:

  • 1–3 Minimum Viable Product
  • These are all of the cases that must be completed in order for your sprint to provide new value to the customer in the form of a usable feature.
  • Priorities 4: Hygiene
  • This is non-essential work that improves the product but is not required in order for the product or feature to be useful to a customer. Small amounts of this work are often spread throughout sprints to continue making small improvements to the product.
  • Priority 5: Incidental work
  • Don’t allow your scope to creep from a manageable size to something so huge that it couldn’t be completed in less than a decade by Steve Jobs and a host of efficiency experts. If you add something as incidental work that needs to be done during a sprint you need to subtract or deprioritize some other work that has an equivalent number of estimated hours. Keeping all your incidental cases under one priority allows you to group cases by priority and see how much time you are spending on cases that are not part of your MVP. At the end of your sprint add up the hours and determine whether or not the interrupts were a worthwhile use of your time. This discussion can be part of your retrospectives or done separately. Either way, the numbers should be useful for evaluating whether or not the work that was done during the sprint was part of the planned work.
  • Priority 6: Long-range work
  • Frequently teams are asked to take on a category of work that is not part of the MVP but does contribute to the overall plans of the organization. These tasks may be expected to take many sprints to complete and their progress needs to be tracked across multiple milestones.
  • Priority 7: Stuff we won’t do
  • It’s useful to declare this as a way of focusing the team and managing expectations about the work that will be completed in the sprint.

For Agile software development teams, Iteration Planner is a useful, graphical tool that allows you to visually manipulate the information you need for planning Sprints. With it, you can set the direction for your team’s work and monitor progress so you can deliver on your organization’s goals.

How to keep track of cases in multiple projects at once?

Life is complicated and we all accept it. While we tend to categorize the different aspects of our lives, in reality, things rarely fit neatly inside the little boxes we carve out for them.

Our work life is another major compartment and when it comes to planning, it’d be nice if a single project captured all the details we might need to organize work for a project or product and across teams, but often that’s not possible.

This meant at times, working with the Iteration Planner and Kanban boards in FogBugz could be kind of awkward. What if you maintain multiple products and each one has its own project? You’d want the “Planner” to show both at the same time, but it couldn’t. Or, what if several teams had multiple projects relating to a single product? You couldn’t plan without affecting the other teams.

Well, such things are not a problem anymore! With the cross-project planning capabilities in Iteration Planner and Kanban, you can keep track of cases in multiple projects at once.

That means you can view all cases relating to a product on one board, even if they’re in separate projects. And multiple teams can plan things without disrupting or being interrupted by others.

Here’s how it works

Site admins can create a new planner and associate it with one or more projects. Each planner may contain any global milestones and any per-project milestones for its projects. You can also optionally filter by project or area, and filtering down to multiple projects is allowed too.

For existing customers, each of their single-project planners migrated to the new versions. If you would like to add additional projects to a planner, view that planner and click “Edit Planner Settings” in the top-right, then “Add Another Project”, select additional projects and click “Save”. With that done, you can add milestones from those projects and any global milestones, and the filter columns shown will include cases from your selected list of projects.

If you use our Kanban board, the project selections for your planner also apply to each milestone when you click through to the Kanban view.

Take a look at our help site for more details. If you have any questions or feedback, please get in touch!