FAQ

Here are some of the common questions that we get regarding Disciplined Agile Delivery (DAD).  If we’ve missed something, feel free to contact us with new question(s).

The FAQ is organized into the following sections:

 

The DAD Lifecycle

 

Is DAD an example of Water-Scrum-Fall?

No.  Water-Scrum-Fall (WSF) is a term coined by Dave West, the gentleman who wrote the foreword for the DAD book, when he was an Analyst with Forrester.  WSF refers to the unfortunate practice of doing heavy upfront modeling and planning early in the project to initiate it, a Scrum-based approach during construction, followed by a heavy/long deployment process.  WSF is a symptom of an organization that hasn’t yet made a full transition to agile and is a problem that seems to be exacerbated by the Scrum lifecycle’s focus on Construction activities (leaving the details of how to start and end a project up to you).  DAD promotes following a full delivery lifecycle – be it a Scrum-based one, an agile one, a continuous delivery one, or something else — that is as light as your situation allows.

Why are there phases?

DAD promotes a full delivery lifecycle and as a result defines three explicit phases: Inception where you initiate the project, Construction where you build/configure the solution, and Transition where you deploy the solution into production or the marketplace.   We chose to explicitly address the full delivery lifecycle, instead of just the “fun” construction portion of it, after empirically observing that the vast majority of agile teams do in fact need to do some explicit up front work to get going, a fair bit of construction work, and some work to deploy.  We also saw that many teams were struggling to be agile for all parts of the lifecycle, see the earlier discussion about Water-Scrum-Fall, and felt the only responsible thing to do was provide advice for the full delivery lifecycle.  For more on this topic, see the blog posting Why are there phases?

What’s happened to Elaboration?

The three phase names in DAD – Inception, Construction, and Transition – are adopted from the Unified Process (UP).  We could just as easily have called these phases Initiate, Construct, and Deploy.  Or Start, Do, and Release.  Or Sprint Zero, Create, and Ship.  Or… you get the picture.  We had to choose something and the UP phase names were as good as any.

However, people familiar with UP have noticed that we have three phases, not four.  In DAD there isn’t an Elaboration phase.  We dropped Elaboration for two reasons.  First, we have worked with many organizations that took the four UP phases and misapplied them to be the traditional Requirements, Architecture, Program, and Test phases.  We didn’t want to make it easy to do that with DAD.  Second, with the Proven Architecture milestone we kept the Elaboration baby, that of reducing technical risk early in the project by building an end-to-end working skeleton of the system that implements high-risk requirements early, but threw out the bureaucratic bathwater associated with having an extra phase.

Is there a feedback loop from “Transition”?

Yes.  In the high-level lifecycle diagram we show this but in the more detailed diagrams we currently do not.  We may update the diagrams at some point to do so seeing as we are often asked this question.

 

DAD and Other Methods

 

How does DAD compare with Scrum?

