There are two keys to successful agile software development.
Two, because successful agile software development is a union of successful agile business process and successful agile technical practice.
On the technical side, the key to success is the continuous pursuit of technical excellence.
As Uncle Bob puts it, “The only way to go fast is to go well”. He also points out that “the primary value of software is that it is soft”. To succeed in agile where technical practices are concerned, means retaining the ability to change the code, to add new features, to evolve the design, to release new functionality, and to be able to do all of those things quickly. Pursuing best practice in areas like TDD, BDD, continuous delivery, continuous inspection, simple design, evolutionary architecture, and of course good old-fashioned SOLID code is what stops code rotting and prevents the technical efforts from gradually getting slower and slower. Keeping up to date with those things as the software community learns and improves and evolves is vital too – as a software craftsman you’re never done learning. Exploiting developments in technology, advances in frameworks, and evolution of languages, are also essential. Principles, patterns, practices, and tools, along with training, learning, and engaging with the wider software development community, are all essential.
All of those details fall under that one headline – “The Continuous Pursuit of Technical Excellence”.
On the process side, the one headline that summarises the details is this: “Value Driven Development”.
(Those two headlines – value and technical excellence – amount to saying “The right thing, the right way”, which is hard to argue with.)
If you’re guided by value-driven development, and understand that what that really means is developing a product bit-by-bit, starting with the most important, the most valuable, before adjusting and repeating with the next most valuable, and if you understand that “value” comes from a combination of things like potential revenue, potential penalties, technical risk, technical uncertainty, the actions of competitors, marketability and so on and so on, then you will avoid the classic mistakes of spending time and money on things that aren’t important, or having technical people working on technical things that business analysts or expert users or product owners don’t really understand or care about thus failing to engage the collaborative power that steers development in the right direction.
So if the value of the next chunk of development is so important, isn’t it odd that the most commonly used format for user stories puts the value last?
The Connextra format (As a… I want… So that) is a widely taught format for user stories, especially for teams new to agile. The idea is to help people avoid writing technical stories from a technical perspective, and to think not just about the required functionality (I want), but also defining and scoping the work better by thinking about the beneficiary (As a) and the value (so that).
The value is the last thing. I so often see teams who know what functionality they want to build next but waste time struggling for a while to make up some user for the “As a” part, often coming to a standstill if the “user” is a system actor or some project stakeholder and not an obvious type of human, mouse-clicking, screen-reading user. Then they tie themselves in knots trying to phrase it in a way that works with “I want” from that user’s perspective. By the time they get to the “so that”, they’ve lost interest, given up, have already invested so much time in the first two lines that the “value” is now locked in, unquestioned. We’ve made all this effort so we’re obviously going to do it…..
This is why I prefer a value-driven format. State the value first. There’s an equally simple format for this, that can easily be taught to and understood by inexperienced teams. Start with: “In Order To”.
When the first thing is “In order to”, then you can’t go anywhere until you’ve understood why you need to do this thing.
The simple act of discussing “In order to” in a story writing workshop, or in a backlog grooming session, or in a release or sprint planning session, so often causes people to discuss the real reason, the real value, sometimes to question it, sometimes to confidently back it.
That really helps prioritisation, it really helps with deciding what should be in and out of scope for that story, and it really helps ruling out things that aren’t yet needed, that aren’t actually being driven into existence to create some bit of “value”. It really helps you avoid doing work that isn’t yet justified, that can be deferred, and it gets you to focus on the things that help you make progress, that get the right feedback, answer the right questions and move you closer to completion.
If it’s so important to identify why you’re doing something, make that the first thing on the story. By the way, the logical way to continue means that identifying the “user” for the story is the second thing to tackle, whereas the easy bit, the bit you already know, the “I want”, comes last:
In order to…