page title icon 4: How Agile delivers value into an organisation

In this podcast we discuss how an agile approach can add value versus old school waterfall methodologies.


In this post we’re covering how Agile delivers value into an organisation. There’s an awful lot out there on agile – the actual process of implementation – but less on how it actually delivers value, particularly compared to the traditional waterfall approach. So how does Agile add the value that waterfall doesn’t?

So the first thing is to actually define what we mean by value? Well it’s delivering new or improved capability into the organisation – that could be a new or improved product or service, or perhaps increasing efficiency such as automating a process.

Ok so that’s the very simple definition of what value is – so how does Agile deliver that more effectively than a waterfall approach? Let’s just briefly cover what you’re going to need to start a project – that’s the Product Vision. The Product Vision is owned by the Product Owner – they will be leading that and will make the key decisions. Ideally they will involve the whole team and during the project you can expect it to be refined as the project proceeds. The vision should contain the fundamentals of what we are aiming to achieve from a business perspective – why are we doing this and what do we think that the value gained is going to be? Ideally you’d also want to define what the output should be – i.e. what does ‘done’ look like – it may be quite difficult to establish that right at the start so it may be refined as the project goes on.

From the vision we are going to create our product backlog – that’s basically a list of work that needs to be done – and the items will then be prioritised based on the value (or perceived value) that is going to be delivered for the business and for the user.

The product owner will make the decisions by defining which items of work are the most important. That can be quite a challenging task in an organisation to actually get the business or get the product owner to make the decisions – but they have to do that! So you are immediately gaining value, because you’re having a discussion around what is actually going to deliver most value.

Let’s assume we are using Scrum. The goal of scrum is to deliver shippable product at the end of each sprint – that’s what it says in the manuals – but we all live in a real world and we know that particularly in the early sprints we may not be able to do that. Realistically it might be 2 or 3 sprints before we are able able to deliver a product that somebody could look at.

A term used quite frequently is Minimum Viable Product (MVP) – I’m really keen on this personally – and have seen this work quite well a number of times. What we are trying to achieve out of having an MVP is a prototype that demonstrates the viability of our product. The actual functionality could be quite simplistic, but it enables very quick feedback on the viability of that solution. You could well find out the product dramatically changes after that initial feedback – the initial presumption may be that it does X and works in a certain way – this may dramatically change and that’s a GOOD thing because you haven’t spent a shed load of money & a shed load of time. OK you have some sunk cost, but it’s not as much as it would have been if you had managed a waterfall project where you delivered a huge product and it hasn’t worked out as expected!

Then moving on to the minimum marketable product (MMP) – as the name implies this is something that is good enough to release into the market and start charging money for the product or service. It’s not going to be the finished solution – there are going to be more iterations or releases – but at that point you’ve delivered value into the organization.

A huge benefit is that because we’re delivering visible product – we have something to show our stakeholders and product owner – that makes it so much easier for them to understand what the product is doing. Even though they might well have some UI/UX mockups or wireframes, there’s really no substitute for actually seeing the product. They’re seeing what it does – I see this often – it will then generate a bunch of ideas. Once they fully understand what it can do, they then say “actually it could do this as well” or “it could work in a slightly different way and it would give us this value” so there is benefit in users and senior stakeholders being able to see the product and then being able to generate feedback around that.

Right at the start of the project we did our product backlog – we went through it, prioritised the items and delivered our sprints based on those – but further down into the project we then want to take the opportunity to review. We’ll do that as a group – this session is commonly called ‘backlog grooming’ – we review the backlog and challenge the decisions that were initially made. Is the priority still valid; have we introduced new items? Which are now the high priority and delivering more value? We’re also taking the opportunity to revisit the vision. Are we delivering on the vision that the product owner has articulated – that’s really really important.

There another aspect of of agile – by running regular sessions such as sprint reviews & sprint planning we’re able to keep the focus on user needs. We can keep challenging ourselves on that on a regular basis – we can measure our success and make sure this is communicated out. Again there are benefits in focusing on the vision – we keep going back to that and saying “are we meeting the original vision, or has that vision changed in some way?”

Another area where agile adds value – it’s delivering incremental change. Organisations are bad at accepting anything new – that’s classic change management. If you’re delivering something in a gradual way, where the changes are not so big, the challenges around adoption are going to be less. Having said that I think it’s probably true to say that quite often adoption can be the bottleneck so it’s not necessarily the ability of the team to actually deliver, it is quite often the ability of the business to accept that change and introduce into their practices and processes. You’ll just have to go through that process do whatever change management is required – communication, training, support & all of that classic change management activity in order to facilitate a smooth adoption.

There’s lot of positives there, but we do need to consider some potential negatives. We definitely don’t want to be shipping a product that is unstable, full of bugs or has a poor UI, so we need to ensure that our QA process is delivering the right quality of output within the sprints. We absolutely don’t want any negative or reputational value to be realised – that would be a total no-no.

Let’s recap and summarise the value items that we’ve just covered:

  • prioritisation and feedback around that
  • maintaining focus on the vision and user needs
  • we are avoiding or potentially avoiding costs/time on product that isn’t going to deliver
  • from an early view of the product we have the ability to generate new ideas and maybe change direction
  • earlier delivery of capability
  • easier adoption into the business

There is clearly lots of value in the items above. I read a recent opinion piece (note: sorry have mislaid the reference – will update this post when found) – that person was arguing that sprints shouldn’t be time bound but they should actually be around value. So not based on fixed time but should be fixed value. That’s one perspective – I’ve not done this myself – but it would be interesting to see if that worked in practice? Thanks for listening/reading.

Leave a comment