Disciplined Agile

DAD incorporates a number of milestones into its lifecycles to gauge the progress and health of your DAD projects/releases.

Why does DAD have milestones?

Governance is largely absent from mainstream agile methods and many believe that agile does not need milestones.   Scrum orders its backlog with highest value work at the top of the stack.  At the end of each sprint (iteration) a decision is intended to be made whether or not the next sprint of work in the backlog provides sufficient value to fund another sprint.  If not, the project stops.  While in principle this strategy makes sense, as a replacement for governance it is flawed for several reasons:

• Not sufficient.  There is much more to effective governance than deciding when to cease the funding of a project.  How did it get started in the first place for instance?
• Not realistic.  In reality most organizations tend to fund releases comprised of many iterations rather than make explicit funding decisions at the end of each sprint.
• Effectively a milestone.  While Scrum claims to not have milestones, pausing to consider if sufficient functionality exists to deploy, and to determine a go-forward strategy is implicitly a milestone.  DAD makes them explicit with guidance for how to effectively apply them.

Why do we need agile governance?

Contrary to what many believe, the need for governance does not disappear for agile initiatives.  Sponsors and other stakeholders deserve and indeed demand periodic updates on the status of their investments.  They want answers to questions like:

• What will I get from my investment and will it be worthwhile?
• Is what is being delivered consistent with the initial funding request?
• What is the status of the outstanding risks and what is being done to mitigate them?
• Is the current release timeline consistent with the original projection?
• When will we have sufficient functionality to go live?
• Are all stakeholders prepared to receive the release?
• When will the project be finished?

Claims that agile is “different” and does not need to provide these answers is one of the reasons that agile is sometimes seen as being undisciplined.  In fact these claims are often used by some as an excuse why agile won’t work for them.  Fortunately, since DAD has built in mechanisms to facilitate answering these questions many organizations are extending their agile implementations to incorporate DAD’s guidance.  Indeed DAD is very appealing to those looking for a way to govern projects while still remaining agile.

Milestone Reviews Should Be Kept Informal

Consistent with the strategy recommended in the DAD goal Govern Delivery Team, milestone reviews should be done in a light manner.  They typically coincide with the end of iterations or phases when when using the Agile/Basic lifecycle.  If you are unsure why DAD has phases you might find the blog posting on the rationale interesting.

Milestone Dates Should Be Communicated

It is a good practice to provide a calendar to stakeholders with milestone dates for each DAD project so that they can plan to attend iteration reviews that coincide with milestone reviews that they are interested in.  While milestone dates may change, it is very useful to have target milestones across a portfolio of projects visible as a roadmap to all stakeholders.

The DAD Milestones

Stakeholder Vision.  The goal of the Inception phase is to spend a short yet sufficient amount of time, typically one to four weeks in order gain stakeholder agreement that the initiative makes sense and to therefore continue into the Construction phase.  By addressing each of the DAD Inception goals the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as lightweight a fashion as possible.  This information is consolidated and presented to stakeholders as a Vision statement as described by the Develop Common Vision goal.  The format of the vision and formality of review with vary according to your situation.  A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

Proven Architecture.  Early risk mitigation on a project is a part of any good project management discipline.  As the Prove Architecture Early process goal indicates, there are several strategies you may choose to adopt to do so.  The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements.  A key responsibility of DAD’s Architecture Owner role is to identify risks in the Inception phase.  It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase.  As a result of applying this approach early iteration reviews/demos often show the ability of the solution to support non-functional requirements in addition to, or instead of functional requirements.  For this reason it is important that architecture related stakeholders are given the opportunity to participate in these milestone reviews.

Continued Viability.  An optional milestone to include in your release schedule is related to project viability.  At certain times during the project stakeholders may request a checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.  Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary.  These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially cancelling the project.  There could be several of these milestones.  If the stakeholders agree to changes the Vision may be updated at this time.  Scrum implicitly has this milestone at the end of each sprint.  DAD makes this an explicit choice and makes it’s frequency optional.

Sufficient Functionality.  While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy.  While this is sometimes referred to as a minimally viable product (MVP) this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality.  The more accurate term to compare to this milestone would be “minimum feature set”.  Regardless, many use the acronym to mean the latter.

DAD’s sufficient functionality milestone is reached at the end of the Construction phase when a sufficient functionality is available plus the cost of transitioning the release to stakeholders is justified.  As an example, while an increment of a consumable solution may be available every two week iteration, it may take two weeks to actually deploy it in a high compliance environment so the cost of transitioning the functionality may not be justified until a greater amount of functionality is completed.

Production Ready.  For non-trivial situations a formal Transition phase is often required to do final preparations as part of delivery of the solution to stakeholders.  Once sufficient functionality has been developed and tested, transition related activities such as data conversions, final acceptance testing, production and support related documentation normally need to be completed. Ideally much of the work has been done continuously during the Construction phase as part of completing each increment of functionality. At some point a decision needs to be made that the solution is ready for production.  Of course, if you’re following the continuous delivery lifecycle then the “Transition phase” has evolved into a “Transition activity” – regardless, someone still needs to ensure that the solution is consumable before you deploy the solution.

