1. Disciplined Agile Delivery (DAD)
Introduction to
Disciplined Agile Delivery (DAD)
This deck has been developed by the Disciplined Agile Consortium (DAC),
This deck overviews the Disciplined Agile Delivery (DAD) process decision framework.
It may be used, and distributed, free of charge as long as the DAC logo and copyright remains visible on each slide.

2. © Disciplined Agile Consortium
Disciplined Agile Delivery (DAD) is a process decision framework
The key characteristics of DAD:
People-first
Goal-driven
Hybrid agile
Learning-oriented
Full delivery lifecycle
Solution focused
Risk-value lifecycle
Enterprise aware
The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.”
Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver sophisticated solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders. Worse yet people don’t always know where to look for advice or even know what issues they need to consider. To address these challenges the Disciplined Agile Delivery (DAD) process decision framework provides a more cohesive approach to agile solution delivery.
There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.
For more information, visit
© Disciplined Agile Consortium

3. DAD is a Hybrid Framework
SAFe
DevOps
…and more
Outside In Dev.
“Traditional”
Agile Data
Extreme Programming
Unified Process
Agile Modeling
Scrum
Kanban
Lean
DAD leverages proven strategies from several sources,
providing a decision framework to guide your adoption and
tailoring of them in a context-driven manner.
The DAD framework does much of the heavy lifting when it comes to answering the question “How do all of the various agile techniques fit together”
In many ways DAD is the process glue that connects the various agile practices.
The DAD framework leverages ideas from a wide variety of agile, lean, iterative, and even traditional sources.
© Disciplined Agile Consortium

4. © Disciplined Agile Consortium
A High Level Lifecycle
One of the key aspects of the Disciplined Agile Delivery (DAD) process decision framework is that it promotes a full, end-to-end, solution delivery lifecycle. The figure on this slide overviews a high-level view of the DAD lifecycle. It is a three-phase lifecycle, more on this in a minute, where you incrementally build a consumable solution over time. We start with this high-level view so that we can explore several important concepts before diving into details.
First, the DAD lifecycle explicitly calls out three phases:
Inception. During this phase project initiation activities occur. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Initiation survey, found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase we do some very lightweight visioning activities to properly frame the project. It takes discipline to keep Inception short.
Construction. During this phase a DAD team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the lifecycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.
Transition. DAD recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. DAD teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.
© Disciplined Agile Consortium

5. Disciplined Agile Delivery: Basic Lifecycle
This lifecycle presents a more detailed view of what we call the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:
It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls sprints).
It uses non-Scrum terminology. Although the lifecycle is Scrum-based we chose to use non-branded terminology in DAD, in the case of this diagram the term iteration instead of sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead.
It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle.
There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and when you take this greater scope into account you begin to realize you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements. For more on this, read Agile Best Practice: Prioritized Requirements.
In includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet. Such milestones are an important aspect of agile governance.
We call this the basic/agile lifecycle because it’s likely where you’re going to start with DAD. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.
…so there’s a fair bit to the agile delivery lifecycle.
© Disciplined Agile Consortium

6. Disciplined Agile Delivery: Lean Lifecycle
This diagram depicts what we call the Advanced/Lean DAD lifecycle. There are several interesting features to this lifecycle:
It supports a continuous flow of delivery. In this lifecycle the solution is deployed as often, and whenever, it makes sense to do so. Work is pulled into the team when there is capacity to do it, not on the regular heartbeat of an iteration.
Practices are on their own cadences. With iterations/sprints many practices (detailed planning, retrospectives, demos, detailed modeling, and so on) are effectively put on the same cadence, that of the iteration. With a lean approach the observation is that you should do something when it makes sense to do it, not when the calendar indicates that you’re scheduled to do it.
It has a work item pool. All work items are not created equal. Although you may choose to prioritize some work in the “standard” manner, either a value-driven approach as Scrum suggests or a risk-value driven approach as both DAD and RUP suggests, but other work may fit this strategy. Some work, particularly that resulting from legislation, is date driven. Some work must be expedited, such as fixing a severity one production problem. So, a work item pool and not a prioritized stack makes a bit more sense when you recognize these realities.
We call this the advanced/lean lifecycle because it’s something we see teams evolve to over time. They often start with the basic lifecycle described earlier but as they learn, as they improve the way that they work, the lifecycle they follow becomes leaner.
DAD doesn’t prescribe a single lifecycle…
© Disciplined Agile Consortium

7. The Phases Disappear Over Time
First release:
Inception
Construction
Transition
Second release: I
Construction T
Third release: I
Construction T
Nth+ releases: C T .
…and promotes continuous learning and improvement.
© Disciplined Agile Consortium

8. Disciplined Agile Delivery: Lean Continuous Delivery Lifecycle
This diagram depicts a Continuous Delivery version of the DAD lifecycle. It is basically a leaner version of the previous lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
A good
end goal
© Disciplined Agile Consortium

