30 June 2011

A Survival Guide for New Agile Coaches - Are We There Yet?

I recall driving to Toronto one time with the kids.  It's about a 4 hour trip, and somewhere around 30 seconds after we left my son asked, "Are we there yet?".  Of course, I patiently responded, "No, we have about 4 hours to go!"

After another hour and several thousand additional queries about our arrival status, I decided to change things up.  When my son asked, "Are we there yet?", I cheerfully responded, "Yes!"  He answered, "No we're not!", to which I not-so-patiently responded, "THEN DON'T ASK AGAIN!!!".  He had nothing to come back with, and I basked in my victory for at least a few minutes.

Coaching Point

There are a number of points that can be taken from this story.

First is the need for releases that are as short as possible.  When you work away for months at a time and can't see the goal towards which you're working, your motivation can erode somewhat.  Imagine climbing a hill shrouded in fog - you just keep climbing and have no idea when you're going to reach the top.  You may eventually become bored with the climb and start back down, when in fact you were only a few metres from the top that you couldn't see!  Release cycles of 24, 18, 12 and even 8 months can have this effect, whereas cycles of 1 day out to 6 months are within "sight" of a team, allowing them to focus better.

Second, there are situations and or products that do require longer cycles (at least initially).  Visual management can help communicate your current and projected locations reasonably well.  For example,
I now like to use our GPS for any long trips even when the route is well-known and we don't really need a map.  Our GPS also shows Distance Remaining, Distance to Next Waypoint and ETA/Arrival Time.  Everyone in the vehicle can see this information and as a result the question in the title of this post is now rarely, if ever, asked.  What information could you display for your project or product that could achieve this?

Third, teams that have been using an Agile process for a good length of time can find themselves in a rut or becoming caught in the daily and iteration-length 'grind' of the process.  On several occasions I've heard team members and even entire teams speak of working away from Iteration Planning, through the iteration, performing a demo, holding a retrospective and then get right back into the next Iteration Planning.  The common theme has been, "We don't have time to catch our breath!"  This can be a symptom of a few issues:
  • No slack built into the iteration to allow for unexpected work or work that was larger than expected
  • No slack built into the iteration to allow team members to 'sharpen their saw' or to spend a small amount of time refreshing their minds
  • This may sound silly, but the use of the term "Sprint" for Iteration - the words we use can and do affect they way we perceive the world.  If a team is constantly "sprinting", they can have the feeling that they're out of breath at a certain point
The key here is to understand that you can't simply fill every single minute of time within an iteration with work directly from the backlog.  Not only is that unrealistic, it will burn out the people on the team.  The excellent book Slack by Tom DeMarco says,
Slack is the lubricant required to effect change, it is the degree of freedom that enables reinvention and true effectiveness.
In other words, by giving teams some time where they aren't working on their regular work, they will be more effective and efficient.  They may also come up with new ideas and even products!  Regardless, look for ways to allow team members to recharge.  Ask the team for ideas, or suggest some team-building activities or even just some 'free' time off, i.e. not charged to their vacation.

Finally, you need to consider what questions are really being asked.  When my kids were asking, "Are we there yet?", the real question is, "When are we going to get there?"  I solved that problem somewhat by using the GPS which displays that information, although when the kids were younger the concept of 3 hours was as abstract as 3 days or 3 months!

If a team member says, "We're stuck in a rut... one sprint after another with no time to breathe", what's the real issue?  Do they have any slack?  Not enough slack?  Is there external pressure to do more, requiring communication with stakeholders?  Do they need to go out for a beer after the iteration demo and forget about the retrospective and iteration planning until Monday?  All of the above?  The point is to not necessarily take the question or statement at face value - try to identify the real question or the root cause of the statement.

While you can simply answer, "No" to the question, "Are we there yet?", that rarely appeases the person or people who ask it whether they're 3, 33 or 63.  Ask yourself what you can do or suggest to either find the real question, make the information required visible or even change the circumstances such that the question never needs to be asked in the first place!

2 comments:

Klaus Even Enevoldsen said...

Good post. I think "sustainable pace" describes what you are saying well. We need the agile teams running at a sustainable pace and not sprinting all the time. But it is ok to sprint sometimes, but not for too long. In the team that I work with we usually sprint on our own initiative, there is no one that demands it of us.

Something that we don't do, but maybe we should, is to have FedEx days or 20% time.

I think there is a lot to learn from Daniel Pink's book: "Drive - The surprising truth about what motivates us". Intrensive motivations like autonomy, mastery and purpose - Agile can meet all three when done right!

Adrian said...

Nice post. I was stuck on a plane on the tarmac recently for over 2 hours while a kid in the row behind me kept asking "are we there yet?". If you think it's bad when you're driving - consider it when you haven't even left yet !

I guess the challenge in a longer term agile project is the fuzziness of epics that are further out make it difficult to see the top of the hill. Defining milestones, or higher level deliverables, can help to cut through the fog a bit. Though you still can't see how far away the summit is, at least you can track your progress in milestones.

One final point: I think the depiction of progress (burn-up, milestones, etc.) needs to be hugely visible to the team - not just buried in a PowerPoint that gets thrown around on occasion. It needs to be in a big visible chart so that everyone can see the progress.

Thanks again for the great post.