Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Daniel Gagnon
Valentin Mocanu
Joshua Barnes
Michael Richardson
Klaus Boedker
Kashmir Birk
Mike Griffiths

Recent Posts

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

PMI and Disciplined Agile at Agile20Reflect

Why doesn't Disciplined Agile use the term "predictive"?

Crystal ball - Getty Images

Quick answer

The term predictive is deceptive.


Detailed answer

In the Disciplined Agile (DA) tool kit we use the term traditional or serial, rather than predictive or waterfall, to refer to the classic/linear ways of working.  We feel that predictive is deceptive, more on this in a minute, and waterfall to be insulting (albeit still in common use within the IT community).  Furthermore, we're starting to move away from using traditional as we're now seeing a generation of practitioners who feel that some of the older agile approaches, in particular Scrum, are traditional ways of working.

There are several reasons for why we feel the term "predictive" to be deceptive:

  1. "Predictive" implies predictable.  Predictive is defined as "relating to the ability to predict" whereas predictable is "something that happens in a way or at a time that you know about before it happens."  Something that is predictable is a sure thing, yet something that is predictive is not. This is an important difference, particularly given that we know that projects aren't completely predictable - otherwise we wouldn't need risk management.
  2. "Predictive" approaches to IT projects are a poor choice in most cases.  Years ago I led a study for Dr. Dobb's Journal that investigated the effectiveness of different approaches (agile, lean, iterative, ad hoc, and traditional) to IT projects.  We found that traditional strategies were less effective in practice than agile and lean approaches, and we weren't the only ones to have found this.  We also investigated what was initially predicted at the beginning of the project and what actually happened by the end of the project, and once again traditional approaches didn't do as well as agile & lean.  BUT, I must stress that the study focus was on IT projects only, not on projects in general.  
  3. "Predictive" approaches to intangible projects are likely a poor choice  DDJ found, in several studies in fact, that "predictive" strategies were less predictable in practice than agile/lean approaches in IT.  I highly suspect that this is true of intangible projects in general although do not have hard data to back up that claim.  We need to investigate this.
  4. "Predictive" approaches to tangible projects are likely a good choice, but I suspect we can do better.  I suspect that "predictive" approaches are more appropriate for tangible projects, such as building houses or buildings, than agile/lean approaches.  I also believe that a hybrid approach combining the best from traditional, agile, and lean strategies is likely better than traditional alone. Having said this, as with the previous point, I don't know of any research that has compared the various project management paradigms for tangible projects, so this too is something we need to investigate.

In short, we know that "predictive" is a deceptive term for a large category of projects and suspect this to be true for other project types.  As a result the only use of the term predictive in DA is to tell you that we don't use it.


Posted by Scott Ambler on: November 09, 2020 12:38 PM | Permalink | Comments (9)

Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams


Like it or not, functional dependencies occur between requirements.  This can happen for many reasons, as we discussed in Managing Requirements Dependencies Between Teams, and there are several strategies for resolving such dependencies.  In this blog posting we explore what happens when a functional dependency between two requirements exists AND one requirement is implemented by an agile/lean team and another by a traditional/waterfall team.

In our example requirement X depends on requirement Y.  Neither requirement has been implemented yet (if requirement Y had already been implemented, and better yet deployed into production, the point would be moot).  When we refer to the “agile team” this team may be following any one of the lifecycles supported by DAD (Basic/Agile, Advanced/Lean, Continuous Delivery, or Exploratory/Lean Startup).


Scenario 1: An Agile/Lean Team Depends on a Traditional Team

