Post: Book Review
Title: Introduction to Disciplined Agile Delivery (second edition)
Subtitle: A Small Agile Team’s Journey from Scrum to Disciplined DevOps
Authors: Mark Lines & Scott W. Ambler

 

1. Introduction

DA (Disciplined Agile) is a hybrid of existing methods that provides the flebility to use various approaches as well as plugging some gaps not addressed by mainstream agile methods. Some quick facts about DAD:

• DAD is the delivery portion of the Disciplined Agile (DA) framework.
• Although DAD was originally developed at IBM, it’s now the intellectual property of the Disciplined Agile Consortium, and is freely avaliable for use.
• The certification program is described at https://disciplinedagileconsortium.org/.
• DA is not a replacement for existing agile and lean methods. It complements them and in many cases extends them to be enterprise ready.

 

2. Reality over rethoric

 

3. Disciplined Agile Delivery in a nutshell

DAD provides a pragmatic approach for addressing the unique situations in which team find themselves. This includes how to sucessfully initiate agile teams in a streamlined manner, how architecture fits into the agile lifecycle, how to address documentation effectively, quality issues in an enterprise environment, how agile analysis techniques are applied to address the myriad of stakeholders concerns, and many more.

Key Points:

• DAD is the delivery portion of DA framework, not just another methodology
• DAD provides 5 lifecycles to choose from; doesn’t prescribe a single way of working
• DAD focuses on achieving common goals in an agile manner
• DAD addresses key enterprise concerns not described by mainstream methods such as Scrum
• DAD is complementary to SAFe far less prescriptive
• DAD shows how agile works from beginning-to-end
• DAD provides a flexible foundation from which to scale mainstream methods

DAD is a people-first, learning-oriented, hybrid agile approach to IT solution delivery. It supports several risk-value delivery lifecycles, is goal-driven, enterprise aware, scalable, and reflects the realities of enterprise solution delivery.

People-first: Roles in Disciplined Agile Delivery.

Hybrid framework: combines strategies from a range of sources.

The focus of DAD is on delivery, although remember that other aspects of IT and your organization still exist such as Data Management, Architecture, Operations, Portfolio Management, and more. A full system/product lifecycle goes from the initial concept for the product, through delivery, to operations and support and often includes many iterations of the delivery lifecycle.

The figure below depicts a high-level view of the DAD lifecycle. The inner three phases – Inception, Construction and Transition – from the delivery portion of the lifecycle. During delivery you incrementally build and increasingly more consumable solution.

We recommend to access http://www.disciplinedagiledelivery.com/introduction-to-dad/  and visualize all the other lifecycles:

• The Agile/basic lifecycle (Scrum based)
• The Lean/advanced lifecycle (based on Kanban)
• The Continuous Delivery: Agile lifecycle
• The Continuous Delivery: Lean lifecycle
• The Exploratory/Lean Startup lifecycle

DAD are Goal-Driven: there are several advantages to taking a goal-driven – it provides a concise, shared pathway to leaner, less wasteful process decision; it supports process tailoring by making process decisions explicit; it enables effective scaling by guiding you through tailoring your strategy the realities of your scaling factors, etc.

The goal diagram for Explore Initial Scope (figure below) depicts a goal that you should address at the beginninf of the lifecycle during the Inception phase.

The process goals of DAD summarizes the goals grouped by the three phases of Inception, Construction and Transition as well as the goals are ongoing throughout the lifecycle.

The DAD distinguishes two types of “agility at scale”: Tactical agility at scale and  Strategic agility at scale. The figure below summarizes the potential tactical scaling factors that you need to consider when tailoring your agile strategy.

 

4. Introduction to the case study

From now on, the book describes a fictitious case study based on a retail bank called “BigBank”. The company would like to develop a solution to enable prospective customers to apply for a mortgage on-line. One of the first decisions that any team needs to make is which of DAD’s five lifecycles to use for this team.

