Disciplined Agile

DAD teams focus on producing repeatable results, such as delivering high-quality software which meets stakeholder needs in a timely and cost effective manner.  DAD teams do not strive to follow repeatable processes.  The observation is that because each DAD team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  The point is that each team in your organization may follow a different process, albeit processes which share similar components defined by a common process framework, while achieving the results required of them.

This may of course be heresy in some organizations.  The danger with “repeatable processes” is that they grow in size over the years to address all possible situations, and as a result address none of them very well.  Imagine a project team that is large and has regulatory compliance concerns.  This team will tailor its practices accordingly.  Now imagine a small team that doesn’t have to address regulatory concerns.  An organization focused on repeatable processes might have that team follow the same process that the previous team followed, even though some of the practices had been tailored to meet scaling factors that don’t apply.  In other words, the repeatable process included some aspects that were overkill for the second team, thereby impacting their ability to deliver in a timely manner or in a cost efficient manner.  In the vast majority of organizations, when given the choice, stakeholders prefer to spend the money wisely and have the solution delivered in a timely manner, not to have the team follow a consistently “repeatable process.”

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 Agile (Scrum-based) and Lean (Kanban-based) DAD lifecycles explicitly depict:

1. Pre-delivery activities.  There are portfolio management activities which occur long before your project begins, including the initial identification of potential projects, their prioritization, and finding initial funding for the Inception phase.
2. Three-phase delivery lifecycle.  Projects have phases that they go through.  All efforts are initiated at some point, all of them go through a construction effort (or a configuration effort in the case of purchased solutions), and hopefully some sort of deployment effort.  This is why the DAD lifecycles include explicit Inception, Construction, and Transition phases to respectively address these aspects.  We’ve confirmed via surveys that the agile teams invest time in project initiation/inception activities, often referred to as Sprint 0 or Iteration 0, and time performing release/transition activities.  From a product point they will go through at least the Construction and Transition phase many times throughout the life of the solution.
3. Post-delivery activities.  The fact that your solution is operated and supported in production, or in the marketplace for commercial products, is included.  We do this to reflect the DevOps reality many DAD teams are in the position that they are working on a new release of an existing solution, and therefore are very likely to be getting defect reports and enhancement requests coming in about previous versions.  As a result they require the discipline to treat these things as potential new requirements and act accordingly.

Without a doubt construction is an important aspect of the overall Disciplined Agile Delivery process, but it’s not the only aspect.  Yes, for many people this is the fun part of delivery, it certainly is for me.  But the reality is that as development professionals we need to explicitly consider more than just construction if we’re to be effective.  It takes discipline to adopt a broader lifecycle that goes beyond the fun stuff that we would prefer to focus on.

We are thrilled to confirm that our new book “Disciplined Agile Delivery:  A Practitioner’s Guide to Agile Software Delivery in the Enterprise” will be launched at the IBM Innovate conference in Orlando June 3-7.  It will be a busy week with the following events planned:

Scott will be co-delivering the Agile Transformation track keynote on Tuesday morning with Scott Rich, the development leader of the Jazz team. That afternoon he will be a participant at the Agile and Systems goldfish bowl. Wednesday morning Scott will be delivering his Disciplined Agile Delivery and DevOps talk and then in the afternoon giving an overview of Agile Modeling and Documentation strategies. Throughout the conference Scott will be meeting with customers, contact your IBM sales rep if you want to organize such a meeting, and doing several press interviews.

On Wednesday Mark will be speaking on “Disciplined Agile Delivery:  Adoption in the Trenches”.  On Monday he will be on the “Agile Coaching 101 Panel” with agile/lean thought leaders such as Mary Poppendieck.  Mark will also be at the Canadian reception Monday night at Blue Zoo.

Mark & Scott will also be doing a book signing on Wednesday at the bookstore.

If you miss the signing and want a book signed, try the Agile Transformation Zone in the Exhibit Hall.  There is a good chance that you will find us there, comparing notes with other agilists and discussing the challenges of disciplined agile adoption in the enterprise.

It promises to be a fun week, with the party at Sea World and the band Foreigner playing.  We hope to see you there!

The DAD process framework uses a goal-driven approach as we illustrate in Figure 1 below.  Throughout our book we  described each of the DAD phases in turn and suggested strategies for addressing the goals of that phase. For each goal we described the issues pertaining to that the goal.  For example, in Chapter 10 when we discussed initial project planning we indicated that 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.

Figure 1. Goals addressed throughout a DAD project (updated).

Since the book was published in June 2012 Mark and I have made a few minor refactorings to the DAD goals to increase their consumability.  Figure 2 presents the goals as they were originally described in the book, whereas Figure 1 shows our refactoring.  As you can see there has been a few minor rewordings but the actual content remains effectively the same.  We apologize for any confusion, but process improvement happens.  ??

Figure 2. Goals addressed throughout a DAD project (original as published in the DAD book).

DAD lays out a set of milestones across the lifecycle that are common across most projects regardless of what agile practices you use.  It takes discipline to use a goal-driven approach to reach those milestones.  This means that you do not use a cookbook approach to deliver your solutions but rather adapt your techniques to follow the path that is best suited to you.  Prescriptive guidance and rules are common in many agile methods and people can easily fall into a trap of doing exactly what is dictated by a particular method without challenging how appropriate it is for their own situation.

Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline.  The Disciplined Agile Delivery (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 which your team executes requires the discipline to address:

• Working software that is “done”.  Your software should be tested to the best of your ability.  Ideally this includes pre-production integration testing and acceptance testing of the functionality delivered to date.  The software should not only fulfill the functional requirements but appropriate non-functional requirements (NFRs) as well.  Some of this testing may require the help of an independent test team, particularly at scale.
• Continuous documentation.  Deliverable documentation, such as operations and support, system overview, and end user documentation are part of your overall solution. Evolving this documentation in sync with the software requires greater discipline than simply leaving this documentation to the end of the lifecycle.
• Consumability. Your solution should be more than potentially shippable, it should also be consumable.  This requires investing some effort in user experience (UX) design throughout the lifecycle, particularly early in the project.
• Organizational change.  The business processes around using your system, and potentially even the organizational structure of the stakeholders involved with it, may need to evolve.  The implication is that your team needs the discipline to recognize and explore these issues throughout the project so that your stakeholders are prepared to receive your solution.
• Operations and support issues.  Your solution should be consumable by all stakeholders, not just end users.  Your operations and support staff should be able to work with the solution efficiently.  To understand these needs your team needs the discipline to work closely with operations and support staff throughout the lifecycle, an important aspect of your overall DevOps strategy.