As I wrote just a few weeks ago in my blogpost going agile with scrum: the taskboard, a very important aspect of being a teamlead, or a ‘manager’ of a team is to be able to monitor the work so that you are able to look back afterwards.
So what does monitoring the work actually mean? Well it is not about letting your team members write their daily hour sheets. That’s just a boring exercise for knowledge workers and does not have any positive effect at all, especially if no feedback whatsoever is returned to the team for the careful registration of those hours.
Monitoring is useful only when the team can look back and have an effective retrospective. This will get the team far more self aware. Before having a retrospective it is important to know a few things about how to have such a meeting. A very good book about this is from Esther Derby and Diana Larsen:
I highly recommend reading it. It tells you how to conduct a retrospective. Set aside enough time for the meeting; get out of the workplace so that you can’t get distracted by the frantic software factory. The book is pact with practical advice and has a full set of examples activities that can be done during a retrospective meeting.
The retrospective….
To summarize, a retrospective has a few stages.
1) Setting the stage
2) Gathering data
3) Generate insights
4) Decide what to do
5) Close the retrospective
In our first retrospective I first set the stage by shortly explaining what the goal of a retrospective is. This can stir some emotions because of people being unclear about the goal; don’t get distracted, repeat the goals and continue 😉
We then used the timeline activity to get a factual look back at what we did during the four weeks since we started an iteration of work. This was to gather the factual data.
a simple timeline, as an example
And because that timeline showed us how much we were actually busy with, namely lots of stuff, trying to handle multiple iterations at the same time as well as fire-fighting daily questions, it quickly made the team aware of the facts. It was hard to be focused as a team on one iteration when the other iterations were not finished yet! It’s hard to deliver quality when you have to jump from creating more features in the current iteration to helping testers getting earlier features out to production.
A good way to get an overview of the feelings was to set-up the next activity. We simply set-up a new flip over chart, divided that into two columns reading ‘glad’ on the left side and ‘mad/sad’ on the right.
What was the team (not) happy about?
The timeline chart -with lots of data scribbled on it- was hanging next to the new flip over for the generate insights activity.
This generated the insights into the feelings we, as a team, were having about looking back at the particular time frame. Starting the activity as a ‘brainstorm activity‘ (see chapter 6.1 of the book) challenging the team to come up with 50 ideas or positive/negative feelings we soon got the flip chart filled with ideas plus emotions about the work that we were doing. This led us to the next stage in the retrospective: Decide what to do. The activity: define some reachable actions.
We did not aim too high with our actions. I pressed that the first actions we wrote down had to be achievable and take away a daily burden that the team felt. The simple actions we took were to
help testers out and improve the standup meeting. Testers need to know what and how to test when issues are assigned to them. Also, we wanted to have a more effective and shorter standup meeting in the morning. This was because our morning meetings were going too far into the details and therefore took too long. The rules we made up for the team were that everybody should answer (only) the three usual standard questions of the daily-scrum, and keep within one minute each.
Retrospective activity: decide what to do.
So, the team decided that if you wanted to say more that is still possible, but only after everybody got to have its turn and the standup meeting was finished when everybody had her say. This means people are free to wander off if the detailed discussions are not relevant for their work that day.
Second thing related to the standup is we decided was that we realised that we need a better room for our taskboard where we were having the daily scrums. The taskboard is currently in a separate room where other people are doing their work. We want our board to be in our development-room, one way or another.
We did not forget the last stage of the retrospective: Closing. Everybody mentioned the ‘return on time invested’ and each individually said it was time very well spent: it’s good that as a team we took time to look back, spent some time on some frustrations and got happiness out of the things that are working well which we cherish, so to speak, like the time we invested in pair programming. In all, a succesfull retrospective it was!
……Seeing the patterns
Of course, the team saw much more that should be achieved than the actions that we choose in the decide what to do part of the retrospective. Some of the actions that are defined are the needs of the team. And those needs can be outside of the teams control. Here is where the teamleads and management gets into play. To get the team work at its full potential we need to get all burdens and obstacles out of the way and have the organisation communicate to the team in a clear way what needs to be the focus for the next iteration.
One of the authors of Agile Retrospectives: Making Good Teams Great
[…] a critical role for middle managers and working across the organization to make sure that the organizational systems are working. Instead of just looking down at what my individual team needs and looking up to see what my manager needs they need to be looking across the organization looking to the right and left of them and understanding how work flows through the organization and how to create and adjust those systems so the work flows smoothly to the team and the policies and procedures and structures in the company enable the team to self-organize […]
see full interview on InfoQ
This of course is good stuff. As a teamlead / manager of the developmentteam one of the concrete ways to -at least try- to get more structure in the workflow, and thus iterations, is to be able to have clear ways of iterations, a backlog and make sure that when a new iteration can start, it’s clear what the team should work on. This means that before an iteration even starts we need to:
– Ask upfront priorities to stakeholders
That’s more easily said than done. Especially if the organisation switches its mind now and than about what is the most important thing to get delivered 😉 Anyway, whatever the priority that comes out, the team always needs to have clear goals by having:
– An organised backlog, keeping a wishlist of requested features and enhancements
– Up-to-date priorities: Ask the stakeholders to check and sort the backlog scenario’s based on priority, on a regular basis
– Feedback from delivered scenario’s: To keep spirit high the team needs to be energized by stakeholders on what was delivered.
And of course the team itself also wants to have a say on those priority lists; especially about what scenario’s in the backlog are easy to implement and which scenario’s aren’t or are seen as a waste of effort. A developmentteam needs to be part of the results; that’s what inspires and will come back as positive energy in retrospectives. Recognize a pattern already? 😉