This chapter also introduce the team (PO, Business Analyst – BA, Team Lead, Coach, Architecture Owner – AO, Developers, Tester and DBA), Stakeholders (IT VP, Sponsor, CSM, Enterprise Architect, Operations Manager, Support Supervisor, MKT VP and PMO Lead) and describes the market opportunity that they hope to address.

 

5. Inception

The Inception phase is an explicit team initiation effort. It should be as lightweight and short as possible. You plan at a high level to think through the major issues that you will face, trusting that your team will be able to handle the details as they envolve.

Team Kick-off Meeting: who is the sponsor to explain the need for the new system (MAP – Mortgage Application Portal) and how it’s a critical business initiative to attract new mortgage customer to the bank. They feel that is prudent to start with a longer Inception because the team is new to DAD and training will be part of this phase.

Week one of Inception
The team attends a 3-day DAD experience workshop to ensure everyone is on the same page and is familiar with Agile fundamentals and DAD.

• The PO works on identifying the initial scope (can use a Story Map)
• The AO leads the team in identifying the initial technical strategy

Week two of Inception

• The PO meets with the business stakeholders to prioritize the work
• The Team Lead, PO and AO meet to identify an initial list of risks
• The AO and PO meet to review the prioritized work item list
• The PO and the Dev Team conduct sizing of the work item list
• The team creates a release plan
• Estimating the number of iterations required

The release plan can include a high-level Gantt Chart to show the release schedule and associated milestones.

Week Three of Inception

• The Team Lead works with the Facilities group to set up a common work area for the team
• Also leads the team to update the risk list
• Summarizing the Inception work into a vision
  • Business goals of the initiative
  • Success criteria
  • Key Stakeholders and Roles
  • Vision (initial scope of the effort; initial technical strategy; initial release plan; work environment details; initial risks)
• The Stakeholder Vision milestone review

 

6. Construction Iteration C1

After the Inception (agreement around the approach that they are going to take), the team is ready to begin Construction.

Day 1: the team already invested time in Inception to estimate the release plan. So, now it’s created a task board to control the tasks, allocating the resources and updating the status of each one.

Day 2: is described the DoD (Definition of Done) to be discussed with the team and point out any changes do solution.

Day 3: one technical issue appears and it’s necessary to add six hours in the original estimation. No one can pair with Danny to get over this technical hurdle, so he needs to stay late.

Days 4-7: the team continues work and makes up for most of the time lost.

Day 8: it’s better to get as many work items “done” according to the DoD that is posted rather than 80% done on each story but nothing completely done.

Day 9: two resource pair together to implement a story. The team will be unable to fully prove that their architecture works until at least Iteration C2. The Team Lead works with PO to reschedule the milestone at the end of Iteration C2.

Day 10: the team spends the morning stabilizing the work items / stories that they have completed, doing exploratory testing, and fixing last minute defects.

Concluding the iteraton, the iteration review and the retrospective are executed by the team.

 

7. Construction Iteration C2

Iteration Planning Session and ten business days executing the backlog. A bit of thinking now will save a lot of time next iteration. In sequence, it happens the demo, the proven architecture milestone review and the retrospective. And the goal diagram for Produce a Potentially Consumable Solution which is presented.

The iteration goes a bit smoother for the team. The team begins to make improvements based on their retrospective from the previous iteration. More importantly they reach their second risk-based milestone, Proven Architecture, by delivering working end-to-end software that implements technically complex functionality. This greatly reduces the risk faced by the team.

 

8. Construction Iteration C3

The team is excited because the second iteration was successful and the daily coordination meetings are running much better. A pair programming is more frequent and backlog refinement (they identify new stories and drop a few of the low priority requirements). These changes result in what looks to be a 20% increase in scope.

And the PO decide to share with the team that decides to discuss the impact immediately after the lunch, sizing the new requirements and updating the burnup chart. After that, Patricia (PO) facilitates a one-hour meeting with the Sponsor and stakeholders to negotiate some of the lower priority requirements to be implemented in the next release.

