Tuesday, November 24, 2009

Agile adoption: Four months in.

Actually I'm not sure if it's four months, it could be a little more, could be a little less. But that's close enough. In some respects I wish I had taken time to blog about this much more frequently, as I think it would have helped me distill my thoughts on how things were going. Possibly even a slim chance someone else may have found it interesting too ;-) But I didn't. I'm going to attribute that to a lack of habit, and maybe I can cultivate that habit more going forward. On the upside, having gone four months or so before posting my thoughts on adopting agile practices, I do feel that I have got a fair bit of experience that has some value to it. Perhaps earlier posts would have comprised vacuous meanderings around the topic of no interest to anyone.


Now I try and think back, I'm not 100% sure I can entirely recollect what the trigger for the turning point was. The best I can remember, there was some...shall we say, doubt or perhaps concern over whether a particular project we were running was going to be feature complete on time. Let me explain a little bit about where we were at this time:

  • we had a slew of software engineers (by our standards anyway) working away on this rather undefined "refactoring and re-architecting" phase of a major product release
  • somehow, despite some top level goals for this phase being set, there was next to know clarity on what was really going on, nor whether it was worthwhile
  • our customer certainly had no clue what was going on
  • the deadline for delivery had been fuzzy until recently
  • we had some nasty combination of huge horrible "the system shall" type requirements documents, use cases that were more use-less cases
  • nobody had a clue what the QA members of the team were doing besides "regression and exploratory testing"
  • the team was working in two week iterations, although they seemed rather purposeless upon closer inspection; the only thing that they seemed to do was ensure we more or less regularly provided a new build to QA
  • the quality of the builds was low, often emergency "patches" were needed to remedy showstopper defects that somehow made it out to QA
  • nobody was pair programming or doing TDD; the unit tests we did have were...let's just say sub-optimal *cough* not working *cough* or commented out *cough*

Anyway, back to the plot. So in a conversation about the need to critically evaluate whether this project was going to succeed, I may have blurted out something about my distaste for estimating in hours and how we should use points. I had done a little reading on this topic and sensed the potential -- estimating the work left in points and measuring velocity would give us a much better feel for progress I believed. They say you "should be careful what you ask for, as you may just get it" and yeah, I got it. So I went away and read a bit more (should we do S/M/L t-shirt size estimates? Fibonacci sequence?) before probably delivering the most disruptive message ever to my developers the next day. "Yeah this is Jon. I thought it'd be a great idea to estimate what we had left in story points. Have you heard of them? No. Don't worry. We're just gonna give it a go..."

I actually had us doing this wrong of course. Rather than estimating as a team I "pair estimated" with individual engineers for features they were responsible for developing. At this stage this was the expedient approach and looking back I still maintain it was better than do a "how many hours/days of work have you got left?" exercise. There was no QA involvement in these estimates, but I think that trying to get their involvement would have been too hard at that stage.

We settled on using 1, 2 or 3 as valid values for estimating our stories, mostly because it seemed simplest to get people to think about whether something was "easy, medium or hard" rather than agonize over a more complex set of choices. At this point I hadn't read any good material on what made for a suitable story, so many of our stories were tasks. With hindsight, although clearly not optimal this *still* was a step in the right direction.

It took the best part of a day for me to work with each of the engineers on the team and get their points based estimates for each of the stories (or tasks...) they believed they had left. Once this was done though I felt a distinct sense of progress. It was somehow easier to think in terms of there being about 100 points of work left, and how this therefore implied we needed a velocity of 20 points an iteration (not real numbers, but you get the point...)

With the "stories" and their corresponding estimates in a spreadsheet, and a daily stand up we suddenly started to be able to understand progress like never before. It was euphorically exciting to feel this degree of comprehension and transparency available to us. This feeling was a fleeting thing at first, but as iterations passed by and the velocity stabilized I think we all felt better about predicting success.

Stand up meetings were initially hard. People were late. People rambled. People didn't see the point. The chickens (myself and other managers) interrupted gratuitously to "coach" people on doing it right. We were eager but perhaps ineffective. Stand ups took ages. But, interestingly, we went from weeks slipping by with hidden issues, to impediments surfacing daily. And we'd solve them, or people would agree to work on solving them there and then. This was our second big win after understanding velocity I think.

With a toehold on our agile adoption, we were starting to build momentum. We have done much more since then, which I will write about it follow up posts to come.


  1. from a developer perspective..here are my views,
    1.the standups and retrospectives are the best part in our agile adoption.it definitely helped us resolve roadblocks quickly and find solution to many of our long standing issues.
    2.yes..we seem to have a better clarity on what we are doing.
    3.did the points estimating really helped us??i personally could not see the benefits out of it.
    4.i agree that TDD and build quality has improved a lot- but is it because of agile adoption??i doubt it.
    i remember like u & jim talking about nightly build and Staz(artezio) working on pulse even before our agile adoption.

    without going into too many details, to summarize in a standup way,
    1. what worked well? standup and retrospectives
    2.what did not go well? points based estimating and the expectation of all teams moving together during a story
    3.roadblocks? No :)

  2. I will follow Ram's lead and add on my comments the "retrospective way".

    What worked well with me? Better visibility into what the team is doing - leading to better collaboration

    What didn't work well for me ? 1) Increased communication 2)Decrease in through put 3) Not clear understanding on how to deal with Stories and requirement specs

    Roadblock ? Would like to see product owner as part of the team- as a pig rather than a chicken.