Retrospective exercise: 4 quadrants for lessons learned

Yesterday I run a retrospective for a group of people who were interested in the lessons learned from one project. Their intent was to look for do(s) and don’t(s) they could take for the next similar project.

While deciding upon a data gathering activity, I ended up creating an activity which I have named: the quadrants for lessons learned.

Please find below picture depicting the activity. It has two axis: success versus failure, and planned versus unplanned. It has 4 quadrants: successful and planned, planned but failed, Unintended but successful, and Failed and not Planned.

The photo below is a result of this activity. As you can see, it generated lots of insights on lessons learned. The participants enjoyed this activity. It gave them lots of data points to talk about. I personally liked it because it opened our eyes for interesting quadrants, such as the accidental success or failure despite of planning.

After gathering the notes on the white boards, I asked each participant to use up to 5 dots on the cards he/she cares the most.

Speed Car - Abyss retrospective activity

Here is a retrospective exercise I have used a few times. I named it the speed car – abyss ectivity.

This is a forward thinking exercise, with an eye on the past. It is a mix of retrospective and futurospective. I did find it useful in occasions where the team came together for one of a time retrospective (not a iteration end, or release retrospective). In the instances I used this activity, it helped bringing the team together towards one common goal (which might not be very clear for all team members).

Activity instructios: total 40 minutes

– Looking at the figure (drawn on the whiteboard), please write notes and place them on the following picture areas: Engine, Parachute, Abysm, Bridge (10 minutes total)

– Read and group notes per area (5 minutes)

– Discussion and action planning for each activity area. Recommended:

• Engine, and Parachute 10 minutes;

• Abysm, and Bridge, 15 minutes

Looking Back

Engine: What have been pushing us forward? Making us move fast?

Parachute: What have been slowing us down?

Looking Ahead

Abyss: What are the danger ahead? What could take us down the role?

Bridge: What could we build to overcome such challenges? What shall we do to overcome the abysm?

Here is the retrospective exercise as slides:

Retrospective activity speed car abyss

My special thanks to my friend Vini (Vincius Viera Gomes) for the awesome drawing.

Feedback from the workshop – Agile Brazil 2011

First of all, I want to thank each and everyone who gave feedback on the workshop and activity: Don’t limit yourself. Based on your feedback I will be able to improve the workshop: Don’t limit yourself workshop – Agile Brazil 2011.

I did collect feedback at the session itself. I followed the same style used on QCon Sao Paulo last year. At the end of the session I had a bow, a few pen and cards (blue, yellow and pink; respectively great, medium, bad). The workshop attendees could write a few lines of feedback on the chosen card and drop it at the bow.

Here is the feedback written on these cards (in no particular order):

• More time required for the activity
• Please talk about techniques on negotiating Kanban limits with a client
• Interesting topic; activity could be more organized
• The activity consumed too much time.
• The game was good, but I wanted to hear more about the results.
• Replenishment + +
• The presentation was excellent; not enough time for the activity.
• Suggestion: add a timer for the activity.
• Excellent! Best talk on Agile
• Congratulations!
• I really like the target idea. I will try to put it in practice. The activity should be more organized; I suggest more time and control.
• Congrats. It was very good!
• Really good activity; I will put it in practice!
• The unique point of view on the flow was very pertinent. The activity really cool and gave me a practical view of the flow theory.
• Really cool activity!
• Print out the activity rules, and have make the roles more defined. For instance, you could have the pizza dude making decisions on where people work. There were too many people on the team making/trying to make decisions.

Based on these feedback and more I did receive verbally, I will do the following for the future of this workshop.

• Keep a version of the presentation without the activity. The presentation was very well received, and the time was under control. I might use it again for talking about Kanban, flow, and the target-variance score. Perhaps I can add a few slides explaining that experiments (such as the workshop activity at Agile Brazil) have show good results.

• For the workshop activity I will do the following improvements:

1. Make reusable cards. It was too much work to prepare, and I will not be able to reuse these cards.

2. Add a mark for amount of work completed in each card (50% done and 100% done)

3. Add a timer for each half day (for example: 1 minute for each half-day)

4. Keep the same numbers of people involved (1 BA, 5 Devs, 2 testers), but reduce the number of people making decisions on who should work in which card and stage (at most 3 people for each team).

5. Time box the activity

6. Have enough time for discussing the results (10 minutes at the end)

7. Have the card wall for each team already prepared on each team table. This should include the cards already on play on day 1 (now renamed to day 3). The theory on limits and targets is already covered during the presentation.

8. Have avatar for each team member ready (BAs, Devs and testers)

9. Simplify the rules (consolidate it), and have it visible at the wall

10. Have a calendar to show the days passing by (again, visible on the wall)

11. Have one person for each two teams to answer questions (co-presenter)

Please let me know if oyu have any more feedback. And once again, thanks for the feedback!

Don’t limit yourself workshop – Agile Brazil 2011

Last Friday I delivered the workshop Don’t limit yourself, Kanban and beyond at the Agile Brazil 2011 conference.

The workshop was composed of two parts: a presentation, and an activity.

At the presentation time, I introduced Kanban, and talked about the reasoning behind the Kanban WIP limits, and the reason I propose a more flexible and effective control: the target-variance score. My hypothesis was that a card wall following target-variance score would have better results than a typical Kanban card wall, and I decided to give it a try at the Agile Brazil conference (it was the first time I did run the activity). The activity results did help me validate the hypothesis! I will repeat this and similar activity, and will keep on sharing the results (future conferences, work sessions, and blog posts).

Below are the presentation slides:

Dont limit yorself beyond kanban - presentation - paulo caroli