Delighted Stakeholders.  Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere.  The initiative doesn’t end the day after deploying a solution to stakeholders.  There are often project closeout activities such as training, deployment tuning, support handoffs, post implementation reviews, or even warranty periods before the project is considered completed.  Lean has a term “delighted customers” which suggests that “satisfied” customers is setting the bar too low.  While DAD agrees, there are more stakeholders than just customers such as production support that we need to delight before we consider the project complete, thus the milestone name “delighted stakeholders”.

Give Milestones a Try

Agile promotes transparency and accountability to our stakeholders.  Take this to the next level by sharing and celebrating achievement of key milestones on your projects.

Looking for some great DAD video content?  Trying to find just the right video to show your boss why moving beyond Scrum to DAD makes sense?  Well we are happy to announce that there is now a DAD YouTube Channel which can be found here:  https://www.youtube.com/channel/UCcWJ20C86Mzxcsqb73AReHQ  Subscribe to keep up to date on the latest DAD talks and webinars.  There is also a new link to this channel at the DAD blog website on the sidebar.

We are looking for multilingual presentations so if you are aware of any let us know.  For now we have added a talk in Russian.

With some basic agile training and help from an agile coach it can be relatively straightforward to enable several teams to be able to produce increments of consumable software every two weeks.  Unfortunately many organizations stop there, believing that they are “now agile”.

For enterprise agile adoptions starting a few agile teams is the easy part and is just the beginning of your agile transformation.  Proving the benefits and sustaining the change is significantly more challenging.

For illustration purposes, let’s assume that over a six month period we have conducted a series of Disciplined Agile workshops and kickstarted twelve teams.  The teams have separate product owners with their own work item lists.  Some of the teams use the DAD basic Scrum-based lifecycle while others use the DAD Lean lifecycle.  The Scrum teams adapt their lifecycle for their context with the simpler projects having a one week Inception phase while the more complex projects use a two week Inception.  For the Construction phase novice Scrum teams use two week iterations while the more advanced teams chose one week iterations.  The teams vary in size from four to twelve team members.  By rolling out the teams in an incremental fashion, with some coaching the teams have learned the key DAD practices for being effective on both the Scrum and Lean teams.  Word is spreading that the teams are impressing stakeholders with regular demonstrations of new functionality.

However, after the honeymoon period is over, people start to ask some interesting questions such as:

• What are the limits of self-organization?  I understand that teams are free to customize their own processes but isn’t some consistency good across teams?
• What are the key milestones for each team?  What is the release schedule for each team?  Are the teams on track for delivering the solution consistent with their Inception vision?  How do I see this information?
• How do I know which teams have the greatest risks outstanding?
• What is our product roadmap strategy across teams?
• How do we measure the effectiveness of one team vs. another?
• How do we measure the effectiveness of individual team members?
• What is the new career path for agile team members?
• How to we adjust compensation plans to encourage effective team behavior and reward individual contributions?
• Has our quality assurance group adapted for agile to have the appropriate mix of embedded vs independent testers?
• Do we have less technical debt than before agile?  How do I know if our quality is improving?
• How do I know that teams are effectively engaging with enterprise authorities such as architecture, data, and quality assurance?
• How can management use agile and lean principles themselves?

These are all fair questions.  For your agile adoption to be effective and sustainable you need a strategy to address all of these issues.  The Disciplined Agile Manifesto adds a principle to the Agile Manifesto regarding the need to adapt your organizational ecosystem to be effective for enterprise agile adoptions:

The need for good governance doesn’t go away with agile.  Your stakeholders deserve the right to gauge the health of their investments in your agile initiatives just like any other project.  There are indeed answers and various strategies for all of the above questions which will vary depending on the context of your situation.  Like it or not, the reality is that effective and sustainable agile transformations can take several years in order to achieve the level of capability and maturity that you expect.  A transformation is a journey, not a destination.  Make sure that your agile coaches have answers to the questions above and know what to do after your Scrum honeymoon period is over.  We will outline some DAD strategies for the questions above in future posts.

For a more detailed discussion of how DAD extends Scrum, please read the whitepaper Going Beyond Scrum.

When we describe DAD we remind people that it is not another agile method as we clearly have enough of those already.  Rather, DAD is a process decision framework that enables better decision making when customizing approaches for adopting agile within the context of your organization and projects.  Popular agile methods can be quite prescriptive.  Sometimes their agile rules – work collocated in one room, use teams less than nine people, or don’t do fixed price projects – are not practical.  Rather than discounting such projects as not agile, why not take a pragmatic approach to dealing with these realities while striving to still be as agile as possible?  DAD provides the guidance that enables you to easily tailor, and later evolve, your agile approach to effectively address the context of the situation that you find yourself in.  Hence the term process decision framework.

