I work at a small dev team (~8), that is part of a bigger dev team (~35). We were undergoing a period where we were having some trouble planning our next sprint, and also we wanted to look at ways to better our productivity even more, compared to other teams.

So I tried a retrospective method which worked well for us at that time, and it’s a combination of some methods I read about at: www.funretrospectives.com.

The team

My team is composed of devs (like myself), testers and a business analyst, which serves as our intermediate to the head product manager. Despite that, we work in small and self-managed teams. This works very well for us, as we can decide for ourselves what is the most comfortable way to work in our case.

As I’ve recently started to gain interest in agile, I was appointed an additional role as a facilitator for my team. This role is simply about being responsible for evaluating the team’s development process and continuously improving it.

The need

As such, I was also responsible for the retrospectives we did every two weeks, so this time I needed a method to:

  1. Identify our current problems more accurately
  2. Define specific actions to be done to solve those problems

Hot air baloon

I used the hot air baloon method to raise some actions we did in the past iteration, that we felt boosted the team’s performance. Some examples of that were:

  • We had practiced pair programming at one point, to solve a difficult problem
  • We had payed more attention to resolving technical debt (part of a continuous improvement thinking we have here)

And then we raised some questions that we felt got in our way to productivity. For instance:

  • Planning too many tasks for the iteration, forgetting we had already some work in the In dev lane when we entered the meeting
  • Legacy code caused us to lose time digging around lines of code to understand a problem

I was glad to notice there were many cases of duplicated issue tickets during this process. That means the team is self-aware and syncronized.

It only took us 10 minutes to raise all the issues. Then we grouped them between two categories: tech-related and team-related.

Tech-related were things dealing directly with productivity and technical issues, and team-related were about communication and planning.

Who, what, when

The second need was satisfied by using the Who, What, When idea, where we specified what actions to be taken about the problems, who would be responsible for each and by what date we would be expecting a resolution.

Three lanes in the whiteboard were enough to wrap up the retrospective, and everyone knew what to do next and what their role would be.

Sometimes you have to extract the best thing out of many ideas to get to the one that works best for you, your team and your environment. That’s part of being agile in a nutshell.