Huddle's Blog

Agile development – bendable, poseable

Posted on 12. Mar, 2009 by Colin in Development, Huddle Life

We’ve banned Andy from playing Hot Chip on the Huddle HQ office stereo, as he is a little bit obsessed.   You can have too much of a good thing.  Bizarrely, however, one of the tracks from their latest album has got me thinking about our Agile development process. Bendable Poseable. The fact that we value responding to change over following a plan. Agile.

Here at Huddle, I think we are especially good at this.  Our developers strike a great balance between flexibility and guarding against scope inflation that could jeopardise the successful delivery of a feature.  Within a given story, the rule of thumb is pretty simple.  If the customer requests a change during development, and it can be completed within the estimated effort of the story, we always do it.  Why wouldn’t we?  Often the distinction between a change and a clarification is subjective anyway.   If the change cannot be implemented within the estimated effort, then we have a potential change of sprint scope.

Scrum dictates that you never change the scope of a sprint once it is underway.  In previous roles I have fought tooth and nail to enforce this rule.  The concept of allowing the team to focus for the duration of a sprint, without distraction, without the need to spend time re-planning, and without excessive context switching, always seemed very attractive.  At Huddle, however, we frequently ignore this rule and make scope changes throughout the sprint.  Of course, we only make these changes if there is a valid business reason.

The most common reason is the most obvious.  If the team is ahead of schedule, and is happy to commit to delivering extra stories or bug fixes, we add them into the sprint.  Recently, this has been happening in almost every sprint.  This may imply that we should be committing to more up front, of course!

Secondly, if the product team change their mind, and would like us to implement a story that wasn’t planned for the sprint, and if there is a story of equivalent size in the sprint that we haven’t started work on, we swap them over.  If the team are comfortable with the change, again, why wouldn’t we?

Very occasionally, however, unforeseen events arise and we have to make more challenging trade-offs.  Something comes up very suddenly that we just have to do immediately, and there is no slack in the sprint schedule.  This is slightly different from the product team requesting a swap, as nobody really wants us to drop anything from the sprint.  This kind of change would have made me very nervous in previous jobs.  Whenever there is pressure to “just sneak something in”, quality drops and bad things happen.

At Huddle, however, these changes no longer give me the fear.  The reason for this is that we practice what we preach – open, effective, honest  team collaboration.  The developers tell the customer which of the low priority items need to be dropped from the sprint, and the customer accepts it.  No tantrums, no hissy fits.  The developers trust the customer to only request these changes if the business case justifies it, and the customer trusts the development team to be flexible and pragmatic.

An important part of any Agile process is customising the process to suit your needs.  I would strongly recommend, however, that the more newly formed your team is, the closer you stick to the textbook guidelines.  Especially if there is not a lot of prior Agile experience in the team. Scrum was devised by folks with big brains and lots of battle scars!  As the team gels and becomes more comfortable working together, it will become evident which changes need to be made to optimise performance. If you do decide to ignore the “no change in scope during a sprint” rule, here are my top three tips:

1) Make sure the development team and the customer have a strong relationship and trust each other’s judgement.

2) If the developers are loudly saying “no” to something, it’s probably a bad idea.

3) Don’t forget QA!  A change that appears quick and easy to code may be a nightmare to test.  Assess the riskiness of a change and test accordingly.

As always, I’d love to hear your thoughts on handling scope change within a sprint, and other Scrum dictates you choose to ignore!

Tags: agile, development, team collaboration