The definition of what: regular increments of valuable software. That’s all there is to agile.
In agile development we don’t like to specify to the tiniest detail before we begin coding or estimate the cost down to the last euro. It is a pointless exercise because building complex software is like travelling uncharted territory on foot: you cannot tell how hard the journey will be from a reconnaissance flight. Until you get your feet wet you cannot predict how hard it will be or how long it will take. That’s the definition of a complex, adaptive domain. Like the time I decided to climb Table Mountain in Crickhowell (Wales). It looked a lot less steep from our holiday cottage (left photo).
Say you want to lose weight and think that shedding five kilos over the next six months is doable. We’re talking about a very simple goal and a clear timeline. So you cut out sugary snacks and take up running. But how do you know if the goal is realistic or even sensible? The agile way of going about it would be to forget about the target and timescale altogether. Instead, you aim to improve your physical and mental wellbeing through measurable improvements in your lifestyle little by little, week by week, rather than obsessing about the number on the scales. If it makes you feel better, if it adds value to your life, you can’t be doing much wrong.
Same with agile. There are countless applications we can build, several ways of building it, but the single goal of every agile team should be to deliver regular increments of valuable software. I call it the definition of what, just a paraphrase of conventional wisdom that should not even be controversial — in my opinion.
Regular increments ensure growth at a predictable pace. We release the product bit by bit because we cannot cast our vision of the final product in stone when we start, nor do we wish to. There is no value in striving for first time right. As the software grows and the world around it changes, so do our ideas about what it’s for. This leads to new insights, hence new features, different features, fewer features. How you should interpret ‘regular’ is open for discussion, but if you can’t manage a monthly release you clearly have room for improvement. Still, regularity is more about cadence and predictability than number of releases per year.
What we release should always be valuable. I like that word. It is deliberately subjective. It invites further questions and assumptions, but that’s a good thing. Value goes beyond profitability. It’s hard to judge the value of software features before they are built, when they are still theoretical. You can try to predict it with a formula but that’s a poor substitute to assessing it from real results. That’s why detailed up-front design is so impossible to get right. Your value judgements are only best guesses, and you can’t possibly be right every step of the way. With a working increment of software under your fingertips you are so much better equipped to evaluate its value.
Valuable packs a lot of other positive attributes, like easy to use, free of bugs, fit for purpose. Think of all the *-ility quality attributes and how they all degrade the overall value when they are lacking. Where’s the value in a miserable user experience or needlessly steep learning curve? How can a program be valuable if it keeps crashing? As to fitness: no matter how cool the developers think it is, if the end user has no need for it, it has no value for them.
I’m not hung up on quantifying development output, expressing velocity as a number of story points per iteration. Value is a subjective notion whereas story points are a measure of effort, not value. You don’t need a burndown chart to sense when your valuable output is slowing down: the stakeholders will tell you. And even if it’s not immediately visible in the product, team disfunctions, technical debt and hidden defects will enter into the equation sooner or later. They bring down the team’s ability to deliver and this means either more time between releases or less value per release. Anything that can go wrong in the process will manifest itself in output and value. The regular release is the perfect opportunity to inspect and adapt before things get out of hand.
One final remark on the definition of what has to do with the changing, malleable nature of software expressed in the word regular. Yes, some software is burned on ROM chips never to get a firmware upgrade. But your average tax return app is never finished, and that’s a good thing. To remain valuable in a changing word the goal cannot be a single piece of software, but a stream of software. Don’t you just love a business model like that?
