The following table describes what changes buyers can expect when Lean-Agile is implemented into the process and when these changes will have their greatest impact.

Table 1. How Buyer’s Risks Change with Lean-Agile
Traditional ADDIE Lean-Agile Approach

Risk increases towards the end of the project with waterfall.

Risk decreases with each iteration in Lean-Agile.

Because the extensive documentation is the measure of progress, hidden misunderstandings within textual meaning can delay substantial changes until late in the development lifecycle, increasing costs and delaying the schedule due to the rework needed to recover.

Because the actual working courseware is the measure of progress, there is less chance for misunderstandings from individual interpretation of textual requirements, decreasing the rework and increasing the likelihood that the course will be delivered on time.

The most challenging work items may not get addressed until late in the project, making it difficult to modify the project to recover from a problem.

The most challenging work items can be prioritized highest so they are addressed as early in the development lifecycle as possible.

The buyer cannot see the contractor’s/supplier’s large inventory of work items that are work in process (WIP) and partially complete or incomplete. The contractor/supplier has so much money tied up in this WIP inventory that they may have a financial incentive to argue and oppose all changes as the buyer’s situation may change.

The buyer can see the entire increment’s worth of courseware in process. The contractor/supplier has minimal WIP inventory, so changes can be negotiated for swap-out without as much rework to partially complete work items, and with less financial burden, easing the discussion and process around changes when they are necessary. This also helps when priorities or constraints become more fluid.

It is difficult for the buyer to assess progress.

It is easy for the buyer to assess progress by inspecting each iteration’s increment that includes only working courseware.

It is difficult for the buyer to assess how closely the solution matches the problem.

It is easy for the buyer to assess how closely the solution matches the problem because each increment works.

The buyer’s expectations are encoded into text in extensive documentation, requiring decoding of those expectations by the producer, driving a hidden risk of missed value too late in the development life cycle.

The buyer’s expectations become even clearer after the first iteration demo conversations as the buyer inspects and evaluates one increment (regardless of how well or poorly the documentation described what they really wanted). The buyer’s expectations are refined and communicated to the development team with each delivered iteration, reducing rework and the risk of not providing the desired value.

The risk of contractor/supplier staff turnover is larger to the buyer if the person who worked on a particular part of the courseware may no longer work on the team when feedback finally identifies an issue or defect, potentially months later. This delay potentially leaves a new person trying to glean the original developer’s intent when addressing a problem.

The risk of contractor/supplier staff turnover is smaller to the buyer because the staff that worked that increment two weeks ago are more likely to still be on the project and available to fix any defects discovered, ensuring the continuity of buyer feedback all the way through resolution as the defect is fixed in the next iteration two weeks later.

The buyer staff’s scheduling windows for review require large blocks of the reviewer’s time because the batch size is so large (entire course).

The buyer staff’s scheduling windows for review can be much shorter because the batch size is much smaller, taking less of their time to review.

Stakeholders have such a large batch to review that they tend to review asynchronously and alone for efficiency, increasing the chances of contradictory feedback that requires another round of tracking and review to referee the conflicts.

All stakeholders are encouraged to attend each synchronous, end-of-iteration demonstration to provide feedback to the development team, with other buyer staff listening, which helps to quickly solve any mutually exclusive feedback.

The risks increase because specialists are working alone for long periods and then simply handing off to the next specialist.

The risks reduce because all needed specialists are on a cross-functional teams see each other’s inputs more frequently, catching problems before as much time has passed.

The risks are often hidden with non-visible knowledge work items and consequently not addressed until much later in the life cycle when the problem is finally noticed.

Day-to-day risks are managed at the daily cross-functional team stand up meetings in front of the visual board, making blockers visible, bottlenecks visible, and the state of all the components obvious.

Changes late in the lifecycle increase the risk of the project costing more than budgeted.

If Agile contracts were used, and the buyer leadership gets that Agile scope (requirements) is flexible, then changes can be swapped out for equally sized effort even later in the lifecycle.

Waterfall tends to fix the scope of the requirements. This implies that all work items are of equal priority. This can lead to implementing critical items late, when project managers assume they will all be implemented, so order is less important. Sometimes, this may eliminate the option of on-time delivery if all does not go well with a critical item. This, in turn, leads to delays in schedule and sometimes an increase in costs.

With the development team always pulling the next highest priority work item, the buyer is assured of getting their highest priority requirements and features within the flexible scope, within the fixed time and fixed cost.

Higher-level risks are addressed at the program level, following the program risk management process.

Same, no change

Political risk for buyer’s staff inside their own organization with their stakeholders if the project is not successful.

Same, no change

So in summary, the biggest changes in buyer’s risk are:

  • Lean-Agile decreases risk with each iteration.

  • Lean-Agile demos reduce misunderstandings with every iteration.

  • Lean-Agile can improve contractor/supplier flexibility.

  • Easier for the buyer to assess actual courseware progress.


Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview