The Disciplined Agile Framework

The Disciplined Agile 2.0 process decision framework provides light-weight guidance to help organizations streamline their information technology (IT) processes in a context-sensitive manner.  It does this by showing how the various activities such as solution delivery, operations, enterprise architecture, portfolio management, and many others work together.  The framework also describes what these activities should address, provides a range of options for doing so, and describes the tradeoffs associated with each option.

This article addresses the following topics:

Why Disciplined Agile 2.0?

There are several reasons why we extended the framework to go beyond solution delivery:

  1. Enable agile delivery teams to succeed.  The focus of Disciplined Agile Delivery (DAD) 1.x was to describe how agile/lean teams work from beginning to end, showing how all the activities of solution delivery (analysis, design, testing, architecture, management, programming, and so on) fit together in a cohesive, streamlined whole.  However, to succeed delivery teams must often work with people outside of the team, such as enterprise architects, operations engineers, governance people, data management people, and many others.  For agile/lean delivery teams to be effective these people must also work in an agile/lean manner.
  2. Provide a coherent strategy for agile IT.  If you think that software development is hard, running the entire IT department is even harder.  IT departments are complex adaptive organizations.  What we mean by that is that the actions of one team will affect the actions of another team, and so on and so on.  For example, the way that your agile delivery team works will have an effect on, and be affected by, any other team that you interact with.  If you’re working with your operations teams, perhaps as part of your overall DevOps strategy, then each of those teams will need to adapt the way they work to collaborate effectively with one another.  Each team will hopefully learn from the other and improve the way that they work.  These improvements with ripple out to other teams.  The challenge is that every area within IT has one or more bodies of knowledge, and in some cases published “books of knowledge”, that provide guidance for people working in those areas.  For example management has the PMIBoK and Prince 2, enterprise architects have TOGAF and the Zachman Framework, business analysts have the IIBA BoK, data managers have the DAMA BoK, and so on.  These industry groups and their corresponding bodies of knowledge contradict one another, they are at different points on the agile/lean learning curve, and sometimes they promote very non-agile/lean strategies.  At the IT level this can be very confusing, resulting in dysfunction.  The  DA framework shows how this all fits together in a flexible manner that supports the realities faced in complex adaptive systems.
  3. Support the lean enterprise. A lean enterprise is able to anticipate and respond swiftly to changes in the marketplace.  It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces.  Lean enterprises require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.  This include an IT department that is able to work in an agile/lean manner.
  4. Context counts.  Every person, every team, and every organization is unique.  The implication is that you need a framework that provides you with choices so that you can tailor, and later evolve, an approach to address the situation that you face in practice.  Although prescriptive, one-size-fits-all frameworks such as SAFe or Nexus may seem like an attractive, easy solution to your process-related needs at first the reality is that they often do more harm than good within the organizations that adopt them.

Why the Name Change?

The scope of the framework evolved from how to be effective delivering IT solutions to how to be effect at IT in general. As a result we felt that the name “Disciplined Agile Delivery” was no longer representative of the goal of the framework. “Disciplined Agile” is more accurate.

Our Release Strategy

We began releasing foundational material in late 2014 and into 2015 until finally there was enough material to warrant a named release in August 2015. Having said that, we’re not done yet. We are incrementally releasing the DA 2.0 material during the Autumn of 2015. Please stay tuned.


To date there have been three major release tiers of this framework:

  1. Disciplined Agile Delivery 0.x.  The framework was originally developed at IBM Rational from early 2009 to June 2012.  The IBM team worked closely with business partners, including Mark Lines, and was led by Scott Ambler.  IBM Rational Method Composer (RMC) currently supports an early, 0.5 version of the DAD framework.
  2. Disciplined Agile Delivery 1.x.  The DAD 1.0 release occurred in June 2012 with publication of the first DAD book, Disciplined Agile Delivery.  Evolution and publication of the DAD framework continued at this site starting in August 2012.  Ownership of the DAD framework intellectual property effectively passed over to the Disciplined Agile Consortium in October 2012, a fact which was legally recognized by IBM in June 2014.
  3. Disciplined Agile 2.0. This is the current version of the framework, initially released in August 2015.  As we described earlier, the focus is on describing a flexible, context-sensitive approach to the IT process.


We will continue to actively develop the Disciplined Agile material here on this site.  To get notified of updates as they occur please subscribe to the blog.  The Disciplined Agile LinkedIn Forum is active as well if you’d like to be involved in the ongoing discussion.