Tag: value

Delivering Value

It’s fundamental to Agile! The first of the Manifesto’s principles is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”; Modern Agile has four principles, which includes “Deliver Value Continuously”; Heart of Agile says “Deliver small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes”.

So who defines what’s valuable? I expect it would usually be your customer (conveyed by the Product Owner) but identifying them can be tricky. Not everything in the product backlog is destined for an end-user; you could be building internal tools (then your customer could be other dev teams) or for yourself. The key thing is identifying what “value” means – this helps the team understand why the work is important as well as where they’re heading. User stories should focus on the “why”, the goals and benefits.

Once the goals are clear, how does a team deliver value? Incrementally, getting frequent feedback to allow them to make adjustments towards meeting the customers’ needs. I like Heart of Agile’s additional mention of “small probes” – taking small steps at first, as you discover more about the goals, technology, etc. As the team become more confident they may want to take larger steps but, in my experience, even when you’re “100% sure” what to build next there’s always a surprise in store. It’s like gambling: don’t risk more than you’re willing to lose – don’t build more than you’re willing to throw away once you get feedback.

Finding value

As part of the warm-up for a retrospective this week we were asked to share an article of clothing which represented the previous sprint. I picked a photo of a jumble sale because I felt we had been trying to find the value in a pile of possibilities – there are many things we could do, but which is the “best”? At a jumble sale, you really shouldn’t try something on then put it back and repeat until you find the thing you want; however, we have the benefit of being able to conduct small experiments to see if we’re doing the right thing.

By taking a small step and inspecting the outcome we can decide whether to continue going in that direction, make a small tweak based on what we’ve learned, or maybe go back and try something different.
To avoid any cognitive bias we should be clear beforehand what criteria we will use to analyse the outcomes; stating those criteria also helps identify any metrics we should collect.
For me, this is the heart of agility – short feedback loops that enable us to learn and react. That reaction helps us deliver what our customers need, and stop working on something as soon as it stops providing value.