In this scenario X is being implemented by an agile team and Y is being implemented by a traditional team.  From the point of view of the agile team, this is very risky for the following reasons:

  1. The traditional team is likely working on a longer time frame.  Disciplined agile teams produce a potentially consumable solution (potentially shippable software in Scrum parlance) on a regular basis, at least every few weeks.  A traditional team typically delivers a working solution over a much longer time frame, often measured in quarters.  The implication is that because Y is being developed by a traditional team it may be many months until it is available, compared to several weeks if it was being developed by an agile team.  This potentially adds schedule risk to the agile team.
  2. The traditional team may not make their deadline.  According to the Standish Group’s Chaos Report, the average traditional team comes it at almost twice their original estimate (e.g. a project originally estimated at 6 months of work takes almost a year).  Similarly, the December 2010 State of the IT Union survey found that traditional teams were much more likely than agile teams to miss their deadlines.  By having a dependency on the deliverable of a traditional team, an agile team effectively increases their schedule risk.
  3. The traditional team may struggle to deliver something that is “agile friendly”.  Agile teams routinely develop well written, high-quality software that is supported by a robust regression test suite and where needed concise supporting documentation.  Although traditional teams can also choose to deliver similar artifacts very often their code isn’t as well supported by regression tests and their documentation may be overly detailed (and thereby more likely to be out of date and difficult to maintain).  In other words, there is potential for quality risk being injected into the agile team.
  4. The traditional team may not deliver.  There is always the risk that the traditional team doesn’t implement Y, traditional teams often need to reduce the scope of their deliveries in order to meet their commitments, or if they do implement Y it is done too late to be useful any more.


There are several strategies the agile team may decide to take:

  1. Negotiate a delivery date with the traditional team. Once the agile team has identified the dependency they should collaborate with the traditional team to determine the implementation schedule for Y.  The agile team now has a release/schedule dependency on the traditional team which is a risk and should be treated as such.  The agile team’s high-level release plan should show a dependency on the delivery of Y and their risk log (if they have one) should also capture this risk.  The agile team should stay in contact with the traditional team throughout construction to monitor the progress of the development of Y.  The agile team should also attempt to negotiate early delivery of Y so that they may integrate with it, and test appropriately, as soon as possible.
  2. Collaborate to develop Y.  One way for the agile team to make it attractive for the traditional team to implement Y earlier than they normally would is to pitch in and help to do the work.
  3. Rework X to remove the dependency.  One of the general strategies discussed in Managing Requirements Dependencies Between Teams was to rework X so that it no longer depended on Y.  This may mean that you reduce the scope of X or it may mean that you deliver part of X now and wait to deliver the rest of X once Y is available.
  4. Reschedule the implementation of X.  Another general strategy is to deprioritize X and implement it after Y is eventually deployed.  This is a realistic option if Y is about to be implemented soon, say in the next few months, but often unrealistic otherwise.
  5. Implement Y.  When the lead time is substantial, the agile team may choose to do the work themselves to implement the functionality.  This can be viable when the agile team has the skills, experience, and resources to do the work.  This strategy runs the risk of Y being implemented twice, once by each team, potentially inconsistently.  To avoid this sort of waste the agile team will want to negotiate with the traditional team to take the work over from them.


Scenario 2: A Traditional Team Depends on an Agile/Lean Team

In this scenario X is being implemented by a traditional team and Y by an agile team.  From the point of view of the traditional team, this might be seen as risky for the following reasons:

  1. They may not understand how a disciplined agile team actually works. Many traditional teams are still concerned about the way that they believe agile teams work.  This is often because they perceive agile to be undisciplined or ad-hoc in nature, when the exact opposite is true.  The implication is that the agile team will need to describe to the traditional team how they work, why they work that way, and describe the types of deliverables they will produce.
  2. They may want traditional deliverables from the agile team.  Disciplined agile teams will produce high quality code, a regression test suite for that code, and concise supporting documentation.  Traditional teams may believe that they also want detailed requirements and design specifications, not realizing that the tests produced by the agile team can be considered as executable specifications for the production code.  The implication is that the two teams will need to negotiate what the exact deliverable(s) will be.
  3. They may struggle with any changes to the interface.  Agile teams are used to working in an evolutionary manner where the requirements, design, and implementation change over time.   Traditional teams, on the other hand, will often strive to define the requirements and design up front, baseline them, and then avoid or prevent change to them from that point onwards.  These different mindsets towards change can cause anxiety within the traditional team, the implication being that the agile team may need to be a bit more strict than they usually would be when it comes to embracing change.

The fact is that scenario 2, a traditional team relying on a disciplined agile team, is very likely an order of magnitude less risky than the opposite (scenario 1).   Either scenario will prove to be a learning experience for the two teams, particularly the one that relies on the other team.  Going into the situation with an open mind and a respectful strategy will greatly increase the chance that you’ll work together effectively.


Posted by Scott Ambler on: July 21, 2014 07:49 PM | Permalink | Comments (0)

Tell me whom you love, and I will tell you who you are.

- Houssaye