Retrospectives on One Page

Drawing is part of a Leanpub book: https://leanpub.com/agileplanet.

References:

• "Agile Retrospectives" by Esther Derby and Diana Larsen
• "The Retrospective Handbook" by Patrick Kua
• "Getting Value out of Retrospectives" by Luis Goncalves und Ben Linders
• Retr-O-Mat by Corinna Baldauf

Scrum on One Page

This drawing is part of a Leanpub book: https://leanpub.com/agileplanet. If you like it, you might want to have a look at the book, too.

References:

• The official Scrum Guide
• "Agile Project Management with Scrum" - Ken Schwaber
• Agile Atlas on Scrum (Scrum Alliance)
• Jeff Sutherland's blog

Lean Startup Experiment - Day 4 (and last)

At this moment we decided to finish our lean startup experiment. We were currently coping with technological difficulties with a relatively simple feature. It is now clear, that we will not be able to accomplish everything we wanted to until Friday evening. Thus, we all agreed to stop and use the last day somehow else.

Why did we struggle? A short retrospective revealed the following issues:

• We did by far not do enough marketing - thus we had almost no real customer feedback on our site (there was exactly one person subscribing the service :-(). We did get some feedback indicating, that potential customers did not really get the idea of our page.
• We did not prepare well enough for our experiment. We used a whole lot of technologies, we did not really know. This broke our neck today.
• One week is really short for delivering even a relatively simple project in a serious manner.
• Summertime is a really hard time to stay focused on such a project ;-)

But after all, we all still learned a great deal. Not only technology, but also how to work in short cycles as a small team. Setting small reachable targets every day and having short status syncs worked extremely well for us.

A big thank you to all readers of this blog and all supporters giving us valuable feedback on our little product! We will now go on and enjoy a great free three days before going back to business as usual :-)

Organizational Dept

In the field of software development, there is a metaphor called "technical dept".  In short, this metaphor says that while you are programming you almost always build up dept. Dept in this case means that your code base decreases in quality over time. You will have to invest time and work to amortize this dept. If you do not amortize your dept, interests will take effect. Thus, as with regular dept, you will always be better off to amortize the dept as soon as possible. Otherwise compound interest will be the effect and at the end you will pay heavily - if you are able to pay back at all anymore.

Speaking about Agile transformations there is another kind of dept. I would call it "organizational dept". It is based on the same concept as technical dept but on an organizational level. As your organization grows, you will take hundreds of decisions. Not all of them will be perfect and thus, you will (with every decision) increase the organizational dept. How does organizational dept look like?

There are multiple instances of organizational dept. Just to mention a few:

• People in the "wrong" position (on jobs they are not suitable for)
• A wide gap between the culture wanted and the culture existing
• Unresolved conflicts between people
• ... and many more ...

As with technical dept, if you do not regularly and fastly cope with organizational dept, interests will occure and over time compound interests will make your dept almost unbearable. At some point you might not be able to pay back at all anymore! Speaking of technical dept, the consequence for a software system is then to be displaced by a new system. What do you think will be the consequence for a company if you get into this state with organizational dept...? I think, we all know!

This is one point why Agile is so successful. Agile folks generally reject living with dept and always try to pay back as soon as possible. The incarnation of this attitude is e.g. the retrospective in Scrum and the focus on continuous improvement and impediments in all Agile methodologies.

Update: Sven Winkler picked up the idea of organizational dept on Boris Glogers Blog and adds some interesing points of view.

It's not the Culture, Stupid!

In many Agile transformations there seems to be an issue with corporate culture. People in the company often think and say, that the current culture is not compatible with Agile and the culture would have to change.

Values often mentioned in this context are the Scrum values:

• Commitment
• Openness
• Focus
• Respect
• Courage

I do only have one issue with this. Try the following: Take this values and present them to some randomly selected persons in your company. Ask everybody the following question: "How important are these values to you and are they part of your set of values?". I made the experience, that every single person will find these values to be important and most consider them part of their individual set of values. How then is it possible, that the corporate culture seems to be a problem?

To answer this question try another exercise: Again take the above mentioned values and show them to some persons and ask them the following question: "How much do you think do people in your close environment live these values?". You might be supprised, that the results will now be much worse than the results of the first question.

Find the explanation for the observed gap and you will probably be a huge step further in your Agile transformation. You can probably do this just by making the gap transparent and asking the people for an explanation. Eventually a retrospective may be a good place to do this.

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.