There are several ways that DAD differs from Scrum:

  1. Greater lifecycle breadth.  DAD supports a full delivery lifecycle, going beyond Scrum’s construction lifecycle to also provide advice for how to effectively initiate an agile project (or product) and how to transition/release into production.  In other words it helps take some of the mystery out of how all this agile stuff actually works in practice.
  2. Focus on enterprise awareness.  A strength of Scrum is its inward focus within a project team to minimize distractions and thus enabling the team to focus on delivering on its commitments to their stakeholders.  Focus is achieved using concepts such as the Product Owner, collocation, whole team, and daily Scrums.  However, this inward focus and self reliance can lead to silo behaviour whereby the team ignores enterprise concerns such as basic governance, reuse of assets, patterns, templates and guidelines.  Disparate architectures and systems that are difficult to maintain can result.  DAD encourages teams to be enterprise aware, and to include the Architecture Owner role, to ensure that good enterprise practices are not ignored and that collaboration occurs between projects and enterprise authorities as required.
  3. Greater practice breadth.  DAD is a hybrid decision process framework that adopts strategies from a wide range of sources, including Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Outside In Development (OID) and many more and shows how they fit together.  Instead of focusing on a small part of the overall delivery process, as Scrum does, DAD addresses a much wider scope and as a result provides more robust and effective guidance to agile teams.
  4. Less prescription.  DAD promotes a goals-driven approach which enables more effective tailoring and scaling.  For example, one of the DAD process goals is Address Changing Stakeholder Needs.  Where Scrum prescribes a single way to do this, the product backlog, DAD gives you several options (Product Backlog, Work Item List, Work Item Pool, Formal Change Management) as well as advice for when to consider each strategy.  DAD also defaults to Work Item List, a more robust extension of a Product Backlog, giving you a good starting point.  Another goal is Coordinate Activities.  Where Scrum prescribes a 15 minute daily meeting called a Daily Scrum Meeting or Daily Stand Up, DAD gives you several options to choose from and walks you through how to choose the right approach for you.
  5. Less branding.  One of the philosophies we took when describing DAD was that we wanted to move away from the process branding that we’ve seen occuring in the agile community.  Although DAD is flexible when it comes to terminology, for example if you want to use the term Sprint instead of Iteration then go right ahead, DAD defaults to non-branded terms.  So for example we use the terms Coordination Meeting over Scrum Meeting, Team Lead over ScrumMaster, Retrospective over Sprint Retrospective, and so on.

We believe that Scrum is a good starting point for teams new to agile.  However, organizations that adopt Scrum find that the either choose to do a fair bit of work to extend Scrum to address the challenges we mention above or they choose to jump start that effort by adopting DAD.  We can help you to transition from Scrum to a more disciplined approach.

How does DAD compare with Scaled Agile Framework (SAFe)?

DAD and SAFe are complementary.  SAFe focuses on scaling agile approaches across an organization whereas DAD focuses on providing a solid foundation from which to scale agile approaches to address the complexities of large teams, geographic distribution, technical complexity, and other scaling factors.   SAFe calls out three levels of scaling – project, program, and portfolio – although currently focuses on program and portfolio.  DAD can easily fit into the project level in SAFe (SAFe current shows Scrum there, and DAD extends Scrum) and actually provides clear hooks such as enterprise awareness and a process goal-driven approach which we believe enables a much better fit to SAFe than does Scrum.  An interesting observation is that both DAD and SAFe come from people with a solid background in the Unified Process (UP).

How does DAD compare with Rational Unified Process (RUP)?

DAD is a hybrid process decision framework that covers much of the same ground that RUP does.  RAD adopts some ideas from the Unified Process (UP), in particular ideas around governance and risk mitigation, it also avoids many of the challenges that RUP instantiations appear to exhibit.  Unfortunately RUP was often mistakenly instantiated as a waterfall process or it was instantiated in a very heavy manner (or both).   DAD instantiations should avoid both of these mistakes through its three phase lifecycle (instead of RUP’s four phases) and through its goal-driven approach which makes it incredibly clear what the challenges are surrounding process heavy strategies.   For more details, read Comparing DAD to the RUP Part 1 and Part 2We can help you to transition from RUP to DAD effectively.

How does DAD compare with IBM’s agility @ scale strategy?

DAD emerged from the IBM agility @ scale strategy and is still an integral part of it.  Contact IBM Rational for more details.   Furthermore, although the DAD framework originated with IBM it now comes from Disciplined Agile Consortium (DAC).

How do DAD and Capability Maturity Model Integrated (CMMI) fit together?

We like to think of CMMI as a specification for a process.  It indicates what the Software Engineering Institute (SEI) believes to be a good set of requirements for a process but leaves the implementation up to you.  So, CMM- compliant processes could follow a waterfall paradigm (they often do), an agile paradigm (they sometimes do), or another paradigm.  CMMI-compliant processes could be instantiated in a heavy manner (they often are) or a light-weight manner (they sometimes are).  It’s up to you.

DAD, on the other hand, provides more concrete advice regarding how to go about solution delivery in an agile/lean manner and provides more concrete tailoring advice to help you adopt the right strategy for the context of the situation you find yourself in.   You may choose to do this in a CMMI compliant manner.  In fact, we explicitly call out Compliance as a potential scaling factor which might driven process tailoring decisions in DAD.

