Priority Race - A Game for Effective Retrospectives

I will introduce a game I invented for facilitating effective and active retrospectives. As every experienced ScrumMaster knows, it is not only important to prioritize (or more correctly: order) your product backlog, but it is also important to prioritize your impediments. This game can help you, making retrospectives more active and fun while obtaining a good order for your impediments.

Material: Non-transparent tape, Scotch tape, flashcards or sticky notes (red and green), flipchart marker, wall or big table

Preparation: Before the retrospective begins, you will have to search for a wall, where you can draw some vertical lanes with your tape. You can alternatively use a large table, which is the second best option. Mark the lanes as follows:

Initial setting: Draw some vertical lanes on a wall (this is the "race track")

It often helps, to put numbers at the top of every column (you can do this easily, using post-its).

How the game works

Step 1: Split your team into several groups of approximately four people. The groups then collect positive and negative feedback on cards (you can alternatively let everybody bring his own feedback, but I like having initial conversations in small groups).

Step 2: Let the groups explain their feedback and put the cards on the wall/table. At the same time, group the feedback cards to clusters of equivalent topics.

Step 3: Put all card clusters to the starting line of your race track, that is position 0, as depicted below.

Put the impediments and things that work fine in the first column (column 0)

Step 4: Now everybody has to execute two moves with green and two moves with red cards. I.e. advance one card two columns to the right or two cards one column with every color. Everybody should try to get her favourite feedback cards as far as possible to the right (but at most two steps). Do this until everybody executed four moves. You can either let the participants do their moves one after another or at the same time (which saves time).

Player 1 advances two green cards one column and a red card two columns

Player 2 moves two green cards one column to the right, and so does he with two red cards

Done: The result will be, that all cards are distributed on the racing track. The distribution is not arbitrary, but reflects the prioritization of the issues in the team.

All Players moved four steps: Prioritization is done.

 
You are now free, to continue with your retrospective, going through the feedback from the right to the left. You can also take a fixed number of green and red cards to focus on in the remainder of your retrospective or take the order as input for your impediment backlog.

You could now focus on the top three cards for further discussion

Hint: You should do some computation before starting the game: Depending on the number of participants you should adapt the number of columns or/and the number of allowed card moves to do for every participant.

You can also use this mechanism for prioritizing any other kind of material (even your backlog) with a larger group of people. I used this game with up to 20 people, prioritizing up to 20 items.

Real world example: Initial setting

Real world example: Result

The great advantage over prioritization with dots or other markers on the cards is, that the result is immediately clear and much more intuitive and visible. No counting - just looking!

Just try it - and if you have any ideas for improvements, different applications, variations, or positive or negative experiences I will be deeply grateful for any comments.

Why Agile is Doomed to Succeed - If Done Wholeheartedly

and why Scrum implementations sometimes fail - or do not deliver what they promised


I recently read the book "Drive - The Surprising Truth About What Motivates Us" by Daniel H. Pink, which is much about motivation in the 21st century workplace. There is a tight connection between the ideas expressed there and the thinking and principles behind the Agile movement (e.g. Stoos-Network, Scrum, XP, etc.). I want to try to work out this connection, so you can understand one of the key success factors of Agile. If one understands these, one has - as a byproduct - immediately a good understanding at hand, why Scrum implementations do sometimes either fail or not deliver what was expected of them.
I will at first try to explain the core drivers and levels of motivation Pink describes in his book. He destinguishes three levels of Motivation:

