From Jon’s “sandwich of the week” to Bob’s musings on object oriented software development, the Huddle blog is nothing if not full of variety. This post will be the first in a new series of ramblings on yet another topic, namely, our Agile software development process. I’ll be focusing on planning, tracking, delivery and project management, as well as team collaboration issues rather than the engineering practices associated with Agile, and today I’ll start with a little bit of background as well some thoughts on one current hot topic.

Firstly, the background. Our development team is split into two sub-teams. Each team has 3 back-end developers, 1 or 2 UI developers and 1 QA. We also have a “spare” QA engineer who works with both teams, and on some cross-team activities. Our process is very Scrum-like, but for historical reasons we don’t use Scrum terminology (iterations rather than sprints; stand-ups rather than daily scrums; iteration demos rather than sprint reviews etc).

We run two week iterations delivering a set of production ready user stories in each. The teams take stories from a shared, prioritised backlog in a joint planning game, but deliver as separate teams within the iteration. Each team, therefore, has its own daily stand-up. We don’t assign dependent stories to opposite teams in the same iteration, so they can usually get on with their work without blocking each other. The teams do not have any specific functional specialisms so, by and large, any story can be assigned to either team. We primarily report on total velocity across the two teams. The team is co-located in Huddle HQ, sunny SE1, London.

The work in a typical iteration consists of a combination of ongoing minor enhancements and stories that contribute towards larger projects. Almost always we develop on our version control system trunk so all changes need to be backwards compatible. We don’t necessarily release to production after every iteration, but when we do we run a week long regression testing cycle (in parallel with development of the next iteration) before we go live.

As I mentioned in my first week here our Agile development team is very good. The challenges we encounter are not as fundamental as those I have faced in some other companies. Having said that, like any good Agile team, we stop frequently to inspect and adapt our Agile software development process.

One topic that is currently vexing me is: how do we know if the team is on track to meet our iteration commitment (sprint goal)? Our track record shows that we deliver around 95% of what we commit to, in terms of story points, but is that sufficient? We have had some less successful iterations and we don’t always have the data we need to anticipate when this is happening and take corrective action. To explain further I’ll list a series of suggested resolutions for our Agile software development process along with why they don’t fully address our needs:

Resolution 1: “Use an iteration / sprint burndown chart.”
Why it won’t work: Rightly or wrongly, our signature story point burndown chart tends to look a bit like this (and that is another topic for another day): so we often don’t know if we are going to make it until the last couple of days of the iteration.

Resolution 2: “So, why don’t you track task level progress in hours, and use an hours burndown chart within the iteration?”
Why it won’t work: We did this for a while. It was moderately useful when the team was very new to the process and struggling to deliver, but as the team became more experienced and more efficient, the overhead seemed less and less worthwhile. As the value decreased, the team’s motivation to supply the data also decreased, so the quality of the data dropped. So, we stopped.

Resolution 3: “This is Agile 101 – your daily stand-up should tell you whether you are on track!”
Why it won’t work: In traditional format stand-ups will not necessarily tell you if you are on schedule to meet your iteration commitment. It’s perfectly possible to describe what you did yesterday, list your commitment for the day and report on any blocks, day after day, accurately and honestly, yet still not provide enough information to ascertain whether iteration delivery is on track. This is because, typically, developers work on one story at a time, whereas the overall iteration scope consists of a series of stories with resource dependencies, and occasionally, technical dependencies. For example, if Bob gets less done than he’d planned in the first couple of days of the iteration, Anto gets ahead and Jenna is bang on track, but Jenna and Bob have a joint story further down the priority list that is dependent on Anto’s story, are we on track to get it done? Who knows!

Resolution 4: “Plan your iteration better. Decide when each story needs to start and end, who will work on it, and build a mini project plan.”
Why it won’t work: Please! Remind me, which do we value more – a) following a plan, or b) responding to change?

Resolution 5: “Well then, if you work on your stories in priority order, and if you work efficiently and sensibly removing blocks as they arise, what does it matter anyway? If unforeseen issues materialise, the lowest priority stories won’t be delivered, and so be it!”
Why it won’t work: Firstly, working on stories in strict priority order is not always practical. We do have some skill specialisms within the teams. For example, if the top priority stories are all backend development heavy, our UI developers will pick up some lower priority items. Secondly, and this is a bit of a guilty confession, I just like to know what we are going to deliver before we get to the end of the iteration!

I’m sure you are all itching to know what we have done to overcome this quandary. The answer is, unsurprisingly, a little bit of all of the above:

  1. We keep an eye on the points delivered day to day and try to spot trends that indicate the iteration is deviating from the normal pattern.
  2. If an individual developer wants to log hours against his tasks to help determine if he is on track to meet his personal commitment, he can.
  3. We’ve amended our stand-up format a little. As well as emphasising “tasks I committed to but did not deliver yesterday” we also quickly review the overall status of each story at the end, and review priorities as needed.
  4. The developers themselves decided to log a simple “target end date” for each story within the iteration, to help retain focus.
  5. We do try to work on stories in priority order as far as possible, and use the stand-ups to divert effort from lower to higher priority stories where possible.

If anyone else has any advice, questions or suggestions on the Agile software development process, I’d love to hear from you! Read more about the Agile Development Process.

Colin Grossman


Request a Demo
trillatron

© 2006 - 2019. All Rights Reserved.