Skip to content

Demystifying Agile: Rants of a Madman – Retrospectives Take III

April 15, 2013

This will be my third post on doing short retrospectives at the end of each Agile iteration. My first was over a year ago, March of 2012, and my second was a follow up in July of 2012. Why this 3rd post? I’m just dumbfounded by all the teams I’ve met who have ignored this advice. Here it is a year later and had you picked just one thing, just one actionable thing, to do better with each sprint you’d have at least 17 process improvements under your team’s belt. Your team today would be able to reflect on how much has improved in just one short year. You’d feel just awesome about it.

If you’ve done this then congratulations! You and your team probably feel really great about how far you’ve come together. If you and your Agile team haven’t done this? I’m just speechless. Really?

Time for a short pop quiz: So, how did it go? Please classify your Agile Team in to one of these categories based on the last 12 months:

  • Overachievers: 1 to 2 things per iteration to improve upon? Surely you jest! We found at least 3 things we could improve on per iteration, created action plans for each, and we can walk you through 50 or more process improvements since your post on this topic! We own the Agile!
  • Achievers: We chose 1 to 2 things per iteration as you suggested, created action plans for each, and can share with you and other teams the 17 to 34 things we are doing differently to be a better performing team than we were twelve months ago.
  • Hopefuls: We chose the 1 to 2 things, but really never acted on too many of them. We were too busy doing other things to actually improve ourselves. We have perhaps 10 things we improved upon in the year that has gone by. Thanks for the reminder and we’ll try to do better from now on.
  • Embarrassed: Dang. We really didn’t bother to do anything with our retrospectives. We know that we should have, but we didn’t. Perhaps we can try again. Perhaps we can check in with other teams and see what they improved upon and see how we could possibly benefit from trying the same. We’ll make a fresh start and try again.
  • Sleeping: Huh? Are we there yet?
  • Contrarians: We see no value in any of this. We are the only Agile team doing it correctly. Your posts bore me. Why hold retrospectives? Why build our keep doing, start doing, stop doing lists? Why pick 1 to 2 actionable items from these lists to help ratchet up the performance of our team? Now go away, you bother me…

Now that you’ve scored your own team, what Agile Team do you want to be part of?

Go make it happen! Just take ownership and go make it so. Yes, you alone can make it happen. Don’t wait for your manager, the product owner, or scrum master to go do it for you; you go lead the charge to do it.

In these posts I can share my thoughts and advice, but I cannot do the work for you. Agile is about delighting customers while delivering incremental value; it is about weeding out what is holding your team back and embracing those things that help the team do better. As an Agile team you owe it to yourself to deliver some of that value back to yourselves; retrospectives can make that happen.

One last challenge: What improvements did your team identify and make in the last 12 months? Which are you most proud of? Please share them with others by adding them as a comment in response to this post. As I said before, we’re all in this together…


About this series: I love Agile; I also hate Agile. I love how it can free teams to truly delight customers while delivering high quality products on time. I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size. My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.


From → Agile

One Comment
  1. Crosby permalink

    Thanks for this wonderful sharing i like agile system development for small businesses. A lot of processes following for agile software development such as waterfall model. Agile development model is different from conventional models, agile project management is a specialized area in project management. It emphasizes on the fact that entire team should be a tightly integrated unit.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: