Recently Luis Goncalves published a blog post about retrospective smells. It’s a good article and worth a look and you can find it here. Although the article in general is interesting and I do agree with most of it, I do disagree about one point being an antipattern: “Line Managers want to attend”.
He quite logically deduces that although they might very well attend on good intentions, their participation can interfere with team member’s confidence in raising issues and talking freely about topics at hand. Leaving manager’s out of retros seems like a proper cure, but I get the feeling we are here treating a symptom to a way bigger underlying issue – lack of trust.
It’s quite common that team members and employees in general are careful when manager’s around, especially if they are new to the team or the company, but instead teaching people to avoid direct communication it should be fostered. It takes time and effort to build that trust, but eventually team should feel comfortable talking about real issues directly and openly with the management. Properly facilitated retrospective is the perfect place to practice and train this open and direct communication.
This trust will eventually work both ways and it’s extremely important for transparency and openness in the company culture. Still it will take time and there is no benefit in trying to force it so I would actually recommend doing retros sometimes with and sometimes without management. Depending how well it goes and start bringing the management in more and more if the trust starts to build up.
There is another benefit in having management present and namely they are more likely to support and help solve the issues if they understand “why” something should be done instead of just “what”. People can bring their whole expertise and experience to the table only if they have proper understanding of the situation and participating in retros can really help in achieving that. People (includes managers!) commit to certain tasks or plans a lot better if they take part in designing them or better yet: let them be part of the solution.
The retrospective is the place for process improvements and probably the most important improvement you could ever achieve is is fixing the communication gap between the team and the management.
Finally I’d like to point out that most of the retrospectives I have facilitated had a manager attending and it never seemed to be a problem. Maybe I’ve just been lucky, but I personally do intent to push my luck and I will keep inviting everyone to the retros.
Illustration by Martha Bárcenas
I recently had a chance to facilitate a retrospective for a fellow team at my department. That team had been through a lot of changes and the most longest serving member had been there for less than a year. So it really looked like a good time to invest a bit of time to really open the conversation channels.
I had not facilitated a proper retrospective in a long time and this was a completely new team for and I hardly knew anyone of them so I did have few concerns.
- Would everybody feel confident enough to speak up and voice their concerns?
- Would they really engage and concentrate on the topic at hand?
- Would I be able to explain the exercises properly after such a long time and in English?
To address the first concern I decided to do a safety check in form of a ESVP -vote. I also wanted to underline the purposes of the retrospective and what we wanted to achieve. I also planned to make a point about being fair / just and show the little cartoon.
For the second point I decided to write some slides to explain the exercises. I usually prefer to have as little technical devices in the room as possible and I like to make the point about leaving mobile phones and laptops aside, but this time I decided to make an exception.
Here is the plan I made for this retrospective that was scheduled to take 3 hours. Apart from the exercises I will share my time tracking and some comments how I feel it went.
1. Set the Stage
1.1. Safety check / ESVP -vote
To understand how people felt about this retro I wanted to see how comfortable they felt.
How did it go?
Luckily the results were really encouraging and only one gave an S and everyone else gave an E so I the results were really encouraging,
1.3. Unlikely Superheroes
I borrowed the idea for this exercise from one of my favorite tv-shows: whose line is it anyway. In that show comics improvise and give each other silly superhero names and then act out a scene trying to solve a silly crisis that the audience gave them. I changed it a bit and only ask each attendee to think about their role and contributions to the project and give themselves a superhero name and identify their superpower and weakness. People tend to be really good at coming up with funny metaphors and this sounded like a fun way to get the people thinking how they see themselves in the team and also identifying their own shortcomings in a relaxed and humorous manner.
How did it go?
I think it worked out quite fine and we got some pretty funny names and superpowers coming out and few laughs as well. This exercise definitely helped to create a relaxed atmosphere and we were ready to move on. In general the 1. stage took only 15 minutes.
2. Gather Information
Timeline tends to be my de facto way of gathering information of what has happened. This time planned to give the team 10 minutes to write down 5-10 events or things that each found meaningful and that had an impact on their moral or attitude towards work (each on their own, so everyone wrote their own notes). After that I would ask each one to step forward and quickly explain each note before putting it on the timeline I would sketch on the whiteboard. Apart from time axis the timeline had moral axis meaning that events that were considered positive would be higher and negative events lower.
How did it go? (time spent: 40 minutes)
In general these seems to be an instant hit. Everyone always has plenty to say and this is a great way to make everyone participate. Even the guy who had been with the team only for 2 weeks had something to say. Some even had way more than 10 tickets and as we seemed to have plenty of time, I let to put them all up.
(break, 15 min)
2.2. Identify patterns
Next I would ask the them to form small teams of 2-3 people and then to have a closer look at the timeline to identify patterns and themes that emerge. Then we would together list them on a separate walls and group and merge them to one combined list of higher abstraction level themes and topics to talk about. When it comes to timekeeping I did drop the ball. This took a lot more time than anticipated.
How did it go? (time spent: 1h 00min)
In general the small teams got underway fast and started to pick out themes and patterns. Then when we wanted to merge the list from each team the conversation really started booming. There seemed to be endless possibilities to discuss and pretty much everyone seemed to be participating.
2.3. Point voting for top 3
After all the topics were discussed we would need to pick top three for further analysis. Everyone would get 3 votes and the top 3 of topics would then be picked.
How did it go? (time spent: 10min)
Well it’s simple enough and got the job done.
3. Generate Insight
It’s a combination of 5 why’s and mind map. The idea is to create 3 teams (1 each topic) and have them analyze the reasons leading to current situation regarding the topic. The reason as many and they are not linear so what you end-up with is a mind map like graph of reasons. I still recommend following up each initial path to at least 5 whys.
How did it go? (time spent: 10min)
4. Planning Future Actions
4.1. The perfect world
This inspired by Toyota Kata and the idea is to think how things would look if they were perfect.. This exercise also concentrates on the topics chosen in earlier exercise. I find it very valuable to think where you want to go before trying to come up with steps to get there.
How did it go?
Skipped due to lack of time.
4.2. Planning game (planned duration: 20 minutes)
Ask teams to plan 2-.3 concrete steps to get slightly closer to the perfect situation in previous. In the end present the tasks to the team and take responsibility.
How did it go? (time spent: 10min)
At this point we were really stressed with time so I had to simplify and push the timelimit. In the end we did have action points for every team and we did have some pretty good ones.
I planned to write 3 questions to a white board and then ask each to write their answers on a separate note. Here are the questions:
- What did you like best in this retro?
- What did you dislike?
- On a scale from 1 to 5 (1 great – 5 horrible), how bad waste of time was it?
How did it go? (time spent: 5min)
Most seemed to want to give the orally and publically saying mostly positive things. Few actually gave me their feedback on paper. Mostly people seemed to like it and the criticism concentrated on lack of time for the planning and the poor time management.
The criticism over time management was spot on and that seems to always be an issue for me. Somehow I always get excited when the team really starts to talk about things and it’s really hard for me to stop it, especially in a case like this when I feel that this was the first time the team actually talked about non technical stuff properly. Still it would make sense to have some proper time for planning the actions to be able to validate and review them properly.
Managing and leading are two very different concepts, but many times you see terms like “manager” and “leader” used interchangeably. I personally like to define them very differently and in my opinion there is a very clear distinction.
In short “managers” are appointed and leaders emerge.
Managing refers to managing conditions and good managers create condition where leadership can naturally emerge. Some people are natural leaders and they will naturally take the lead unless their leadership skills are suppressed by management.
Leaders are very context dependent. In a software team during different development phases different people can emerge as leaders and even designing different parts of the system it might well be that the people who best understand the requirements and situation naturally take the lead.
A good manager should understand to cede control when someone else is better fit to lead. Arbitrarily holding on to power will only interfere with teams capability to perform. Ceding control requires a confidence and trust in the team.
Emerging leadership is a natural phenomena. Take a travelling flock of birds for instance. A wedge of cranes has a leader, somebody has to fly in the peak. The leader position is however circulated naturally.
The form of the wedge is fairly stable, but some other flocks change the form dramatically and peculiar forms and patterns can emerge. “When birds fly in flocks, they often arrange themselves in specific shapes or formations. Those formations take advantage of the changing wind patterns based on the number of birds in the flock and how each bird’s wings create different currents. This allows flying birds to use the surrounding air in the most energy efficient way. ” (http://birding.about.com/od/birdbehavior/a/Why-Birds-Flock.htm) Should an agile team think it’s form should stay constant.
Leadership implies followers. When it is not by authority as when manager tells his team to do something, its naturally good measure to check if the actions are agreed upon. If you have a good idea and people are willing to follow you because they agree with you, that makes you a leader.
Emerging leadership is an ongoing self organization activity by the team. Self organization is one of the fundamental agile -principles, but it’s not always understood as an ongoing process. Emerging leadership is a natural phenomena in a truly self organizing team. Agile team should be more like a flock of bird that is prepared to change forms to best benefit from the “currents” every team members skills create any given moment of time.