How do DAD and PMI/Prince fit together?

The scope of DAD is software-based solution delivery, so yes, it encompasses project management activities.  The good news is that strategies such as PMI and Prince are moving towards being more agile, the bad news is that they’re not there yet.  The implication is that you’ll need to work with these people in your organizations to help them understand and adopt more agile ways of working.

 

General Questions

 

Why DAD?

There are several reasons why you should be interested in the DAD framework:

  • It provides a foundation from which to scale agile software delivery.
  • There is no single strategy (such as Agile/Scrum, Lean, SAFe that applies to all situations.  People will need to make many process decisions at many levels to maximize their chances of success.
  • Not everyone is a process expert.  The DAD process decision framework can lead to better decision making.
  • DAD is pragmatic, not dogmatic.

Read Why DAD? for more details.

What differentiates DAD from other frameworks/methods?

Unlike other options, DAD is not a prescriptive framework.  It is a process decision framework designed to provide various strategies to facilitate better process decision making for the unique context of your situation.

We don’t believe that one framework such as SAFe is best used for all scaling situations.  For example, there are several ways to organize large agile teams (a single large team, several feature teams, several component teams or hybrids of these).  Instead of prescribing one strategy DAD instead provides guidance to select the strategy that makes sense in a given situation.  Similarly, you will evolve your strategy to reflect the geographic distribution of your team, the level of complexity that you face, the culture of team, any regulatory compliance requirements, the organizational distribution of your team (e.g. are you outsourcing some work), and other factors.  See the Software Development Context Framework (SDCF) for some detailed thoughts on this.

DAD’s process goal driven approach makes your choices explicit.  It provides straightforward guidance for surfacing your process related options and then understanding the trade-offs of those options.  This in effect helps teams to up their game in retrospectives. With such an approach it is easier for a team to really own their process.

An interesting thing about this goal driven strategy is that it surfaces strategies that are questionable in most situations, such as writing a detailed requirements specification early in the lifecycle.  This strategy may make sense in some circumstances, for example in life-critical regulatory situations, but in most situations is less than ideal.  The DAD frameworks makes the advantages of this strategy (not many) and the disadvantages (many) of such a strategy clear, in the hopes that it will give people who still believe in such an approach insight into the risks that they’re taking on.  More importantly DAD also provides guidance for better options, hopefully prompting them to get on the path of process improvement.

Why are there primary and secondary roles in DAD?

The primary roles (Team Lead, Team Member, Product Owner, Stakeholder, Architecture Owner) are the ones that you will typically see in most agile situations.  The secondary roles (Domain Expert, Technical Expert, Specialist, Integrator, Independent Tester) are often needed in scaling situations.

Can we still make mistakes?

Yes, there are no guarantees.  However, we believe that the DAD framework will help you to make more informed process decisions through its support for a full delivery lifecycle, its process-goals driven approach, and the fact that its a hybrid taking ideas from a wide range of sources (including non-agile ones).

What are the disadvantages of DAD?

There are a few potential issues with the DAD framework:

  • DAD makes the complexities of solution delivery clear, which can overwhelm anyone looking for a simple, “just tell me what to do” strategy.  To address this DAD suggests some default strategies to start with, many of which are very similar to what is promoted by Scrum.
  • DAD is still in its early days so it is not as well known as other frameworks.

Is there tooling support for DAD?

Yes.  Please read Tool Support for DAD for more details.

  1. Patrick McGovern
    February 27, 2014 at 7:08 am

    Hi Scott, I really like this approach, thanks. It resolves some serious apprehensions I have around pure Scrum approaches. I was wondering if you’ve done any research into how the bid process needs to change on an Agile engagement. It seems like the same problem we faced with RUP; you don’t know what you don’t know.

  2. February 27, 2014 at 8:12 am

    Thanks. I’ve written up a fair bit of stuff around initial estimating but haven’t really done much writing around agile contracting per se. If you go poking around on the net you’ll find a fair bit of material on this subject though.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 598 other followers