9. DAD Exploratory “Lean Startup” Lifecycle
This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.  As a result they need to quickly explore what the market wants via a series of quick learning experiments. In effect this lifecycle is a replacement for the Inception phase of other DAD life cycles
See
Sometimes it takes time to identify what your stakeholders actually need
© Disciplined Agile Consortium

10. DAD supports a robust set of roles
Team Lead
Agile process expert, keeps team focused on achievement of goals, removes impediments
Product Owner
Owns the product vision, scope and priorities of the solution
Architecture Owner
Owns the architecture decisions and technical priorities, mitigates key technical risks
Team Member
Cross-functional team members that deliver the solution
Stakeholder
Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies
Primary roles are commonly found regardless of the level of scale.
Secondary roles are typically introduced, often on a temporary basis, to address scaling issues.
Why So Many Roles?
This is a common question that we get from people familiar with Scrum. Scrum has three roles – ScrumMaster, Product Owner, and Team Member - so why does DAD need ten? The primary issue is one of scope. Scrum mostly focuses on leadership and change management aspects during Construction and therefore has roles which reflect this. DAD on the other hand explicitly focuses on the entire delivery lifecycle and all aspects of solution delivery, including the technical aspects that Scrum leaves out. So, with a larger scope comes more roles. For example, because DAD encompasses agile architecture issues it includes an AO role. Scrum doesn’t address architecture so doesn’t include such a role.
Some Important Thoughts About Roles
On a DAD project any given person will be in one or more roles, an individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time. For example, Peter may be in the role of team member and architecture owner right now but step into the role of team lead next month when Carol, the existing team lead, goes on vacation.
Roles are not positions, nor are they meant to be. For example, Jane may be in the role of stakeholder for your project but have the position of Chief Financial Officer (CFO) within your organization. In fact, although there may be hundreds of stakeholders of your project none of them is likely to have a position of “stakeholder.”
Agile deemphasizes specialized roles and considers all team members equal – everyone pitches in to deliver a working solution regardless of their job description. An implication of this is that with the exception of stakeholder everyone is effectively in the role of team member.
Traditional roles, such as business analyst and project manager, do not appear in DAD. The goals which people in traditional roles try to achieve, for example in the case of a business analyst to understand and communicate the stakeholder needs/intent for the solution, are still addressed in DAD but in different ways by different roles. There isn’t a perfect one-to-one match between any given traditional role and a DAD role, but as you will find in the Disciplined Agile Delivery book there are reasonable transition strategies. The critical thing for traditionalists to understand is that because the underlying paradigm and strategy has changed, they too must change to reflect the DAD approach.
© Disciplined Agile Consortium

11. DAD is Goal-Driven, Not Prescriptive
This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods.
For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.
First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:
Supports process tailoring. Goal diagram, visit for examples, make it very clear how DAD enables people to make intelligent process decisions.
Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors.
Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.
Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?
Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.
It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless.
So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
© Disciplined Agile Consortium

12. DAD Teams Are Enterprise Aware
Disciplined agilists:
Work closely with enterprise groups
Follow existing roadmap(s) where appropriate
Leverage existing assets
Enhance existing assets
People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team. This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team.
By working in an enterprise aware manner DAD teams enjoy:
Higher levels of productivity because they are less likely to reinvent the wheel
Quicker times to deployment/market because they have less work to do
Higher return on investment (ROI) because they have less work to do
Higher levels of quality through following common conventions and reuse
© Disciplined Agile Consortium

13. Context Counts – Tailoring and Scaling Agile
Introduction to Disciplined Agile Delivery
Context Counts – Tailoring and Scaling Agile
DAD provides the foundation from which to scale:
Large teams
Geographically distributed teams
Compliance
Domain complexity
Technical complexity
Organizational distribution
Agility at Scale
Disciplined Agile Delivery
Delivery focus
Risk-value driven lifecycle
Self-organization with appropriate governance
Goal driven
Enterprise aware
To understand the need for the Disciplined Agile Delivery (DAD) process framework you must start by recognizing the realities of the situation which you face. The Process Context Framework (PCF) defines a roadmap to effectively adopt and tailor agile strategies to meet the unique challenges faced by an agile software development team. The first step to scaling agile strategies is to adopt a disciplined agile delivery lifecycle that scales mainstream agile construction strategies to address the full delivery process from project initiation to deployment into production. The second step is to recognize which scaling factors, if any, are applicable to your project team and then tailor your adopted strategies to address the range of complexities the team faces.
Agile
Construction focus
Value driven lifecycle
Self-organizing teams
Prescriptive
Project team aware
© Disciplined Agile Consortium
© Scott Ambler + Associates

14. Governance is Built Into DAD
Governance strategies built into DAD:
Risk-value lifecycle
Light-weight milestone reviews
“Standard” opportunities for increased visibility and to steer the team provided by agile
Enterprise awareness
Robust stakeholder definition
© Disciplined Agile Consortium

