One of the key aspects of Disciplined Agile Delivery (DAD), the portion of the Disciplined Agile (DA) toolkit that focuses on delivery, is that it promotes a risk-value lifecycle. In this article we overview the standard Scrum/agile “value-driven lifecycle”, explore its advantages and disadvantages, and then show how to easily extend this strategy to a risk-value lifecycle.
Several agile methods, in particular Scrum, promote what is called a value-driven lifecycle – the basic idea is that you prioritize the work by business value and do the most valuable work first. There are several clear advantages to this approach, including the fact that you’re always working on the most valuable functionality and therefore providing the best return on investment (ROI) possible to your stakeholders. By building your solution incrementally, and by allowing your stakeholders to evolve their requirements, your team enables your stakeholders to maximize the value they get for their investment by allowing them to pay for only the most valuable functionality that they want. Furthermore, allowing your stakeholders to evolve their requirements increases the chance that you will build what they want. The value-driven lifecycle approach is clearly a good idea, but there are even better ways of working.
This article addresses three topics:
- Common risks in software development
- The risk-value lifecycle
- Addressing common risks throughout the delivery lifecycle
Common Risks in Software Development
We know that there are common risks that teams face when developing software-based solutions, risks that aren’t always well-addressed by a value-driven approach. These risks are:
- Unaligned stakeholders. When we are building software-based solutions we have a wide range of stakeholders, far more than just the end-user/customer, and their goals and expectations can be very different. For our team to be successful we need to get our stakeholders, including ourselves, reasonably well aligned to go in the same direction.
- Inappropriate architecture. If you’ve been in the IT industry for any length of time you’ll have likely heard of, or worse yet worked on, a team where a bunch of smart people came up with what they thought to be a good architecture, another group of smart people reviewed and signed off on it, yet months later the team still ran into significant technical problems (such as the solution not integrating well, not being performant, not being reliable, and so on). The challenge is that you don’t know whether your architecture works until you have actually working software that implements it.
- The delivery team builds the wrong thing. On long projects, a very questionable idea all in itself, there is the risk that the team will get off track. Either they evolve away from the original vision (an indicator that either the original vision was off or that the team has gotten sidetracked, or both) or changes in the marketplace negate the value of what they’re working on.
- Insufficient functionality. Some teams are forced into delivering insufficient functionality into production, often because of a date driven schedule, only to find that their stakeholders don’t like what was delivered even though it was “on time and budget.”
- The solution isn’t ready to be shipped. Sometimes systems are put into production when they aren’t ready, either because they weren’t technically ready (quality wasn’t good enough, wasn’t enough supporting documentation) or because the stakeholders weren’t ready (they weren’t properly trained, they were overwhelmed with releases of other systems, they simply don’t want it right now, and so on). A primary cause of this problem, once again, is a date-driven schedule.
- Your stakeholders don’t like what they get. Sometimes teams do a great job of building “potentially shippable software” but when they ship it they discover that it isn’t being used as widely as they hoped. This happens when your team doesn’t work closely with your stakeholders, or if they do work closely with stakeholders they’re not working with the right ones.
The Risk-Value Lifecycle
Enter the risk-value lifecycle. Figures 1 and 2 depict the two project-based lifecycles supported by DAD, the Agile/Basic lifecycle that is based on Scrum and the Lean lifecycle based on Kanban. These are only two of several DAD lifecycles to choose from. These lifecycles depict several key aspects of a risk-value lifecycle strategy: explicit phases, sophisticated work prioritization, and explicit milestones.
Figure 1. The Agile/Basic Scrum-based lifecycle (click diagram to expand).
Figure 2. The Lean Kanban-based lifecycle (click diagram to expand).
Let’s explore these aspects of a risk-based lifecycle in greater detail:
- Explicit, streamlined phases. The two project lifecycles supported by DAD call out explicit phases, in this case Inception, Construction, and Transition. Although there are raging debates over the need for Inception, sometimes called Sprint 0, the reality is that about 95% of agile teams do in fact do some form of up-front planning, modeling, and general setup of the team and their work environment. So in DAD we make this explicit and show how to streamline Inception. Similarly teams need to transition, or deploy, their work into production at some point. You should also streamline Transition as much as possible, and through automation should evolve into an activity instead of a phase (something that is captured in DAD’s Continuous Delivery:Agile or Continuous Delivery:Lean lifecycles, not shown here). By having explicit, streamlined phases we can reduce some of the common risks of software development described earlier. We work through how this happens in greater detail in the table below.
- More sophisticated work prioritization. In DAD we suggest that you adopt the role of Product Owner (PO) from Scrum, at least if you’re new to agile. The PO is responsible for prioritizing the work. We also suggest that you adopt the role of Architecture Owner (AO) from Agile Modeling, a person who guides the team through making architectural and technical issues. The AO and the rest of the team should provide the PO with input into the risks faced by the team, and point out which requirements are risky (and explain why). With a Risk-Value approach the PO may decide to increase the priority of the riskier requirements so that they are implemented first by the team. By implementing the riskiest requirements first the team effectively proves their architecture with working code. Or, perhaps they discover that their architectural strategy doesn’t work, in other words they fail fast, when they still have the most time and budget available to deal with the problem (or worst case they can cancel the project and thus minimize their losses). Depending on the background of the PO, you may find that you need to educate them on some of the realities of software development
- Explicit, light-weight milestones. This is part of DA’s overall lean IT governance strategy, in particular the delivery governance portion of it. In Figure 3 you see that the milestones called out in the lifecycles are instrumental in reducing overall risk on your solution delivery endeavor. The following section explores why this happens in greater detail. For more information, please see the blog Reduce Project Risk with Light-Weight Milestones.
Figure 3. Decreasing risk and increasing value throughout a disciplined agile project (click diagram to expand).
Addressing Common Risks Throughout the Delivery Lifecycle
The following table summarizes how each of the common risks described earlier are addressed via a risk-value delivery lifecycle.
|Risk||How DAD Addresses this Risk|
|Unaligned stakeholders||This is why we include a light-weight Inception Phase in the Disciplined Agile Delivery (DAD) lifecycle. Inception ends with the Stakeholder Vision milestone – this milestone verifies that our stakeholders are aligned behind a realistic strategy.|
|Inappropriate architecture||In DAD we promote the idea of proving your architecture with working code early in Construction, a strategy adopted from the Unified Process (UP) that has also been adopted by Extreme Programming (XP) practitioners. This is captured by the lightweight-milestone Proven Architecture as well as the process goal Prove Architecture Early. DAD also supports the strategy of spikes to explore small portions of your architecture, such as new technologies or combinations of technologies.|
|Delivery team gets off track||Agile teams should make a go-forward decision on a regular basis, something that teams following the Agile/Basic Scrum-based lifecycle do at the end of each iteration, to determine how to continue. Although this is a great idea in theory, in practice it can break down because the Product Owner is responsible for driving this decision and they often “go native” and become well-aligned with the team. When this happens they are less likely to decide to cancel the effort or even pivot in a different direction. To counteract this problem the best strategy is to have releases into production on a regular basis because actual usage will provide feedback as to how valuable your work actually is. In the case of infrequent releases, often the result of the project mindset, we suggest that you consider holding a light-weight Project Viability milestone review every few months to ensure that the team is still on track.|
|Insufficient functionality||Active stakeholder participation throughout Construction helps to ensure that the team understands the needs of stakeholders and implements the appropriate functionality. When active participation isn’t realistic then the team needs to work with stakeholder proxies such as POs or business analysts (BAs). Furthermore, the DAD lifecycles include a specific Sufficient Functionality milestone where the stakeholders, often led by the PO, decide that the team has built sufficient functionality to warrant the effort of transition.|
|Solution isn’t ready to be shipped||The Transition phase includes the Production Ready milestone where you should ask two fundamental questions: Is the solution ready to be shipped? and Are your stakeholders ready to accept the solution?|
|Stakeholders don’t like what they get||The value-driven aspects of the lifecycle should address this risk, particularly through the adoption of an active stakeholder participation strategy. However, if you’re not working with the full range of stakeholders then you risk missing the requirements of the people you’re not working with. DAD also promotes the idea that teams should focus on producing consumable solutions, not just potentially shippable software, thus increasing their chance of building something their stakeholders actually want. There is also the Delighted Stakeholders milestone which suggests that teams find a way to determine if their stakeholders actually like what was delivered – it isn’t sufficient to merely ship working software, our stakeholders actually want solutions that are consumable (usable and desirable).|
The idea of a risk-value lifecycle isn’t new. It was popularized in the mid-1990s by the Rational Unified Process (RUP) and is now being rediscovered by agile community. DAD adopted this strategy from the very beginning because it provides better results than Scrum’s value-driven lifecycle. One of the primary advantages of a hybrid framework like Disciplined Agile is that we’re not limited to the strategies of a single method, we can instead leverage ideas from a wide range of sources. The risk-value lifecycle is just one of many such ideas.