Agile Retrospectives as Rock Band Show

Agile Retrospectives to me are like rock shows. So really depend of the moment and really happens this way for me.

Like a rock concert depending of the moment you want to mosh or just be nice and relax or be happy and sing with the crowd.

For me software development is like music, so there are moment where things are more calm, other moments are more like a rush and other moments are just transition between moments.

So what are the moments? It`s really depend on how your team work and what you do, but lets say classical software development and see kinda of 3 big moments.

This are not phases like you might think in RUP, but are not that different ideas, i like to think this trough the music so are kind of different rhythms or moments of a single song.

So when you do the agile retrospective first of all you need to acknowledge with moment is the current one, it could be a combination of several things but it definitely will have a kinda of weather on the current moment the team lives.

The Fireman

This could be given an incident or an issue that happen or just a hunt to improve things. So if you have a team just to fix bugs or you are more focused on production bugs now you might have more focus on investigations - thats might be an smell of tech debts that are not being payed but besides that consider a moment where you are doing some stabilizations. Tweaking things or just doing a very quick fix to solve a problem that is critical.


This is when you are figuring out a solution, Could be creating something totally brand new and them is when you do more design sessions and analysis or even researchers to figure out where to go and how to the things.  Or even when you are paying tech debts and re-arch things and want improve stuff.


This is most of stuff are in place and you need to deliver stories and throughput can to place. You have the most designs in place and them its more add functionality and improvements, small enchantments them extinguish fire or think about the future.

This is not waterfall, all modes could happen on the same week, and they can go back and forth, so i1m not talking about damm pahses, i1m talking about moments you live, like you get happy, bored, unhappy and back and forth. like a song.

You need get out!

For me its very important to get out of your office. restaurants spaces, public spaces, pubs no matter what you have a great place with coffee and beers its great, People relax and they have with less fear when they get out of their day by day location. When you are out of office you tend to be less worried about people because there is less people there and its just your team and your coach, so its really great,

Acknowledge the moment of the team is a big thing, you need realize more stuff before setup your setlist. buts mostly i see some dimensions you kinda of always thinking about, or goals or concerns you never keep tracking as a coach.

The Dimensions

  1. Create a REAL Team
  2. Continuous improvements
    1. Make Sure the team learn from failures
    2. Make sure the team acknowledge whats is going on.
    3. Improve process and tools
    4. Improve Code and solutions: tests, design, arch, devops, etc...
  3. Have fun
# Creating a REAL team

This is tough and you always need to have that on spot. You will pick practices that make the team confident to say stuff to each other and listen each other and collaborate to improve whats is not going well. This is based on trust an this is built day by day, but sometimes you dont have the time or the opportunity to do it daily so at leat you force somethings to happen on that moment.

You want make sure feedbacks happens, you can start with rules and retrospectives but as lean as you get you want do all this things at daily bases and dont need to have push retrospectives to talk about whats bad on the team. I see retrospectives as trains if you lost one it will be another so we can do that with small problems that can wait. there are things that cannot wait and you should not wait them you stop the team NOW and talk about it.

# Continuous improvements

Always you need be improving everything its better do it small and slow tham nothing, The peace its not relevant its the direction that counts most. So there are moments the team has more trust and its close to be a team, them you can focus more and more in problems and things that could be improved. That could direct some choices or your practice setlist. When the team is new you need to be focus on the trust and make the team open, so closed and analytical practices wont have much value, but as the team grow you might close a little bit the practices and focus on the system thinking practices and make sure people learn and are aware and figure out solutions for things.

To make this work you need actions, you need make sure some of the things you talk you make it out of the retrospective otherwise its just a public payed complained therapy and that wont work out since agile coach are not shrinks :-) 

# Have Fun

This is very important, life its short, you want have fun, otherwise what the point to do 8hrs of your day of something you dont have fun!? So always look for new practices, find retrospective practices its not easy but as you do more and more agile coaching you start to understand the principles behind the things you do and i really advise you to create your own practices and always try to experiment things, 

I Have lots of failure practices and its important figure out why they didn't work out. But i have practices i created they work very well in my projects and people see benefits doing it. As a Agile Coach you become a cooker and all cokers as chefs they have they own very way to prepare the meal, so create your own way( i will share some of my in other posts :-) ).

So whats is the good setlist size and length? It really depends for me something between 3 and 6 hours its more them good. I always try to go between 3 to 7 practices and dont do more than that i trayed, also tried more tham 12h retrospectives and they become massive, people dont pay more attention and fun goes away. 


Popular posts from this blog

Podman in Linux

Java Agents

HMAC in Java