Old Dog, New Tricks

I held my first project retrospective this week. It was probably overdue, but there is no time like the present right?

I found Peter Steven’s blog and Boris Gloger’s paper on Heartbeat Retrospectives helpful in setting the format. I decided to cover the following topics in our retrospective

• What did we do well?
• What can we improve on?
• Who has ownership of the things that can be improved?
• What are the priorities?

We used sticky notes and a white board. You need to be succinct to state your point on a sticky note. Plus once they go up on the whiteboard they tend to lose ownership and they become the team’s ideas. There were only a few times when we had to ask who wrote something and that was only to clarify an idea. The group ownership of ideas keeps things flowing and prevents the meeting from being driven by one or two strong personalities.

Starting with “what went well” set the tone that the meeting is going to be positive and constructive. At other companies I have been at these type of meetings often turned into a finger pointing exercise and went downhill rapidly. Our team has a lot to be proud of, and it was great to reflect on the things we did well. And if it ain’t broke…..

The things we thought we did well broke down into 3 catgories: Team, Process, and Technology. I am not sure if that categorization was planned or an impromptu decision. Grouping them into categories didn’t really serve any purpose other than it allowed us to acknowledge each point as we decided where it belonged.

Like any project there are things that we can do better. We purposely did not put any limits on what people thought we could do better. Once we put everything up on the board we broke it down into two groups: Team and Organization. Team means we can do it within the framework of our own team structure. Organization meant we had to bring others (HR, management, etc) into the mix to help address the problem.

Once we had things broken down into 2 categories, it was time to prioritize the lists. There are a couple of different schemes you can use here. Seeing the same issue raised by multiple people may indicate something that is important. Ultimately we decided to do a simple voting scheme where everyone got one vote, and that seemed to work pretty well. Next time we may try giving everyone three votes, but that’s for next time. We have a small team, so there were only a few items in each category that got votes, but even that tells you something, and we were able to prioritize those items. The reality is you can’t fix everything, so you focus on what is most important.

Probably the most important part of a retrospective is that you take action on the high priority things to improve. I am anxious to seize the momentum and teamwork of the meeting. That is the challenge for me and the team in the very near future.

I went away for a relaxing weekend, far from cell phone reception and internet access. Given my recent post about not being able to turn it off at the end of the day, maybe it is slightly ironic that I packed two books: The Art of Agile Development and The Art of War.

The Art of War is one of those books I like to pick up from time to time. I am not a fan of comparing war to sports or work, there is no comparison. The book is a good read though for understanding strategy, how to utilize resources, and human interactions. Many of the concepts are applicable to daily life.

I found an interesting passage in The Art of War that could be applied to the concept of Energized Work.

In War,
   Victory should be swift
   If victory is slow,
   Men tire, morale sags
   Sieges exhaust strength;
   Protracted campaigns
   Strain the public treasury.

If men are tired,
   Morale low,
   Strength exhausted,
   Treasure Spent;
Then the feudal lords
   Will exploit the disarray
   And attack.
   This even the wisest
   Will be powerless
   To mend.

Logically, I believe in the concepts behind what the XP community refers to as Energized Work. Software engineering is a complex activity and it requires you to be fully engaged and focused. That is hard to do if you are working long hours. The problem I have with it is that over 20+ years of working as a software engineer, I have conditioned myself to work to the limits.

I was talking with another developer about this recently and I said that it really takes buy-in from management to make Energized Work possible. He turned it around and put the burden back on me. His thinking was it only worked if I made the decision to follow the principles and it would never work if I waited for someone else to make it happen.

That meant I had to make the decision to leave work at a regular time. That I had to make the decision to spend time with my family instead of sneaking off to do work. This developer and I have worked together in the past and he knows my work habits pretty well. His analysis stopped me in my tracks.

Bad habits are hard to break. One of mine is not being able to turn it off at the end of the day. I have to put the blame for that squarely on me. I have no problem saying to another developer “Go home, you’ll get it in the morning”. I need to remember to apply that advice to myself from time to time.