15. Disciplined Agile Delivery: The Foundation for Scaling Agile
Compliance
Domain Complexity
Technical
Complexity
Geographic
Distribution
Team Size
Organizational
Distribution
Disciplined Agile Delivery (DAD)
Scrum
Lean
Kanban XP
Agile Modeling
And more…
SAFe
Outside In Dev.
The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum. We felt that the first step was to identify how to successfully develop a solution from end-to-end. Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together. This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.
The DAD framework provides a better foundation for scaling agile:
Risk and value driven lifecycle. Scrum has what is called a value driven lifecycle. Work is prioritized by value to the business and is performed in priority order. This is a pretty good approach, but it’s possible to do better. Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk. Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of succeeding early. A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success.
Self organization with effective governance. There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy. But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem. Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams.
Delivery of consumable solutions over construction of working software. There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus. First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project. DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project. The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach. Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle. Second, agile teams do far more than produce software. We create supporting documentation. The software runs on hardware that may need to be upgraded and/or redeployed. We potentially change the business process around the usage of the system we’re producing. We may even affect changes to the organization structure of the people using the system. In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”. Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want. What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals. The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal.
Enterprise awareness over team awareness. We alluded to this in point #2. Disciplined agile teams recognize that they work in a larger organizational ecosystem. This enterprise awareness motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization. Done right this increases a team’s ability to deliver.
Context-sensitive and goal driven over prescriptive. One process size does not fit all. A strategy that works for a small co-located team will put a large geographically distributed team at risk. A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship). So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in. DAD describes a straightforward, easy to consume strategy that is goal driven
DAD leverages proven strategies from several sources,
providing a decision framework to guide your adoption and
tailoring of them in a context-driven manner.
© Disciplined Agile Consortium

16. What Does it Mean to Be Disciplined?
In general, it requires discipline to follow many agile practices and philosophies
But, it also requires discipline to:
Reduce the feedback cycle
Learn continuously
Deliver solutions incrementally
Be goal driven
Enterprise aware
Streamline Inception and Transition efforts
Adopt agile governance strategies
It is clear that many common agile practices require discipline. For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things. Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DAD takes it to the next level in the following ways:
Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles. Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations. There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by the DAD framework. These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.
Continuous learning. Continuous learning is an important aspect of agile software development in general, not just DAD. However, DAD explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise. It also addresses the need for three categories of learning: domain, technical, and process. Continuous learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, proving the architecture with working code, spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.
Incremental delivery of consumable solutions. Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline. The DAD process framework goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline. Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).
Being process goal-driven. The DAD framework promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial project planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.
Enterprise awareness. Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly. It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so. Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise. Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.
Adopting a full delivery lifecycle. Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do. Building serious solutions requires a lot more than just doing the cool construction stuff. It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle. The basic and advanced DAD lifecycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).
Streamlining inception activities. We devoted a lot of material in the DAD book to describing how to effectively address how to initiate a DAD project. Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications. Some people have referred to the practice of doing too much transitory documentation up front on an agile project (known as Sprint 0 in Scrum) as Water-Scrum-Fall. We cannot stress enough that this is NOT the intent of the Inception phase. While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible. If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach. It takes discipline to be aware of this trap and to streamline your approach as much as possible.
Streamlining transition activities. In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies. For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment. However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible. This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.
Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams. Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives. It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.
Moving to lean. For all DAD process goals we describe a range of options to address the issues pertaining to that goal. These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies. Generally, the leaner the strategy the greater the discipline it requires.
© Disciplined Agile Consortium

17. Shuhari and Disciplined Agile Certification
Module 2 - Agile Foundations
Shuhari and Disciplined Agile Certification
At the shu stage you are beginning to learn the techniques and philosophies of disciplined agile development. Your goal is to build a strong foundation from which to build upon. At the ha stage you reflect upon and question why disciplined agile strategies work, seeking to understand the range of strategies available to you and when they are best applied. At the ri stage you seek to extend and improve upon disciplined agile techniques, sharing your learnings with others.
We have adopted a Shuhari strategy for this certification program.  Shuhari is a martial arts concept that represents the stages of someone's learning:
Shu (Learn). At the shu stage you are beginning to learn the techniques and philosophies of disciplined agile development.  Your goal is to build a strong foundation from which to build upon.  This beginner stage of learning is represented by the Disciplined Agilist-Yellow Belt certification.
Ha (Detach).  At the ha stage you reflect upon and question why disciplined agile strategies work, seeking to understand the range of strategies available to you and when they are best applied. This intermediate stage of learning is represented by the Disciplined Agilist-Green Belt certification.
Ri (Transcend). At the ri stage you seek to extend and improve upon disciplined agile techniques, sharing your learnings with others. This "master" stage of learning is represented by the Disciplined Agilist-Black Belt certification.
© Disciplined Agile Consortium
© Scott Ambler + Associates

18. DAD Resources
Disciplined Agile Delivery: A Practitioner’s Guide, by Scott Ambler & Mark Lines
DAD Blog:
DAD Certification:
DAD LinkedIn Discussion Group: