Blitz Retrospective

Dear Junior

One of my favourite method tools is a retrospective format I call the "Blitz Retrospective". I have used it in a lot of situation where it has been impossible to do "large" retrospectives. For example, in some situations, the teams have been very "retrospective sceptic". In other, there has been a formally appointed "scrum master" who was not very open to suggestions, so suggesting changes to his retrospectives would not achieve much. In yet other, the sprints have been so long I have not had the patience to wait a few weeks. In all these situations it has been possible to suggest, and do, a "really quick retrospective".

The "Blitz Retrospective" only takes 25 minutes, and its focus is to find *some* change the team think would improve things. The format consists of three parts: the startup, collection of ideas, and vote. 


Startup


If it is the first time, the startup is spent explaining the format so everybody feels comfortable with what will happen. I clarify that the purpose is to find one single idea of improvement that we will try out next week.

A question that always come up on purpose is why we are limited to one idea, and what happens with the rest. Well, if the timespan is only a week, it would be foolish to focus on more that one thing - it would just result in none of them being changed. 


As for the rest of the ideas that come up - they will be there in the back of peoples minds and might change things implicitly - but they will not be actively in focus. If it is not the first time, I usually quickly rehearse the procedure, but I spend the time on evaluating the last retrospective's "winning idea" - more on that later.

The startup in full should not take more than five minutes. 


Collection of Ideas


Second section is the collection of ideas. To help the team members I split a whiteboard in three sections labeled "Continue/Increase", "Start/Try", and "Quit".

First section "Continue/Increase" is for things we already do and that support our work. Second section "Start/Try" is for ideas that we think we should benefit from, but we do not do it already, at least not in any significant amount. Last section "Quit" is for things team members think we do, but should stop doing as it does not serve us well, or even harm us.

Then team members are free to write down suggestions in any of these sections. Usually, I let them write on stickies, so that they can write a short statement on the sticky and explain it briefly when they post it on the board. If a short discussion emerges, then fine. However, if it seems to turn into a debate, or risk running long, I cut it short pointing to the purpose (find one idea) and the procedure (there will be a vote later). 


I also try to convince the team to keep the suggestions very concrete and limit them to thinks they directly can effect. For example, replacing the ventilation system of the building might really improve, but selecting such improvements is just asking for failure. In other retrospective formats such ideas are really valuable, but the purpose of Blitz Retrospective is basically to get acceptance for retrospectives - and then they must make a difference. We want things we actually can do, and that we can do within a week.

The collection of ideas could take ten to fifteen minutes. On occasions when time has not been an issue, I have let it run on longer - but usually most ideas are on the board after ten minutes. 


Grooming the List of Suggestions


When getting closer to the end of collection of ideas, I take a more active role, starting talking about the stickies in the "Quit" section. 


It is extremely valuable to get the "Quit" feedback, and I really encourage people to post such suggestions. However, I am a firm believer of that you should focus on "telling the good stories", because the stories you tell (and repeat) will become part of the "team lore" and shape the atmosphere of the team work. This is the basic idea behind the organisational philosophy "Appreciative Inquiry".


So, telling "bad stories" will basically make people feel bad - but not do much good in the long run. Telling "good stories" will culture a nice team atmosphere as well as enforcing the good habits.


Therefore I take on the role as the "positivist fanatic" and try to rephrase each sticky under "Quit" into "positive" ones. For example, if a quit-note says "stop coming late to meetings", I might suggest a start-note "meetings begin exactly on time - even if people are missing".


Before throwing away the "Quit" not I ask the original poster whether the new notes have captured the original purpose. Surprisingly often there is an additional aspect I had not understood. In the "begin on time" example, the poster might say: "It is not only about starting on time, it is also that every time someone arrive (late) there is a start of chit-chat and small talk that disrupts the meeting". To capture this there will be a second note start-note "keep meeting focus when people arrive mid-meeting".

I also ask if there are some suggestion that the poster think is a duplicate of some other - if so they can have it removed. Merging two similar suggestions to one of course gives them a better chance to "win".

Still when "grooming", the board is still open for new ideas, it is just for the team members to step up, post a sticky, and present the idea.

At the end of collection of ideas there often are a load of ideas and we only have a few minutes until we shall leave the room with one selected idea: time to vote.

Voting

For the voting, I simply rearrange the stickies and let each team member give three suggestions one vote each. The sticky with the most votes is the winner and is what the team should try for improvement the coming week.


As for the rest - things might improve just by having vented them, but they are not in active focus.

Evaluation


Next week I use the startup section for a quick evaluation. Here I want to separate two parts. 


One question is whether we did as we intended at all. Not trying isn't necessarily failure. Things change quickly from time to time and we might have had valid reasons not to do it. Even "did not have time" is a valid reason - and suggests that we should put aside time.


If the team did try the suggestion, the second question is whether it helped us or not. If it was helpful, we try keep doing it. If it was not helpful, then it is important to keep in mind that it was an experiment - and such should have positive and negative outcomes from time to time.


If the suggestion was tried and found helpful, we should find a way to formalize it. Technical stuff might go into a new check on the build server, working habits might go into the team's "Team Rules" or "Working Agreements" - whatever the name. The important part is that we do something that makes it plausible we will continue doing this good thing we have just found.

Getting Retrospectives Going, at All

I have found that running a few Blitz Retrospectives often results in an acceptance of having retrospectives at all. In combination with the not-very-scary format "ok, we can spare 25 min after Friday lunch", it is a good way to get retrospective started at all.

Of course, such a brief format misses many points - things a longer and deeper retrospective will catch. But the purpose of Blitz Retrospective is not to catch those - it is to win acceptance for having retrospectives at all an pave way for deeper retrospectives down the road.

I have found that the format works well for that purpose.

Yours

   Dan

ps Ester Derby and Diana Larsen have written a great book named Agile Retrospectives that is really helpful once you have gotten past that initial resistance, have established retrospectives, and want to elaborate them, specialise them, or just improve them in general.


pps Tobias Fors has made the point (blog post in Swedish) that feeling safe and secure is fundamental to engaging in a retrospective. He suggests the fundamental rule being "Everyone did their best given the conditions", and I have seen it helpful to start each retrospective with writing some similar statement on the whiteboard.

Agile Product Owner - the New Project Manager Role

Dear Junior

From time to time I hear claims that: "with agile/Scrum, there will be no need for project managers any longer - they will have to find some other job". This seems strange to me, I get what they are getting at, but the analysis is very incomplete.

To start with, a role cannot go and find some other job - role is a job description, not a person. A person can go find "some other job". So, I guess that they mean that all people currently employed as project managers will have to go find themselves something else to do, because "Agile" has come along making them as obsolete as the advent of cars made company stable-hands no longer needed, simply because their skill sets where no longer needed.

Interpreted that way, I can see what they mean. If you have a project manager, who's major part of the workday is to "administer resources" by assigning tasks to programmers and controlling the result - then than those tasks will be absorbed into the Scrum team (using Scrum as an example) and their self-organisation and commitment-driven collaborative work under the lead of a scrum master. And, if the rest of the workday is filled with planning and fiddling with requirements - then those tasks will be absorbed by the engaged, involved product owner (still using scrum as an example). What is left in-between is the clerk accounting tasks like compiling time reports and other stuff - and those things are not considered necessary any longer. Thus, what are left are unemployment, retraining, and disappearance from the scene.

Throughout my years in software development I have met more than a few project managers. Some of them have done a good job and I have gained respect for their skills and efforts, some not. For those, I have not been impressed by, the above analysis hold - I think software development as a whole, and the poor teams they managed specifically, are and would be better off without them. However - the good project managers I have met have made a difference through their skills and efforts - chasing them on the door for having "project manager" on their business card would be a serious mistake.

Where do the skills of these good project managers fit in the "Brand New Agile World of Scrum"?

The naïve answer is often "they become scrum masters". However, when I look at the tasks and skills needed for being a scrum master, and at the skills of the good project managers I have met, I do not see a very good match. Well, "good leader" is a match, but then it stops. The scrum master leads the work in a very tight loop, facilitating the synchronisation of work between programmers, keeps the work focused on the next "smallest step" etc. If I would appoint someone as scrum master, I would not look among the project managers, I would look among the programmers, looking for the informal leader, the one trusted and respected by the rest of the team; perhaps the person already have a title like "lead programmer" or similar. Given complete freedom, I would probably go even one step further: I would let the team itself elect the scrum master, with some mandate period and some mechanism for re-elections.

If not scrum master, then what to do with our excellent project manager? When thinking about where I have really seen them making a difference, there are a few skills that pops into my head. First, they have been leaders with a vision. Even tough they have had some kind of steering board or committee that supposedly has given directions, it is the project manager that has embodied the vision and purpose of the project, and done the job of "walking the floor", being involved and keeping people engaged. Secondly, they have had a really good grasp of requirements and prioritisation thereof. They have understood to the minute detail what the system should do and why, they have been available to answer questions and straighten question-marks when needed. And, thirdly, they have taken responsibility, making decisions when needed - even when putting them self at risk by not waiting for the next steering committee meeting to pose the question, realising some decision is needed right now.

So, where do these skills come best to use in e g Scrum? It should be pretty obvious: they should be product owners!

But, the product owner, should that not be the Manager of Web Sales, or some CXO? For crying out load: NO! No CXO I have met have the time to do a good project owner job. They will not be willing to spend at least an hour a day in the programmers' workspace to answer questions, they will not be at the daily standups, and they will not come to the retrospectives. The former project manager will do all this. And will most probably talk with the Mgr of Web Sales and the CXO, as they are important stakeholders (former members of steering committee), to understand the interests at stake in the system, where after she will make an informed decision, now also having the formal mandate to do what she has always done.

I wish I could give one piece of advice to the excellent project managers I have met. I that case it would be this: do not get fooled to think you should become a team lead or a scrum master; it is a waste of your skills. Your role in the brand new world of agile is the one of a product owner - do what you have been doing so well, now with full empowerment. We all need you there.

Yours

Dan

ps Check out my fellow Swede Anna Forss' essay on "Confessions of a Serial Product Owner". She is an excellent example of a project manager turned product owner. She is also one that shares my interest in the combination of domain driven design and product ownership.

pps Some of the skills for priority of requirements/stories I have seen at good project managers that would make excellent product owners are spending a lot of focus on keeping things upcoming really crisp, and let the rest of the list be a little bit more informal - but never sloppy.

ppps There are many ways to describe a good product owner. One is through the four characteristics engaged, involved, decisive, and empowered.
ppps To give credit where credit is due, the fragments of this idea had been lingering around in the back of my head for some time, but it was not until my friend and colleague John Wilander said it out aloud that I got the push to phrase it properly.