Another way to look at DAD is that is “pragmatic agile”.  In their book The Pragmatic Programmer, Andrew Hunt and David Thomas describe the need for programmers to be inquisitive, critical thinkers who are realistic and jack-of-all-trades (what we call generalizing specialists).  These qualities are consistent with those we describe for all team members on DAD projects.  This pragmatism reflects the need for agilists to abandon dogmatic, purist approaches to implementing agile and recognize the need to adapt for the complexities of most enterprise projects.  We often encounter management that is frustrated with agile teams that ignore organizational standards and resist compliance with any sort of governance that seeks measure things such as the health, risks, and return on investment for these agile projects.  In return, agile teams often say that management just doesn’t get it.  Surely there is a compromise here.  Management needs to understand that they need to adapt their approach to governing agile projects and agile teams need to be flexible in dealing with the realities of building software solutions for the enterprise.

Why is DAD pragmatic agile?  We feel that it is pragmatic to:

• Take a goal-driven approach which describes the agile strategies available to you, the advantages of disadvantages of each, and when to consider using each one.
• Invest a small amount of time prior to beginning construction to get going in the right direction.  We frame this endeavour in terms of the goals described below in the Inception phase section of Figure 1.
• Plan to spend some time after completing the construction of the solution to properly deploy it to your stakeholders.  This is described via a goal-driven strategie as shown in the Transition phase section of Figure 1
• Do some lookahead planning and modeling, often referred to as backlog grooming, on a just-in-time basis to be more effective when implementing work items during each iteration
• Leverage the existing organizational ecosystem to reuse existing services, patterns, templates, code, guidelines and other assets
• Govern the project teams in an agile manner
• Encourage project specific process improvement through self-organization within the constraints that make sense for the organization
• Adapt the types and formality of work products produced for the context of the projects

We have seen that DAD is certainly resonating with companies that have been struggling to create their own flavour of agile with Scrum, Extreme Programming (XP), and other approaches.  This roll-your-own approach can be difficult and expensive for companies to develop and then maintain.  DAD provides a complete and flexible framework that enterprises have been looking for, enabling them to get on with the actual job of delivering business value to their stakeholders.

How do we apply the toolkit to make better decisions and be pragmatic?  DAD is goal-driven.  Figure 1 shows the goals that are consistent with any type of software development effort regardless of type,  whether it be custom development or implementing a package for instance.

Figure 1.  The Process Goals of Disciplined Agile Delivery.

Figure 2 shows an example of a process goal diagram to show how to fulfill a particular goal.  To address the Explore The Initial Scope process goal we need to consider various issues or factors in order to be most effective for the context that we find ourselves in.  This goal is an important part of the Inception phase so that we can move towards obtaining stakeholder consensus that it makes sense to move into the Construction phase and begin building the solution.  For each issue there are a number of choices.  Some choices, such as work item stack, are bolded and italicized indicate good choices as a place to start for a typical DAD project.  Some issues show an arrow beside the options which is an indication that the choices at the top are typically the most effective and the better alternatives to strive for.  A typical project will make hundreds of process decisions and these diagrams can be used to ensure that the various options are considered.  An example of a decision might be what view type might I use to depict my scope?  DAD recommends starting with a combination of usage modeling, domain modeling, and non-functional requirements.  For usage modeling, user stories is the most popular agile approach, but you could also create use case diagrams or personas as needed.  The DAD book describes each of the alternatives, as well as their advantages and disadvantages of each.  In this way, DAD helps us make better decisions.

Figure 2.  Process Goal Diagram: Explore the Initial Scope.

Is pragmatic agile an excuse for taking shortcuts?  Although the DAD philosophy seeks to be as agile as possible, it is not an excuse for being lazy.  We use the term disciplined for a reason.  We often see organizations that are struggling with Scrum, and the root cause turns out to be that the teams are skipping some of the core Scrum practices.  For instance they may have decided that they have a good process and no longer need to do retrospectives.  In situations like these, the teams have abandoned one or more of the goals of a DAD project.  Referring back to Table 1, we can see that an ongoing goal is to Improve team process and environment.  Another example might be that the team does not do regular, end-of-iteration demonstrations.  Here they are not fulling the goal of Produce a potentially consumable solution.  Perhaps the teams says that they always have working software, but how do we know it is consumable?  Who as seen it?  Have the operations and support staff seen it?  Are end users actually eager to work with it?

As you can see, we can refer to the goals table and ask ourselves, “how are we fulfilling each of these goals?”.  Using this goals driven approach can help to ensure that you do not have gaps in your approach to implementing pragmatic agile.

Mark met the team that just finished the translation of the DAD book into Japanese here at IBM Innovate in Orlando.  They have created a Japanese version of the DAD Blog.  A link has been added on the main page to the Japanese blog in the Blogroll links section.  A big thank you goes out to the DAD community in Japan.  Perhaps we will run a DAD workshop there soon!