Steven Voyles

Ahh, the agile retrospective. I’m not sure I’ve seen a single more unappreciated practice in all my time working in agile environments. I’m also not sure there is a single more valuable practice among all those activities that we typically associate with agile development.

For those of you new to agile, I will give a brief overview of what a retrospective is. The agile retrospective is a period of time that should be set aside at the end of an iteration for the team to reflect on that iteration and look for opportunities to improve their current processes. Those of you familiar with the core agile value of ‘inspect and adapt’ will see instantly why this is such a vital activity. This is where we pause to inspect what we are currently doing and plan to adapt our methods to improve our ability to deliver value to our customer.

There are various techniques that can be used to conduct a retrospective and there is some debate around when exactly the retrospective should be held relative to the iteration. Both topics are beyond the scope of this article, but the main point I would like for you to take away from this is to just have one. Every iteration. Without fail.

Resist the temptation to barrel through your product backlog, heads down, checking off tasks until the product is ‘finished’. The time you take to slow down, get everyone together and have a conversation where your team talks about the issues they are facing and formulates a plan to overcome those issues will pay unimaginable dividends down the road.

“Yesterday I worked on US2846, today I’ll be working on US5378. I have no impedements.” Does this sound like one of your standup meetings? If that does sound familiar, I’d like to challenge you to ask yourself, “Does this provide value to my team?”

I have participated in stand ups that are barely more than phrases like that, successively provided by each member of the team, at many of my clients. If your stand ups sound like this, I would encourage you to examine what value a meeting like this is bringing to your team. Sure, this allows the project manager or scrum master to get a status report and fill out the burn down chart, but is there something more we could be getting out of our time in this meeting? Let’s explore the purpose behind the daily stand up in more detail.

Shared Commitment

The daily stand up provides an opportunity for team members to make commitments to each other about the progress they plan to make today towards the team goal. This is a powerful concept. Having team members make commitments to each other about the work they plan to accomplish rather than some higher authority leading the project frames the commitment in a way that increases team cohesion and cooperation. Rather than being beholding to an authority figure who is pushing the team member to achieve some goal, that person is now accountable by each and every member of that team. Peers that, hopefully, are respected and appreciated by the team member. Perhaps most importantly, people that she doesn’t want to let down.

Issue Surfacing

Another powerful concept behind the practice of the daily stand up is the ability to identify ans bring to the surface issues that may soon become impediments to the team. I the example I gave above, few if any of the other team members would have any idea what that individual was working on unless they had the IDs of every user story in the sprint memorized. While this does happen, I suggest it’s not the best way to report status to your fellow team members. What I have found to be more effective is to encourage team members to provide the full title of the task and user story being worked to give the rest of the team the full picture of what is being done. This not only helps the other team members to understand the nature of the commitment being made, it also helps everyone to identify potential conflicts with the work they are doing so that the two can get together after the meeting to discuss their impacts on each other.

Identifying Obstacles

All team members should be encouraged to report any obstacles they are facing at the daily stand up. It’s much better if we can report obstacles as they come up so that they can be dealt with immediately, but we should be doing so at least once each day and the stand up provides us an opportunity for that conversation to take place. Perhaps the most important duty of the scrum master, project manager, team lead, or whatever you call the person guiding your project direction, is to deal with obstacles that the team is facing and remove them. This allows the team to focus on the work that needs be done to deliver the commitment we made to the customer. Make sure that your team is using this time to bring those obstacles out into the open and get them addressed.

Team Alignment

An Agile team should always be moving together towards a common goal that the team has committed to accomplishing. It’s one of the most powerful and under appreciated aspects of Agile development. Make sure that your team is using the daily stand up as an opportunity to report progress towards that goal and identify course corrections that need to be made in order to stay on track.

As I come into new organizations to work with Scrum teams, I often find the team going through the motions of scrum or agile development without necessarily understanding why it is they are doing the things that they are doing. This is the first post in a series in which I will explore the reasons behind many of the processes we use in Agile development. I think it’s important in a methodology that focuses on allowing people to do what works best for them that those same people have an understanding of what the standard processes are all about. My hope is that this can help us to avoid throwing out good standard processes because they didn’t work for us; not because the practice doesn’t work for our team but because we failed to understand the practice well enough to implement it correctly.

All too often, the decision to pursue agile development in general falls victim to this lack of understanding and gets crushed in the process. I think it’s important for us to examine our process and make sure that we are adhering to the principles of Agile development before we decide whether or not Agile development works for us.