The Agile Value Proposition
What is the value of Agile? Maybe you find yourself on a team that is using an Agile framework, such as Scrum. Maybe your team mutually decided to work in an Agile manner. Or maybe it has been prescribed by your management. Maybe you’re not very clear as to WHY your team is working in this manner. And possibly, you are confused and stressed; you feel like your work world has been turned upside down and things are going way too fast in two week increments. Either way, whether you are all confused or just a little fuzzy about why your team is doing what it’s doing, I hope this blog post will help you understand the WHY of what you’re doing, even if HOW you are doing it remains problematic. (If that is your situation, I would be happy to discuss it and help you make it better, if possible.)
I would like to share with you the Agile Value Proposition, four advantages which Agile brings to the table as compared with a traditional, aka waterfall, approach to product development.
In the graphs below:
The Green Line 
= Agile
The Dashed Line 
= Waterfall
(I am indebted to Mike Griffiths for the graphs below, which are included in his book, PMI-ACP Exam Prep, and reproduced here from my own exam prep notes.)
1. Visibility
Visibility means more interaction and transparency between stakeholders. By stakeholders I mean EVERYONE involved in the development of a project: product owners, business analysts, software developers, testers, managers.
How does visibility work in a typical waterfall project? Well, there may be a period where only a project manager and some business folks interact to get things started. Then a business analyst enters the picture and spends many hours, days, months preparing voluminous requirements. Then the dev team is brought in and they might spend months coding. Then QA tests. Maybe they find problems and developers have to fix them. Eventually, the product enters user acceptance testing (UAT) and there’s a good chance these folks might send things back for more rework. The visibility may have started at a high point for a very brief moment at project kickoff. But all through the rest of the process I described, only a subset of stakeholders are involved at any given point. Then there is high visibility at production release. This is shown by the U-shaped dashed line.
In Agile, this process is reduced to MUCH shorter cycles with all stakeholders involved with more frequency and overlap. We plan with business folks and developers involved. We eliminate the middlemen (PMs and BAs) to a large degree and bring the business folks and developers into direct contact. This fosters a much more efficient shared understanding of the product we are developing and why we are developing it. The feedback loops between testers, developers, and product owners are short and effective. Visibility may dip while an increment is being built. But it goes right back up as product owners inspect and accept what is built in each increment. Hence the green wavy line. After each increment we plan some more and build some more, continuing the feedback loops with all stakeholders aware of what is going on.
2. Business Value
Business Value should be the goal of every project. Waterfall delivers business value only after a long period of planning, building, testing, as depicted by the dashed line. When we finally get to release time, there is the risk that what we produced may not be exactly right. It may even be horribly wrong. There’s the risk that many things may have changed between project inception and final delivery: market changes, strategic business changes, personnel changes, etc.
How is Agile different? In Agile, we produce business value sooner. We produce increments working software that is available for product owner inspection. It may not necessarily be released to production with each increment. But it is presented to the product owner. This allows the PO give more frequent feedback, modify features, even change direction if need be. Product can be released for business use in repeated phases thereby producing value early on with additional value added progressively, as depicted by the upward arching green line.
3. Adaptability
How much adaptability is there in waterfall? Pretty much none, as can be seen by the dashed line. There is adaptability at the outset during requirements gathering. But once the requirements are signed off there is no adaptation without change control. And who likes going through that? It’s like lifting the top ten floors of a building because you want to change a brick on the first floor.
In Agile, adaptability runs high throughout most of the project. That is because we deliver in small increments, have frequent inspections at short intervals, and can adapt to changing requirements without undoing large parts of competed work.
4. Risk
What about risk? How do waterfall and Agile compare in risk management?
As you can see by the dashed line, risk remains high throughout most of a waterfall project. Much of this is due to the fact that most of testing is not done until later in the process after much work has already been done. Think of all the time that elapses from requirements through build to finally arrive at testing. Requirements could have been misunderstood. Bugs might be found that require much investigation and untangling of code to resolve. And what about performance? That usually doesn’t get tested until everything is build. Then we stress test a system and hope to heck it doesn’t blow apart.
Since our focus is delivering value early in an Agile project, we also want to consider risks and technical dependencies early. Mike Griffiths describes risk as “anti-value – factors that have the potential to erode, remove, or reduce value if they occur.”
On an Agile project, we can have a “risk-adjusted backlog.” This is where we move the work of mitigating the biggest risks to be among the high priority items in the backlog. If we can evaluate the impact of a risk and determine how much value we would lose if the risk occurred, we can then balance business features with tasks to remediate risks. By doing so, the level or risks decreases rapidly, as you can see by the green line.
Wrap Up
I believe Agile has a lot of value to deliver, if it is done correctly. I have experienced it. If you feel like you’re in a whirlwind of Agile confusion, there’s probably a more systemic problem with your team. I’ve experienced that too. Like I said above, I would be happy to discuss this with you and help you if I possibly can.