Jeff gave an entertaining presentation on strategies for coping with the inevitable changes that take place during a project release. The talk was punctuated with blasts of music from various artists filling in as personas, from Mel B as a developer capturing user stories (“So tell me what you want, what you really really want”) to Johnny Rotten as an experienced agile practitioner (“Don’t know what I want, but I know how to get it”).
Many companies are now adopting agile methodologies such as Scrum to jump on the agile bandwagon, and are looking for consultants to provide training, and to come in and tell them all the answers to their problems. Because they are looking for prescriptive processes that they can put in place for people to follow, we are starting to see ever-more complex systems for things that were previously considered simple tasks (such as prioritising user stories). This is what Fred Brooks referred to in No Silver Bullet as ‘accidental complexity’ – complexity in the activities around writing software, rather than in the domain of the business problem you’re supposed to be solving.
Is this process rigor, or rigor mortis?
We have forgotten the meaning of iteration, and are working in increments instead. We are expecting an ‘iteration’ to contain a number of fully-completed stories, which we can then forget about and move on to new features. The problem with this is that when we deliver those stories, the customer is not entirely satisfied, and we have to introduce new stories to refine the design. This in turn affects our velocity, because we find ourselves spending more and more of our time enhancing features that we thought were done.
It’s not iteration if you only do it once.
Alastair Cockburn has suggested a ‘three story’ approach, where you make the iteration explicit by putting two additional cards behind each user story – one to fix the original story, and another to fix the second attempt. Jeff’s only concern with this was that people might take it too literally, doind a seond rework even if the customer was already happy, or stopping after the third story when the feature clearly wasn’t really done.
Along with YAGNI, Jeff suggested adding YAGRI (you ain’t gonna release it). This was to remind us that it’s OK to present non-production features to the customer, in the knowledge that they won’t be released until they’ve been iterated into a deliverable state. To me that seems OK for shrink-wrapped software and other things where iterations aren’t released, but I wonder how it applies to web applications, where it is becoming the norm to release small changes frequently (perhaps multiple times per iteration). In that case, we’re used to making the assumption that everything is always releasable. Maybe the answer is to separate new, ‘beta-quality’ features from the main body of functionality.
Three strategies for coping with the inevitable uncertainties in building a release were described:
Follow the Money
Prioritise the business goals. By focussing on the things with the highest value to the business you restrict the user constituencies which you should target first, and hence identify the highest priority user stories.
Don’t Choose the Solution Too Early
Focus on the user goals rather than the perceived requirements on the application, and consider and discuss alternative ways of meeting those goals. It may be that a simpler or cheaper implementation than the immediately-obvious one may be sufficient.
Build up Quality in Iterations
Sometimes the customer really does need everything to be implemented before the product can be released. In this situation, you can start by implementing stories to a very basic, almost prototype, level. You then build up the quality iteratively, using feedback from the rough-cut implementations to guide you. One way of doing this is to grade each story (eg A+ down to F, plus I for incomplete), then have a ‘passing grade’ at which the feature is considered fit for release.
One consequence of actually iterating, rather than using ‘iteration’ as a label for an incrementl chunk of functionality, is that there’s a lot more work for the customer (or product owner, or whatever you want to call them). They need to work frequently with the developers to evaluate each version of a story’s implementation and describe the changes necessary to make it fit their needs.
The summary of the talk was to question common practice and to trust your instincts. As an aside, that leads into a rant I keep meaning to get round to, on the subject of people who say that a particular behaviour “isn’t agile”, because it doesn’t fit the letter of their particular methodology of choice. Watch this space.
[tags]xpday, iteration, agile[/tags]
Traditional approaches to motivation tend to fall into one of two camps: the carrot (“do this and you’ll be rewarded”) or the stick (“do this or you’ll suffer the consequences”).
There’s an article in today’s Guardian called 