The 12 Days of Agile Principles! Principle #7
Inspired by The 12 Days of Christmas we’re exploring the principles behind the Agile Manifesto. Originally defined in 2001, The Principles of the Agile Manifesto are still highly relevant to Agile approaches today. So like an advent calendar of Agility, we're unwrapping one principle each day for the 12 working days - Monday to Friday, leading up to Xmas. By the time we conclude we should all be in the festive spirit!
*****
Welcome to DAY 7 of ‘The 12 Days of Agile Principles’…
PRINCIPLE #7
Working software is the primary measure of progress
This slightly problematically worded principle only refers to software and very much a technology driven view of the world, we’ve evolved to know a lot more than we did in 2001.
In recent years the rise of the customer experience and the publication of The Lean Startup by Eric Ries was a welcome injection of logic into the agile software delivery world, because we had become pretty efficient at building the wrong thing using our agile processes, assuming that our order taking of requirements from within the business was good enough - it wasn't. Now we strive for validated learning, from real customers of our products to ensure we are solving customer problems with the things we deliver. So working software may be the primary measure of progress to an Agile team, plus validated learning from customers must follow as almost as valuable, in fact, if your validated learning proved to you that you didn’t need to create any working software at all for your solution, maybe more valuable!
However, at the heart of this principle is essentially the idea that a document (Requirements Documents, Functional Specification, Detailed Tech Spec, Solutions Architecture Document etc.) isn’t something of value in itself. “What?!! I happen to find my documents super interesting!” I hear you say. Well if you asked a customer of your on-line product who was using your website whether they wanted to see the requirements document behind the software they are using, I think they might not find it so valuable. This principle serves to remind those who get too caught up in documentation that it’s of comparatively low value. Therefore it follows that processes that are set up around the creation, review and governance of said documentation is also of no value. Set your processes up around the creation, review and governance of working features and functionality instead, stuff that will actually create value in the hands of your customers.
So Agile leaders will serve their teams well to ask themselves three questions at the end of every iteration: Is my team happy? (see Agile Principle #5) Did our team deliver what they said they would deliver? AND Did our team deliver working software? Don't bother showing me a presentation pack at Showcase, I want to see real working stuff.
And in case you’re wondering, working software doesn’t mean “It worked on my machine” it means working, tested and accepted, and will not explode if you ship it.
***
Continue on to Agile Principle #8 or join the conversation at @TheRebootCo.
#12daysofAgilePrinciples