The team finds that it has much less hardening to perform during this iteration. This is due to doing more testing earlier in the lifecycle. The demo goes very well. Terry (Team Lead) shares the updated release burnup chart with the team. The chart now shows two requirements lines, one showing the number of “must have” points and the other showing the grand total of points.

The retrospective begins with a review of how they’re doing with implementing the process improvements from previous iterations. The AO feels that they really should be evolving the supporting documentation along with the software that they’re building. This reflects DAD’s philosophy of developing consumable solutions, not just working software.

Carlos (Coach) suggests that the team adopt the practice of continuous documentation where they write the supporting documentation in parallel to writing the code (ex: using the wiki). He also offers to pair with anyone needing help.

 

9. Construction Iteration C7

Now the team is working smoothly, adding new value to MAP every two weeks. Ashok (AO) led the team through these hard technical decisions, exactly as an Architecture Owner should. Other points have been evolving:

• Stakeholder collaboration
• Test often, test early (automating acceptance tests and Continuous Integration)
• Automated deployment scripts
• Automated dashboard
• Planning (the team has firmly commited to a delivery date based on ten construction iterations. Also getting serious about deployment planning)
• The retrospective

 

10. Construction Iteration C10

The last Construction Iteration before Transition and the focus is on implementing a handful of high priority functionality and on final hardening of the solution.

Parallel independent testing in their pre-production testing environment has enabled the team to identify potential issues that had escaped their whole team testing efforts. Part of their hardening efforts is the finalization of training materials for the upcoming training of support staff.

 

11. Transition

The focus of the Transition is for a team to release their consumable solution into production successfully. This should be in as lightweight a manner as possible. The Transition Goals are: ensure the solution is consumable and deploy the solution.

Ensuring that the solution is ready to deploy, the team needs to:

• Perform final testing and fixing
• Support training of the help desk staff
• Finalize the deliverable documentation
• Support development of end-user training videos
• Validate the deployment scripts

 

12. The road to Disciplined DevOps

The Construction phase consists of seven two-weeks iterations. Here are the highlights practices of whats happens:

Release 2

• TDD – Test Driven Development
• Working from home (using tools to enable and after discussing with the team)
• Improvement tracking (ex: measured improvement where at each retrospective the team rates how well they are doing at addressing the previously identified improvements)
• The team evolves (while the team has grown to become extremely efficient and intends to stay together long-term, it’s a good idea to rotate team members to keep them stimulated and give them new learning opportunities)
• Parallel independent testing
• Vacations
• Sharing their learnings

Release 3

• Training (two-day training for example in ATDD and BDD)
• Requirements envisioning
• Improved quality
• Continuous deployment
• Adoption of ATDD (Acceptance Test-driven Development)
• Organizational support for Continuous Integration / Continuous Deployment
• Strategizing aroud DevOps

Release 4

• The team reworks MAP with DevOps capabilities
• The release cadence was tightened
• The lifecycle evolves
• Operating and supporting MAO
• The team stops sizing

In the case was created a DevOps Center of Excellence (CoE) that helped to put the organizational, process, and tooling infrastructure in place to support a Disciplined DevOps strategy.

13. Closing Thoughts

Why DA? You should consider adopting a Disciplined Agile approach when:

• You want a flexible / pragmatic agile framework rather than a purist agile method
• You’re successfully using Scrum or XP and want to take it to the next level
• You’re not getting the results that you expect using agile
• You’re out of compliance and want to incorporate a lightweight agile governance
• You’re using Scrum and unsure how to address fundamental activities such architecture, testing and analysis
• Your organization has adopted SAFe but run aground because you didn’t have a solid foundation in place for your agile delivery teams
• You need to support several approaches to agile/lean development within your organization
• You need to understand how to effectively blend agile/lean initiatives with your teams that user a traditional approach

 

Access the websites below to read more details about Disciplined Agile Framework:
http://www.disciplinedagiledelivery.com/
https://www.disciplinedagileconsortium.org/