By Woody Zuill

What’s the most important “Agile Practice”? : Do Regular Retrospectives. Getting good at retrospectives is well worth the effort.

The basic idea is to take a look at how things are going, decide on some thing (or things) to make better, decide on action(s) to take, take the action(s), and then repeat the whole thing sometime soon.

We do frequent retrospectives. As a team, we like to reflect, tune, and adjust every chance we get.

We did a retrospective back in August about “pain points” with the purpose of identifying things that were daily “pains” for us.

This is what the affinity groupings and other “artifacts” looked like over a few months (Aug. 8 to Oct. 25).  I’ll cover a little of each below.

Pain Points

In our first retrospective in this series, we found that two important areas that showed up as “pain points”.  One of these areas was developer skills.  Here is the affinity grouping about developer skills:

The items include:

• Code fluency
• Coding skills
• IDE skills
• Typing skills
• Language fluency (C#/SQL)
• Resharper Skills
• Shortcuts

Give it a name

When an affinity group gathers enough post-its to clearly show we have an area we feel needs fixing, we try to come up with a name for it.  This one was easy to name: Developer Skills

We always discuss the things we discover during a retrospective and try to find some action we can take.  In this case, we decided to take some time to mull things over and meet later to discuss how to proceed.  We are flexible – remember: no practice is written in stone. Except for DO RETROSPECTIVES.  That actually IS written in stone.

The basic process we followed for this particular discussion was similar to a “Lean Coffee”.  We all suggested topics and wrote them on post-it notes, prioritized them, and discussed them in prioritized order, taking a few minutes per item, until we had sufficient actionable ideas.  We gathered a list of about 20 ideas on ways we could improve our developer skills, and we talked over about half of them.  Some of the ideas seemed to fit together naturally so we grouped them, and pretty soon we had a few things we decided we’d like to try.   These are what we call “action items”.

Here is what we ended up with:

Action Items

Here is what we decided to do

• Create a “cheat sheet” or “check list” for the steps for some common tasks
• Review and learn the motivations behind some code generation we were doing
• Hold a daily 1-hour practice period focusing on MVC, TDD, and basic coding skills

A Daily Practice Period!!!

Well, what do you know.  Seems like something we should have been doing from the start… I think we had talked about it now and then over the past year or so, but that’s how it is with good ideas sometimes: they stay stuck on the back burner until they’ve simmered just enough and then we move them to the front, I guess.  For over a year and a half we have had a weekly study and practice period and it has been very beneficial, so in the spirit of Extreme Programming – we decided to try doing a daily practice period.

We’ve been using the “practice” of daily practice for about 4 months now – almost every morning we practice doing a coding activity.  We’ve refined it a bit over time, but the basic idea has stayed pretty much the same.

Another Retrospective, another step forward: The 12 Days of Index

After a while (about a month I guess) we had another retrospective about our practice sessions, and although things were very positive we noticed that we were not gaining a mastery of one of the things we were practicing: Creating an Index controller and it’s related parts and tests.

We discussed our approach and a few ideas we might try.  One approach we adopted is very similar to how I used to practice the banjo when I was first learning (many, many years ago):

• Practice a little bit of a tune you want to learn (just a measure or two).
• Once you have that down, learn the next little bit in isolation from the part you already learned.
• Once you have that down, combine it with the part you already learned, and practice those together until it works nicely.
• If the transition from the first part to the second part gives you trouble – isolate and practice the transition.
• Once you have the “combined parts” working well, learn the next little bit, then combine…
• And so on.

We gave this “practice of practicing” a name: “The 12 Days of …” (you fill in the …. with the name of the thing you are practicing).  It is a little like the song “The Twelve Days of Christmas”.  You sing the first part alone, then the second part AND the first part, then the third part AND the second part AND the first part.  Hopefully, you get the idea.  So, in this case since we were practicing the coding of an Index Controller, we called it “The 12 Days of Index”.

The concept is to truly master each small part “in order”, adding the result to what we have already mastered.  Everything is learned “in the small” and builds to encompass the whole concept we want to learn.  So far, it’s been working pretty good.  We’ve had a few retrospectives on this since we started using “The 12 Days of …” and we’ve kept it so far.

Things to notice

• We pay attention to try to figure out what needs attention.
• We experiment and try things that might be an improvement.
• We review and make changes as often as needed.
• We name things in a way that makes it easy to “get the idea” and talk about what we do.
• We practice doing the work we do.
• As we become better at a practice, we start to look for ways to improve that practice.

So… have fun, retrospect, and keep on practicing.

One last thing.  We are starting a regular practice session for practicing retrospective techniques.  There is a great book on the subject: “Agile Retrospectives: Making Good Teams Great” (Diana Larsen and Esther Derby) – I’ve actually worn out my first copy of the book.  I ordered 6 new copies of the book and a group of folks here at work are going to get together weekly to practice the techniques in that book.  Very cool. We are now retrospecting on our retrospectives, and practicing getting better at it.