Disciplined Agile

Produce a Potentially Consumable Solution

This Construction process goal describes how our team will build or configure a solution for our stakeholders that best meets their current needs. While “potentially shippable software” is a good start we need to do a lot better in the enterprise space. It isn’t enough to be potentially shippable; what our stakeholders want is something that is usable (it is easy to work with), desirable (they want to use it), and functional (it meets their needs). Furthermore, our stakeholders need solutions, not just software. Yes, software is part of the solution. But we may also be updating the hardware or platform that it runs on, writing supporting documentation, changing the business processes around the usage of the system, and even evolving the organization structure of the people using it. Working software is nice, but a consumable (usable + desirable + functional) solution (software + hardware + documentation + process + organization structure) actually gets the job done.

This goal addresses planning, analysis, design, and programming aspects of development (other aspects are addressed by the goal Accelerate Value Delivery). To be effective, we need to consider several important questions:

  • How will we plan how we’ll work together?
  • What programming approach will we take?
  • How will we architect and design the solution?
  • How will we approach deliverable documentation?
  • How will we ensure that our solution is consumable?
Copyright Project Management Institute All Rights Reserved Produce a Potentially Consumable Solution v5.4 Organize the Work Coordination meetings/daily standups End-of-increment session Iteration/sprint planning Just-in-time (JIT) planning Look-ahead planning/backlog refinement Value flow planning event Visualize plan Focus the team Develop Software Behavior-driven development (BDD) Test-driven development (TDD) Test-first development (TFD) Test-after development Testless programming Explore Solution Design Agile Modeling session/big room planning Architecture spike Detailed design specification Just in time (JIT) model storming Look-ahead modeling/backlog refinement Mob programming Model-driven development (MDD) Proof of concept (PoC) Set-based design Test-driven development (TDD) Write Deliverable Documentation Active stakeholder participation Continuous documentation - same iteration Continuous documentation - Following iteration Document late Ensure Consumability Demonstrations Design sprint Regular deployment Usability/consumability design Usability/consumability testing

Figure 1. The Produce a Potentially Consumable Solution process goal diagram (click to enlarge)

You can use the DA Browser to learn more about the options in the goal diagram of Figure 1. 

Why This is Important

There are several reasons why this process goal is important:

  1. We need to incrementally produce a consumable solution. A key agile concept is to keep things as simple as you possibly can. It is important to keep this in mind when choosing whether to work on an artifact and to what level of detail. Show your users a working solution as quickly as possible and at regular intervals. For agile teams this begins in the first iteration of Construction and continues for each subsequent iteration. For lean teams it may begin even sooner, perhaps just a few days into Construction. Stakeholders will soon tell us whether we are on the right track. Often they will tell us that we have missed the mark. This is a natural outcome. It is a good thing that we found this out early while we still have the opportunity to adapt our solution toward what they truly need and expect.
  2. We want to explore design details at the last most responsible moment. Because we’re exploring requirements just in time (JIT), we similarly evolve our design JIT.
  3. We need to plan and coordinate our work. Disciplined Agilists plan at the “long term” release level and the intermediate term iteration level (if they’re following one of the agile life cycles). We coordinate with other teams when it makes sense to do so and internally on at least a daily basis 

Key Points

  • The team will collaboratively produce the solution incrementally, seeking and acting on feedback as they do so.
  • The requirements, design, and plan will evolve over time based on your—and your stakeholders’—changing understanding of what they want.