• Motivation 1.0: This is what essentialy motivates every kind of mammal to do whatever it does. It's about the basic necessities for survival: eating, drinking, reproducing, security, etc. In essence Maslow's hierarchy stages 1-3. This was probably fine for humans in stone-age and earlier times.
• Motivation 2.0: Essentially based on rewards and punishment (or as Pink states it - carrots and sticks). This was one of the main drivers of the industrialization era where thinkers and managers where broadly influenced by the theories of Frederick W. Taylor and his "scientific management". It is all about command & control and extrinsic motivation. Work in this times was in huge parts not very complex and consistet much of simple repetitive tasks, that are done by computers and robots nowadays.
• Motivation 3.0: There is strong evidence from scientific research of the last five decades, that Motivation 2.0 (rewards & punishment, extrinsic motivation) are very unreliable and weak motivators in our current social and industrial environment (but still relevant for some very specific settings). If you want to read about and understand this hints - read the book! Following the book there is a better motivation scheme than Motivation 2.0, wich is based on intrinsic motivation. This motivation scheme has three core drivers:
• Autonomy: Not to confuse with independence! Autonomy means the need and ambition to have as much as possible autonomy over the work to do. It means having the opportunity of acting with choice (e.g. choice over how to do the work and when to do it best). "Control leads to compliance; autonomy leads to engagement".
• Mastery: The willingness, to strive for excellence. It is about continuous improvement and perfection of the personal skills. Which is not the willingness to be the best of the best, but more the drive, to make the most out of the talents and abilities one has (which is the most you can expect!).
• Purpose: Everybody wants to see the work he does in a greater, meaningful context. The work one is doing from day to day should have some greater sense, which is indeed almost always the case, since most of all work is done for some customers.

So far - so good. But where is the connection to Agile?

It is essentially very simple. Agile is in big parts build exactly around the core drivers of Motivation 3.0. Let me explain this shortly:

• Autonomy: Starting with XP, continued with Scrum and now discussed in the Stoos-Network is the central idea of the self-organizing team. The idea is to give a team as much as possible autonomy over the work to do.
• Mastery: Here craftmanship (XP) and continuous self-improvement (Scrum, Stoos-Network) are the keywords. These postulations and processes are inseparably connected to agile processes and ideas.
• Purpose: Agile frameworks generally build upon integration of the customer. The tighter - the better. Direct feedback and collaboration with the customer is probably the best way of getting sense and meaning to your work. This is because you immediatly see, who benefits and get direct feedback.

OK, I understood that, but where is the point of failing Scrum implementations? How does this motivation stuff help me understanding the why of failure? It is not hard:

Scrum works out well, if you encourage these points, since motivation of your teams is very likely to increase. Increased motivation leads to increased productivity and - by the way - to increased satisfaction.
If you do only use the mechanics of Scrum, but do not really let the teams self-organize (giving them the freedom to make their own decisions!) or do not cultivate craftmanship (invest in education, encourage and set the stage for self-education) or do not bring the customer as close as possible to the team, motivation will not flourish. Thus, you are very likely not to improve very much - and be doomed with another process corset. Which I would just call failure.

Making the Case for Story Points

Or: Why Story Points Outperform Man-Days easily

I introduced Scrum to a number of teams now. There was always big discussion whether estimation in Story Points is of any use. I think estimating in Story Points is one of the really great inventions of the Scrum framework and I want to draw out the reasons for this believe in this post.

Estimating in Story Points has great advantages in multiple aspects:

Team Advantages

• Story Points are a team metric. They are always estimated by the whole team. In my experience those estimates clearly outperform man-day estimates, since they depend not so much on who actually carries out the estimated task. Thus Story Point estimates are more reliable.
• Since everybody in the team participated in the estimation most people feel more accountable for the work behind the Story. This is often not the case with man-day estimates which are in many cases given by experts and carried out by someone else.
• Since the whole team estimates, much more information is shared among team members. This supports reducing islands of knowledge.
• In emerging discussions during estimation open questions and risks are discovered very early.

Abstract Number Advantages

• There is no immediate connection between Story Points and real working hours. This makes estimation often much easier and removes useless points from the discussion agenda in estimation meetings.
• Estimating in Story Points makes you almost immediately think a little more abstract during the estimation. You often do not loose yourself in the details of the implementation which makes estimation faster but still accurate enough.
• Story Points are usually estimated in fixed and fastly growing steps (e.g. the Fibonacci Numbers). Therefore the amount of uncertainty and risk is simply expressed in the resulting number. The bigger the number - the higher risk and uncertainty. This is clearly expressed by not having numbers like 427 available (which would suggest high accuracy for outside observers).
• You can estimate earlier in Story Points than in man-days. The reason is that you can much earlier say how big a task is relative to other tasks, than to determine exactly how many days you would need to implement it. Relative estimation seems to be easier to accomplish for human beings than absolute estimations.
• Estimations in Story Points are often more honest than estimates in man-days. The reason is, that you do not have the feeling to "promise" to be done in X days.
• Since the Story Point number is abstract you do not have the temptation to build in buffers. Thus you have much better control about the real state of work.