The activity was the simulation of work moving through the card wall (visual representation for the same workflow) for 4 different control mechanisms:

A – without limits

B – Kanban limits, without pairing (unless the WIP reaches the limit)

C – Kanban limit, pairing as much possible

D – using the target-variance score (instead of limits)

Dont limit yorself beyond kanban - activity

Four decks of cards exactly equal were distributed to the teams (A to D) which had the exactly same configuration: 1 BA, 5 Devs and 2 Testers. The cards (Stories) had to be played in the sequential order (1, 2, 3…20).

Below is one team’s deck of cards.

While the time went by (myself screaming: the day started, it is lunch time, it is afternoon working hours, and the day is over), the work was moving on the workflow (the card wall). Each team work dynamics (who helps who, and when) was decided according to each team control (no control for team A, limits for teams B and C, and the proposed target-variance for team D). The teams were taking pictures and collecting data for a Cumulative Flow Diagram (on an excel spreadsheet) at the beginning of each day.

Here is a photo taken by team B:

We were able to finish the activity, but unfortunately, we did run short of time and could not analyze the results. I did promise this blog post for the attendees to share a few notes, photos and the Cumulative Flow diagram of each team.

At the end of the activity, I had the following data points:

• Team A completed 10 Stories
• Teams B and C had similar results: both finished 11 Stories
• Team D seemed like the less chaotic team, and did the highest number of stories: 12 Stories

On subsequent blog entries, I will share the feedback from the session (thanks!), upload activity photos, and the Cumulative Flow Diagram created by each team. If you were at the session and have either photos or the excel file, please send it over.

Here is the feedback I collected from this workshop.

The 1000 Students Challenge

I've been doing agile coaching and consulting since 2003. First internally, later external working for various consulting organizations all over the globe. Well, one of my key experiences was, that before being able to teach agile, the mind needs to be freed from old school thinking. Think about a major reset. I won't say that everything taught is unusable, however, it is often used in the wrong context. There is more and more evidence that better ways of working -- especially, in the field of knowledge work -- do exist and agile is one of them.

Since 2010 I am a Professional Scrum Trainer with Scrum.org and teach various Scrum classes. Depending on the mixture of the audience and their background, it does take some time to free their minds from the old believe system and make them receptive to the new ideas. Better late then never, but for a two day course it is not as effective as it could be. Often, the AHA-effect happens late on day two.

After having given the PSM to a bunch of very stubborn senior managers, I decided that a there must be a better way to change the world of software development. That night, the 1000 student challenge was born. The idea is simple - don't try to change the head of the system, but have future agile thought leaders join the system and move up the ladder.

My vision is to teach 1000 students in Scrum and hope that they will change the world of tomorrow.

On May 28-29 2011 I gave me first Pay It Forwad - Professional Scrum Master (PIF-PSM) training at the University of Bern. I had the pleasure to work with 13 bright students, willing to come in on a Saturday and Sunday to learn about agile and Scrum. The training is essential for free - however USD 100 per student is required to cover the assessment fees and the course material.

13 people joining the workforce with a an agile mind set. It is a small beginning, nevertheless I really feel good about it.

If you are interested in doing this at your local university please contact me and we work out a way to spread Scrum at your place as well.

987 more to go ...

.

PM Dojo

The first PM Dojo! At least, it was the first PM Dojo I have heard about. For this reason, I want to share it.

Inspired by many Dojos our colleagues have been doing at Thoughtworks Brazil, we –PMs and BAs-- decided to give it a try.

Here are the slides we have used:

PM Dojo Thouhgtworks Brazil - 2011 April 27

The Dojo took one hour. It started with a quick overview, followed by a round table (fishbowl style), and a closing exercise.

The round table had 4 chairs. One chair was kept empty, available for whoever wanted to join the conversation. When someone joined the table, someone else on the table (typically the one either sitting longer or less involved on the current conversation) would leave the table. The other participants were standing or sitting near the table. This is the fishbowl style.

For the closing exercise, we used the ROI (Return on Investment) and Feedback exercise.

Basically I asked the participants to write down in a post-it feedback about the Dojo. Then, I told them to place the post-it on the ROI radar.

The ROI radar have a line going from very little ROI :( -- to very high ROI :) ++. The ROI question was:

For this last hour that you have spent here in this Dojo, how do you measure the return on your investment (of your time)? I am supper happy; this was really worthy my time: goes on top; the opposite goes on the bottom.

Below is the result from the ROI and Feedback exercise.

I left the Dojo with a good feeling. Now, I will check the feedback, chat with some of the 20+ folks that participated on it, and start thinking about the next one.

Scrumban em Porto Alegre

A ThoughtWorks será anfitriã do primeiro treinamento de Scrumban em Porto Alegre.

Do Scrum ao Kanban: Novas perspectivas em gestão Ágil de projetos de software

Recentemente, a comunidade ágil, tem voltado a atenção para o Kanban, muitas vezes usando como referência o Scrum (método ágil predominante). Neste treinamento Rodrigo de Toledo e Alisson Vale explicitam esse caminho do Scrum ao Kanban, também conhecido como Scrumban, revelando quais os ganhos que podemos colher. Conceitos como fluxo contínuo, foco, visibilidade e melhoria contínua são reforçados. Acreditamos que o Kanban traz um novo patamar de amadurecimento no mundo ágil.

Dias:
1º e 2 de abril. Das 9h às 18h.

Local:

Escritório da ThoughWorks (localizado na PUC-RS, Tecnopuc, predio 99, 14º andar)

Maiores informações:

http://www.scrumban.com.br