We talk a lot about benefits realisation in project management and probably even more about Agile. But what about the two put together? Many agilists would probably laugh because, for many of them, agile equals delivering benefits so something like “delivering benefits with Agile” might sound a bit obvious. But let’s look at some details.
Agile is a lot about iterative and incremental product building, which in itself should deliver some benefits.
Incremental means you’re adding new functionalities to your product as you progress which makes parts of the overall product available sooner for the end customer. Available for use that is allowing users to realise some of the benefits.
Iterative means you keep coming back to some previously built functionalities to enhance, improve or extend based on some customer feedback. Iterative work won’t give you the perfect product from the beginning, but you’ll discover what “perfect” means by listening to your customers and integrating their feedback, which means building the right product with those features that customers want and will deliver value and benefits.
Slicing Products into Smaller Deliverables
Slicing is not necessarily something new but with Agile we’re taking this to the extreme.
Slices (another word for increments) are delivered at very short intervals of time (another word for iteration) making some features available for consumption very fast. And yes, “very fast” is being redefined every day: from sprints of a few weeks to a few deliveries every day, a very common thing is DevOps.
How is this related to benefit realisation?
Every slice is going to deliver small functionality from all the relevant features making it a working product that can be used. Here’s a simple example:
By taking a sprint of two weeks, a team can deliver a slice of an e-commerce website which will allow end customers to search for a product, see its details, add it to cart and even pay for it. Now, that might not be the best user experience in the world; maybe some key elements are still missing, but a user can buy a product online. Which is what the overall product is all about.
You give this slice to your potential users and they can receive the main benefit of the e-commerce website: buying products online. Some would even argue that this first slice of functionality will deliver maybe 20-30% of its features. But we’ll talk about prioritisation later.
Minimum Viable Product (MVP)
Maybe you won’t release that first slice, but with just a few of those slices, you’ll get your Minimum Viable Product (MVP).
That’s something you can put on the market and from that moment on it is your real end-user who is going to take over your product. They’ll choose which features are valuable and which are not, what they like and what they don’t and more importantly, what new features they want in the product.
The MVP approach advocated the “better done than perfect” philosophy in which you make it perfect by including your customer’s feedback. Besides, for many products, there is no “perfect” – a simple product might just do. If you look around, you’ll discover that some of the most successful products today are just a bit more complex than a MVP.
You don’t add new features unless their value is proven. Unless customers are asking for it, this will avoid one of the biggest traps of product development today: not saying no to ideas! Most Product Owners (or Project Managers) just can’t say no to some ideas, and they tend to integrate everything into the product. The result? A very complex product that does a lot of things for a lot of people.
Which is not that bad except building all those features could be expensive and also “everything for everybody” might not be ones’ idea of value.
The Product Backlog
The way we express requirements in an Agile project is another practice with high impact on benefit realisation. Simply, the product backlog is the place where you keep all the requirements, needs, wants, ideas. It doesn’t mean everything from the product backlog will be delivered. Maybe some items are not valuable or maybe some ideas are impossible for now.
But there are a few things which make the product backlog very special: user stories and backlog prioritisation.
User Stories
User stories are how we express those requirements. They’re just a simple statement, usually written following this template:
As a {user type},
I want this {functionality},
so that I get this {benefit}
The immediate benefit of every functionality is part of the functionality description.
One thing becomes very clear from this statement. User stories are written from the end-user perspective. In other words, we try to express everything we have to do or build as if an end customer would describe it. We use their perspective and as much as possible their words. The advantage is that this will make the team who builds the product always think of the end customers when they build the product.Fast Track Agile Learning
So, at any moment, the team is going to focus on benefits. Another advantage of expressing requirements this way is that if something is not valuable for the end customers, it will be questioned and challenged. It might be that some functionalities have no direct value they might be required or necessary for the overall system to function.
In this case, the team will try to be as creative as possible in finding a solution without wasting too much time on this. They have to dedicate more time and energy to those user stories that do add value and deliver benefits.
Backlog Prioritisation
Backlog prioritisation is the main technique to ensure whatever you deliver is considered valuable by the end-users. As previously said, the product backlog is a collection of everything. So, quantity comes first – many ideas, all the ideas!
Afterwards, however, it becomes about quality. At frequent intervals (sometimes all the time) the Product Owner (we’ll talk about this role very soon) will look through all the functionalities and make some decisions.
Those that deliver most of the value will be given a high priority, those that don’t, get a lower priority, which means that quite often they will not even be built anymore. A prioritised product backlog is a list of functionalities ranked by their value for the end customer.
How do you do that?
It’s quite simple: you look at the benefit associated with every user story and try to understand how important that particular benefit is for the customer.
A well-prioritised backlog will be a clear reflection of the Pareto principle: 20% of the functionalities should deliver 80% of the value of the whole product. Sometimes, in some cases, it is even more than that: 5% of the features might deliver 90% of the value (again, think Excel!)
Every Agile approach (we’ll use this word instead of “methodology”) there’s a role whose job is just that: making sure the product delivers value.
Most popular title for this role is Product Owner. The responsibility of the Product Owner is to build (with the team) and deliver the product but most important, to build the right product. By “the right product” we understand a product that people want and find valuable because it delivers a benefit.
Without going into details, the Product Owner has a few techniques that will help:
– writing user stories (keep the end customer perspective on things),
– plan an iteration (deciding on a slice of the product backlog that will be delivered in the next iteration),
– review the iteration with the end customers and get validation and new ideas,
– provide the support during the iteration for the team who’s building the product assisting them with anything they need,
– making sure whatever is built during the iteration is something of value.
What makes this role unique is attention and focus on delivering value and benefits. Nobody wants a product; they all want a benefit or a solution to a problem. And a product is just that: a means to an end.
We saved the best for the end. Agile not only deliver benefits, it does that in a very efficient way. Products developed using Agile tend to be cheaper. Yes, most people will probably smile at this, but it should be one of the benefits of doing Agile.
An Agile team will take efficiency very seriously. Again, without getting into too many details, here are a few examples: every day the team is doing a quick check of the progress to make sure there are no impediments or blockages which normally cause delays and extra cost. If there’s a problem, they will consider fixing the problem as the highest priority.
Also, at the end of every iteration, the team will do a retrospective of the last iteration. What worked well, what can be improved and how can we deliver more results next time. And as we all know, more result per iteration is the very definition of efficiency.
In conclusion, Agile does help a lot when it comes to building something of value and delivering it fast, so those benefits are realised. We just tried to look at some aspects of benefits realisation in an Agile project, but this is a vast topic. The best way to discover what Agile has to offer is just to start to do some Agile and embrace a key pillar of doing Agile: fail fast.