Efficiency Advantages

• Estimation in Story Points is often much faster than classical estimation in man-days. Many of the reasons for this point are still mentioned above. Additionally, there are methods to get those estimates really fast (e.g. Planning Poker or Magic Estimation).
• By estimating in Story Points you avoid unnecessary discussion and justification for the time needed ("Why can't you do this in three days? Five really seems a little to much...").
• You additionally avoid useless discussions about teams performance ("you are three guys working five days a week - why did you only finish work estimated for six man-days last week?"). To be clear: discussions about teams performance (positiv or negative) are legal and often good hints for impediments, but not in the indicated tone. Thus Story Points can switch your attention from justifying to solving problems.

Self-Improving Mechanism

• In my experience you get an excellent predictability for your projects progress with Story Points in early project stages. This is because Story Points contain a self correcting mechanism. Slow or fast progress will show up early in the project.
• If you made some errors during your estimations the errors are very likely to be averaged out. Thus you do not have to care so much about the correctness of your estimates, which saves you good amounts of time.
• The estimates in Story Points are self adapting. If a team changes, the mechanism adjusts itself immediatly. If the teams performance increases or decreases you do not have to re-estimate. All estimations stay valid and you can still easily predict progress.

I do not love to say this, but there are two disadvantages at hand with Story Points from my point of view:

Shortcommings

• Firstly, they are hard to explain. Almost everybody is familiar with some estimation in man-days. The concept of relative and abstract estimates are difficult in the first place. But this vanishes after only a few weeks.
• The second point is that in our times and organisations you often have to do some recalculation from Story Points to man-days for financial reasons. This is easy, but is work that generates only limited value.

If you have any other arguments on estimations in Story Points - feel free to comment on this post.

In essence, the central goal of estimations is to get the necessary metrics and information to make progress transparent. This is obviously possible with both, man-days and Story Points. But considering the huge amount of advantages of Story Points this - at least to me - seems to be the better and more efficient way to achieve this.

But after all - it's an estimation technique and the only thing you can be certain about is that it's to some degree uncertain.

YABAA - Yet Another Blog About Agility?

For quite a time I was absolutely sure, that I could not help anybody by writing about my personal opinions or experiences. And if there is no value in writing for somebody, I will probably be better off spending my time in more value creating ways.

However, during the last few weeks I had lots of discussions giving me the impression that some of my expriences and insights could be of some value for others doing similar stuff as I do. Furthermore I am now convinced that writing about specific topics is of great value for myself, because it enforces me to reflect more on those topics. Since my main focus lies on applying and introducing agile methods I will probably mostly - but not exclusively - write about specific methods or insights I generated while doing exactly this.

So by now I am not anymore absolutely sure about the uselessness of my writing for others. This is a point following me through all of my life. In many things I was certain that assumptions hold true and was later convinced that good old reality thinks different.

• Long time ago I was convinced, that I am an exorbitantly bad student - advancing from school to university convinced me that this is not generally true 
• Long time ago I was convinced, that the US would not be a country I would like very much - traveling there convinced me that this is not true 
• Some time ago I was convinced, that perfectly executed classical project management is the only way to succeed - Scrum and agile methods convinced me that this is absolutely false 
• And there are many examples to be made...

What I learned from all of this is that you do not know anything for sure, until it is done and history - and even then you can discuss about facts...

So I decided to make one of my personal key insights the title of this blog: "It's Certainly Uncertain". Hoping, I will discover many, many more wrong assumptions in my further life and keep on learning.