DAD Phase Goals
© Scott Ambler + Associates
The Construction Phase
• Goals:
• Produce a potentially
consumable solution
• Address changing
stakeholder needs
• Move closer to
deployable release
• Improve quality
• Prove architecture early
© Scott Ambler + Associates
DAD Milestones
Milestone
Fundamental Question Asked
Stakeholder consensus
Do stakeholders agree with your strategy?
Proven architecture
Can you actually build this?
Project viability
Does the project still make sense?
Sufficient functionality
Does it make sense to release the current solution?
Production ready
Will the solution work in production?
Delighted stakeholders
Are stakeholders happy with the deployed solution?
© Scott Ambler + Associates
The Construction Phase
© Scott Ambler + Associates
Construction Iteration Lengths
1 week or less
15%
2 weeks
51%
3 weeks
15%
10%
4 weeks
> 4 weeks
Heuristics:
•
•
2%
Average = 2.3 weeks
Shorter is generally better than longer
Teams at scale may require slightly longer iterations
Source: Ambysoft November 2010 Agile State of the Art Survey
© Scott Ambler + Associates
A Construction Iteration
© Scott Ambler + Associates
A Typical Day of Construction
© Scott Ambler + Associates
Risk and Value During Construction
High risk
(“tricky
bits”)
Each release should add value to customers, but it’s also
important to reduce risk during the course of the overall project
For example, it’s strongly recommended to focus early effort on
proving that the architecture can support future releases
High value
(“juicy
bits”)
Release Planning, Revisited
• Feature-driven?
• Add the story points for all desired
features
• Divide by the expected velocity to
get the required number of
iterations
• Date-driven?
• Use the required finish date to
determine the number of
iterations
• Multiply by the expected velocity
to determine the number of story
points in the release
• Count off that many story points
from the product backlog
Sprint (Iteration) Planning
• The sprint is a consistent iteration of time in which the development
team creates a specific group of product capabilities from start to finish
• At the end of each sprint, the product is working and ready to
demonstrate
How Long is the Sprint?
• Considerations:
• Length of the release
• Amount of uncertainty
• Ease of getting feedback
• How long priorities can remain unchanged
• Willingness to go without outside feedback
• Overhead of iterating
Two Examples
Project A (4-week iterations)
• Project B (2-week iterations)
•
• 18-person team working on the first
version of a commercial application to be
sold at $50,000 per user
•
7-person team working on a client-server
desktop app used by 600 employees of the
company (not sold or used outside the
company)
Originally estimated at 13 months, but
pressure for an earlier release, even with
only partial functionality
•
Fair amount of requirements and
technology uncertainty
•
Experienced developers, co-located
•
Access to users partially restricted
• Expected to take one year, but an early
release to selected customers after 6
months
• Significant uncertainty in requirements
• Developers divided into two teams
• External customers, requiring internal
proxies
Sprint Planning
• At the beginning of each sprint, the
scrum team reviews the product
backlog and decides which user stories
to include in the sprint
• These user stories become the sprint
backlog
The Sprint Planning Meeting
• The first day of the sprint
• Recommended: no more than 2 hours for every week of sprint
• All members of the core team must be present (product owner,
development team, scrum master)
Review user
stories from
the product
backlog
Determine
what the
team can
commit to in
the current
sprint
Create the
tasks
associated
with each
user story
Confirm that
all tasks can
be completed
by the team
during this
sprint
Development
team
members
choose their
first tasks
The Sprint Backlog
• The sprint backlog is the list of user stories associated with the current
sprint, AND related tasks:
• The user stories in order of priority (from the product backlog)
• The story points previously estimated by the development team
• The tasks necessary to develop each user story
• A burndown chart showing the status of the work the team has
completed
Burndown Chart and Product Backlog
• A burndown chart can also
show the overall project
progress
• The total number of story
points for the project is
shown at time = 0.
• This number is reduced at
the end of each sprint,
showing how many story
points remain
Burndown Chart (Story Points)
• A burndown chart shows the
amount of work remaining (in
this case, story points) on the
vertical axis, time on the
horizontal axis
• This is an example of a
burndown chart within a single
sprint, showing the change in
the number of story points as
the sprint progresses
Above the dotted line
means the completion
rate is slower than
expected
The dotted line
shows a constant
rate of story points
completed per day
Burndown Chart (Hours)
• Another type of burndown chart
looks at the number of work
hours remaining in a sprint
• The dotted line represents a fixed
number of work hours per day
during the sprint for the entire
team
• The data points show the actual
number of hours worked each day
Team Availability
• How many hours per day during the sprint can each team member
dedicate to the project?
• This does not include meetings or helping other team members
complete tasks
• A typical number is 5-6 hours per day, but is often less than that
Person
M
T
W
Th
F
M
T
W
Th
F
Ann
5
4
5
5
3
5
3
6
3
4
Ben
6
6
5
5
6
3
5
5
5
5
Carlos
3
3
6
6
6
6
4
4
6
6
Release Burndown Bar Chart
When work is completed, the top is lowered
When work is re-estimated, the top moves up or down
When new work is added, the bottom is lowered
When work is removed, the bottom is raised
Points
Iterations
Burndown Chart and Velocity
• Velocity is the number of story points completed per iteration
If the team’s velocity remains the same, you can determine how many
iterations will be required to complete all of the planned story points
Estimating Velocity
tom-sylvester.com
Iterations Completed Low Multiplier
High Multiplier
1
0.6
1.60
2
0.8
1.25
3
0.85
1.15
4 or more
0.90
1.10
Note: Actual Velocity Varies
The actual velocity of team is likely to vary from one
iteration to the next.
Why would the number of story points increase?
Planned finish at Iteration 8, now expected at Iteration 11
Sprint Planning Workflow
Determine
team
availability
Select user
story or
work item
Decompos
e into tasks
YES
Update
sprint
backlog
Anothe
r item?
NO
Sign up for
tasks
Select a Work Item
•
•
•
•
•
Which items should be considered for this sprint?
User stories, defects, nonfunctional requirements, etc.
Factors include:
Business value (from the product owner): “juicy bits”
Risk: implement technically risky work in early iterations to reduce overall
project uncertainty: “tricky bits”
• Due date: commitments to stakeholders
• Operational emergency
• Logical or technical dependencies
Juicy Bits vs. Tricky Bits
Technical
Risk
High Risk
Low Value
(Avoid)
High Risk
High Value
(Do First)
Low Risk
Low Value
(Do Last)
Low Risk
High Value
(Do Second)
Customer Value
Prioritizing Example
• Infrastructure, such as a security framework
• Probably low customer value, at least in the beginning
• Cost may be low in the beginning, but it might need to be
edited later in the project
• Does this add new product or project knowledge?
• Does this reduce or eliminate risk to the project’s success?
Splitting User Stories
• When? Too large to fit into a single iteration, or not enough room left
within the current iteration
• How?
• Splitting across data boundaries (the type of data used by the
story)
• Splitting on operational boundaries (such as the CRUD
operations: Create, Read, Update, Delete)
• Splitting on functional vs. non-functional requirements
Other Guidelines
• When features “cut across” multiple areas in an application (for
example: security, error handling), create two versions of the story,
one with and one without support for the cross-cutting concern
• Separate a large story into smaller stories if the smaller stories have
different priorities
Work Item Definition of Done (DoD)
• How will you determine whether the work item is done?
• Typically acceptance test results, or “up and running in a production
environment”
• The product owner must agree on the DoD
• Details are not necessary during the sprint planning meeting
User Stories to Tasks
• Tasks are the execution steps necessary to develop a requirement or
complete a work item
• Implementation of a user story may require multiple tasks.
• Tasks include development, integration, testing, and documentation
activities. Remember that you must finish the sprint with fully
functional user stories
• Tasks are typically no more than 1 day in length (why?)
Example: Mobile Banking App
User story:
log in and
access
account
Example tasks could include:
• Create an authentication screen for user name and
password, with a Submit button
• Create an error screen for the user to re-enter
credentials
• Create a logged-in screen (including a list of
accounts – to be completed in the next user story)
• Create calls to the dbase to verify user name and
password
• Refactor code for mobile devices
Sign Up for Tasks
• Remember the self-organizing and self-managing principles of agile:
team members volunteer for tasks, they are not assigned
• Recommended: agile team members should “pull” work into their
queue only when they have the capacity to do so. One task at a time.
Sanity Check
• Is the team over-committed for this sprint?
• Check estimated hours against total hours available
• Options:
• Postpone some work
Not an option:
Delay integration
• Drop work
Delay testing
• Work differently
Delay documentation
• Get help
You must be able to demonstrate working
software at the end of the sprint
Look-Ahead Planning
• Be careful not to get ahead of yourself
• The focus must be on the current sprint backlog
• Can save time for the planning meeting before the next sprint
• The product owner should continuously “groom” the product backlog:
evaluating new items and adjusting priorities
Working the Sprint
• The daily scrum
• Tracking progress
• Common roadblocks and solutions
Daily Scrum
• First activity of the day
• All members of the scrum team are expected to
attend
• Stand-up meeting, typically 15-20 minutes
• Anyone else may attend, but only the
development team, the scrum master, and the
product owner may talk
• The focus is on immediate priorities;
coordination, not problem solving
Daily Scrum: The Three Questions
• What did you do yesterday?
• This tests the team’s focus. Question anything that was not work
planned for this iteration
• What are your plans for today?
• Allows the team to revise the team’s priorities and plans
• What are your blockers or impediments?
• This may lead to additional tasks or work items
Guidelines for Daily Scrum
• Take issue offline: keep a list on the
whiteboard for further discussion after
the meeting
• Start on time
• Everyone must be present
• Attendees stand up, this is a short
meeting
• Coordinate the day, don’t just share
status
• Use the visual task board
The Daily Scrum is Not:
• The scrum meeting is for peer-to-peer coordination
• It is not:
• A blame session for slipping schedule
• A problem-solving or issue-resolution meeting (work outside the
scrum)
• A detailed status report
• A forum for non-team member to voice their opinions (they can
observe, but not participate)
General Considerations
• Explore and model the solution before writing code
• Use processes that prevent defects instead of relying on processes to
find defects
• Share and demonstrate the solution often
• Welcome changes
Welcome Changes
• Traditional project management tends to discourage
changes by establishing a strict change management
process
• This leads to:
•
Additional and unnecessary requirements at the start
•
Inflexible response to legitimate changes based on
feedback
• Agile project management allows and welcomes changes
that add value and help ensure customer acceptance
• The product owner is responsible for reviewing these
opportunities
Ongoing Activities During the Sprint
• Create deliverable documentation (“just barely good enough”)
• Part of the acceptance criteria for a work item
• Non-solo development (pair programming and other practices)
• Update task progress
• Help lead the team (shared responsibility)
• Maintain a sustainable pace
• Gather and report metrics
• Follow organizational standards
Important Popular Practices
• Test driven development: write the tests first
• Continuous integration: build the solution, run regression tests
immediately
• Continuous deployment: deploy the solution to a production
environment (demo sandbox) for evaluation and feedback
• Parallel independent testing: may be useful for complex domains and
large/distributed teams
Best Practices During the Sprint
Understand the
work item
Explore the solution Build the solution
Prevent problems
Create acceptance
tests
Model the
requirement ahead
Model solutions
Design unit tests
Validate solution vs. Code unit tests
architecture spike
Test-driven
development
Deliver work
Model the
requirement
Model the solution
UX design
Find problems
Improve quality
Continuous
documentation
Non-solo
development
Continuous
documentation
Non-solo
development
Validate the
integrated solution
Share the solution
Write production
code
Create build
Deploy to
integration
environment
Continuous
integration
Continuous
deployment
Regression of unit
tests
Code reviews and
inspections
Full regression of
Deployment testing
unit tests
Acceptance tests
Parallel independent
testing
Continuous
documentation
Refactor
Non-solo
development
Tracking Progress
• Self-organized teams decide on their own tracking mechanisms
• Use sticky notes and whiteboard, fancy slides are not necessary
• Typical artifacts include:
• Sprint backlog (list of tasks)
• Status of tasks: to-do, in-progress, review (by product owner), done
• Sprint story points burndown chart
• Sprint hours burndown chart
Visualizing the Plan: The Task Board
The Task Board
Summary of Roles During the Sprint
•
•
•
•
•
•
•
•
•
Development Team
Select the highest priority tasks and
complete them as quickly as possible
Request clarification from the product
owner if unclear
Collaborate with other development
team members: seek help when you
need it, provide help when they need
it
Conduct peer reviews
Volunteer for tasks outside your
normal role
Fully develop functionality to create
shippable features
Report daily on progress
Alert the scrum master to any
roadblocks
Achieve the goals committed during
•
•
•
•
•
•
•
•
Product Owner
Prioritize product functionality
Represent the product
stakeholders
Report on cost and schedule to
the stakeholders
Elaborate user stories with the
development team, clarify where
necessary
Review completed work and
provide feedback to the
development team
Add user stories to the product
backlog as necessary
Ensure that new user stories are
consistent with strategy and goals
Look forward to the next sprint
and elaborate user stories to
•
•
•
•
•
Scrum Master
Uphold agile values and
practices by coaching
wherever necessary
Shield the development
team from external
distractions
Remove roadblocks,
both short- and longterm
Facilitate consensus
building within the
scrum team
Build relationships with
external partners
(“Never lunch alone”)
Verifying Work
• Testing, ideally automated testing
• Peer review
• Product owner review (per the DoD acceptance criteria)
Common Sprint Roadblocks
Roadblock
Action
Management wants to borrow a development team member to write a report. All
members of the team are fully occupied
Tell the requestor that the person is not available, and probably won’t be for the
duration of the project. Suggest alternatives.
A development team member cannot move forward on a user story without the
product owner, who is out of the office on a personal emergency
Can any work be done around the user story? Locate another person who can answer
the question. Review upcoming tasks to keep productivity up.
A user story has grown in complexity and now appears to be too long to be finished in
this sprint
Work with the product owner to break the user story down so some value can be
delivered in this sprint. Smaller is better than incomplete.
The End of the Day
• Stabilize the work for check-in and automated testing
• Update the sprint backlog showing task status and estimated hours
remaining on tasks in-progress
• Update sprint burndown charts
Concluding the Iteration
• Iteration hardening (preparing for demonstration and potential
deployment)
• Sprint Review
• Sprint Retrospective
• Assess progress and adjust the plan
• Assess remaining risks
• Determine the strategy going forward
The Sprint Review Meeting
• The sprint review is a meeting at the end of
the sprint to demonstrate the user stories that
the development team completed
• This requires working software: fully tested and
integrated
• All stakeholders are welcome to see the
progress and provide feedback. They will
probably propose new requirements, and
that’s a good thing.
• Note that the product owner is expected to
provide input throughout the sprint (not just at
the end)
The Sprint Review Meeting
• Guidelines:
• No PowerPoint slides
• Refer to the sprint backlog and other existing visual tracking if
necessary
• The entire scrum team should be present
• Demonstrate what has been completed, not what’s planned
• Use the actual production environment as much as possible
• The product owner can describe upcoming work
• Gather feedback and add to the product backlog
The Sprint Retrospective
• The sprint retrospective is a meeting where the scrum team discuss how
the sprint went and what they can do to improve the next sprint.
• The sprint isn’t over until the retrospective is complete
• The goal is continuous improvement to increase velocity (work output) and
effectiveness
The Sprint Retrospective
Questions
• What went well during the sprint?
• What would we like to change?
• How can we implement that change?
Discussion Areas
• Results: work completed vs. work planned
• People and relationships
Suggestions from Retrospective
• Examples of useful suggestions from the retrospective:
• How can we increase velocity?
• What can we do to sustain this velocity?
• Are there unnecessary meetings or other distractions that limit our
available hours?
• Are there administrative or other external barriers?
• Did we improve by acting on the recommendations from the last
retrospective?
Assess Progress
• Did the team complete everything they planned?
• What was the velocity?
• How does the rest of the project look?
Updating the Schedule
As the project progresses, the remaining number of iterations can
be more accurately estimated
Determine the Strategy Going Forward
• Continue in the current direction (next iteration)
• Pivot in a new direction
• Cancel the project
The Phases Shrink Over Time
First release:
Inception
Second release:
Third release:
.
.
.
Nth+ releases:
Construction
I
Construction
I
Construction
C
C
C
C
© Scott Ambler + Associates
Transition
T
T
Are You Ready to Deploy?
• At what point are you ready to move to the Transition phase?
• When the product owner believes that the solution is ready to deploy,
the “Sufficient Functionality” checkpoint meeting can be scheduled:
• Solution is ready
• Stakeholders are ready to receive it
Construction Phase Patterns
• The team reliably demonstrates software at the end of
each iteration
• Team members finish tasks ahead of schedule and ask to
help others
• Iteration dates never move
• Any stakeholder can see a demo of working software at
any time
Construction Phase Anti-Patterns
•
•
•
•
•
•
•
•
•
Work item list is too big to manage
Inattention to risk mitigation
Assuming the architecture will work without proving it with code
One or more team members are working on other projects
A work item isn’t done
Some tasks were missed during planning
A requirement was missed that another depends on
The product owner fails to “groom” the product backlog
Defect counts are increasing in each iteration
CIS675 – Agile Project Management
Agile Project Plan (100 points)
Develop a preliminary agile plan for a real or hypothetical software project of your choosing. This
must include:
1. Overview of the project. See Figure 12.2 on page 256 of Ambler & Lines for an example.
a. What exactly are you planning to achieve?
b. Why is this project important and necessary?
c. What business problem is this project intended to address?
2. Product overview and vision statement, See Figure 12.5 on page 260 of Ambler & Lines
for an example.
a. Include at least 18 (eighteen) requirements or features written in the form of user
stories
b. Provide sufficient detail for non-technical stakeholders to understand how these
features support the business goal
c. Use diagrams and drawings to illustrate the proposed solution. See Figure 12.6 on
page 263 and Figure 12.8 on page 266 of Ambler & Lines for examples.
3. Prioritized user stories. Rank order the user stories previously identified in item #2 above
based on your analysis of the business need. See Table 17.2 on page 390 of Ambler &
Lines for an example. Note: you do not need to include the “Relative Estimate”
column.
4. Acceptance test criteria. For the top six (6) priority user stories, propose acceptance test
criteria. See Table 17.3 on page 391 of Ambler & Lines for an example.
5. Release plan. Use the prioritized user stories to develop a release plan, explaining which
features or user stories will be included in each release.
a. If you choose to do only one release, explain why you are not recommending multiple
releases
b. If you choose to do more than one release, explain the benefit to the business to release
some features and user stories before all of them are complete
c. The release plan should include the date for each release, and the number of iterations
(sprints) planned before each release
6. Risk analysis. Identify at least eight (8) technical risks for the project, and estimate the
probability and impact of each. See Table 12.6 on page 268 of Ambler and Lines for an
example.
This assignment should fully explain your project concept, constraints, and expectations.
Your assignment must be 8 pages long, including figures, tables, or other exhibits.
All written assignments in this course should follow standard APA style, with 12-point font and
one-inch margins. Figures, tables and other exhibits should be clearly labeled and referenced.
Assignments should also conform to standard spelling, grammar, and punctuation.
Related Books of Interest
A Practical Guide to
Distributed Scrum
Agile Career Development
By Elizabeth Woodward, Steffan Surdek, and
Matthew Ganis
By Mary Ann Bopp, Diana A. Bing,
Sheila Forte-Trammell
ISBN-13: 978-0-13-704113-8
ISBN-13: 978-0-13-715364-0
This is the first comprehensive, practical guide
for Scrum practitioners working in large-scale
distributed environments. Written by three of
IBM’s leading Scrum practitioners—in close
collaboration with the IBM QSE Scrum Community
of more than 1,000 members worldwide—this
book offers specific, actionable guidance for
everyone who wants to succeed with Scrum in
the enterprise.
Supercharge Performance by Linking
Employee-Driven Career Development with
Business Goals
Readers will follow a journey through the lifecycle
of a distributed Scrum project, from envisioning
products and setting up teams to preparing for
Sprint planning and running retrospectives. Using
real-world examples, the book demonstrates how
to apply key Scrum practices, such as look-ahead
planning in geographically distributed environments. Readers will also gain valuable new
insights into the agile management of complex
problem and technical domains.
Lessons and Approaches from IBM
How do you make career development work for
both the employee and the business? IBM® has
done it by tightly linking employee-driven career
development programs with corporate goals. In
Agile Career Development, three of IBM’s leading
HR innovators show how IBM has accomplished
this by illustrating various lessons and approaches that can be applied to other organizations as
well. This book is for every HR professional, learning or training manager, executive, strategist, and
any other business leader who wants to create a
high-performing organization.
Sign up for the monthly IBM Press newsletter at
ibmpressbooks.com/newsletters
Related Books of Interest
Implementing the IBM®
Rational Unified Process®
and Solutions
Work Item Management with
IBM Rational ClearQuest and
Jazz
By Joshua Barnes
A Customization Guide
ISBN-13: 978-0-321-36945-1
By Shmuel Bashan and David Bellagio
This book delivers all the knowledge and insight
you need to succeed with the IBM Rational
Unified Process and Solutions. Joshua Barnes
presents a start-to-finish, best-practice roadmap
to the complete implementation cycle of IBM
RUP—from projecting ROI and making the
business case through piloting, implementation, mentoring, and beyond. Drawing on his
extensive experience leading large-scale IBM
RUP implementations and working with some of
the industry’s most recognized thought leaders in
the Software Engineering Process world, Barnes
brings together comprehensive “lessons learned”
from both successful and failed projects. You’ll
learn from real-world case studies, including
actual project artifacts.
ISBN-13: 978-0-13-700179-8
The Complete Guide to Managing Work
Items and Workflow with IBM® Rational®
ClearQuest® and IBM Rational Team Concert™
Work items are the lifeblood of software and
hardware development. They tell development
teams exactly who is doing what, which issues
are resolved, which remain unresolved, and which
products are impacted. In large, team-based
projects, however, managing work items can be
difficult. Now, two IBM Rational experts show
how to simplify and improve every aspect of work
item management with IBM Rational ClearQuest
and the powerful and collaborative Jazz™-based
products: IBM Rational Team Concert (RTC) and
IBM Rational Quality Manager.
Visit ibmpressbooks.com
for all product information
Related Books of Interest
Enterprise Master Data
Management
An SOA Approach to
Managing Core Information
Dreibelbis, Hechler, Milman,
Oberhofer, van Run, Wolfson
ISBN-13: 978-0-13-236625-0
The Business of IT
Software Test
Engineering with IBM
Rational Functional Tester
The Definitive Resource
By Chip Davis, Daniel Chirillo, Daniel Gouveia,
Fariz Saracevic, Jeffrey B. Bocarsley, Larry
Quesada, Lee B. Thomas, and Marc van Lint
ISBN-13: 978-0-13-700066-1
If you’re among the thousands of developers
using IBM Rational Functional Tester (RFT), this
book brings together all the insight, examples,
and real-world solutions you need to succeed.
Eight leading IBM testing experts thoroughly
introduce this state-of-the-art product, covering
issues ranging from building test environments
through executing the most complex and powerful tests. Drawing on decades of experience with
IBM Rational testing products, they address both
technical and nontechnical challenges and present everything from best practices to reusable
code.
How to Improve Service and
Lower Costs
Robert Ryan, Tim Raducha-Grace
ISBN-13: 978-0-13-700061-6
An Introduction to IMS
Your Complete Guide to IBM
Information Management Systems,
2nd Edition
Barbara Klein, et al.
ISBN-13: 978-0-13-288687-1
Dynamic SOA and BPM
Best Practices for Business Process
Management and SOA Agility
Marc Fiammante
ISBN-13: 978-0-13-701891-8
Outside-in Software
Development
A Practical Approach to Building
Successful Stakeholder-based
Products
Carl Kessler, John Sweitzer
ISBN-13: 978-0-13-157551-6
Sign up for the monthly IBM Press newsletter at
ibmpressbooks.com/newsletters
Praise for Disciplined Agile Delivery
“Finally, a practical down-to-earth guide that is true to agile values and principles while at the
same time acknowledging the realities of the business and the bigger picture. You will find no
purist dogma here, nor any hype or hyperbole. Ambler and Lines show how to navigate the varied
contexts and constraints of both team-level and enterprise-level needs to hit the agile ‘sweet
spot’ for your team and attain the real benefits of sustainable agility. I wish I’d had this book ten
years ago!”
—Brad Appleton, agile/lean development champion for a large fortune
150 telecommunications company
“We have found the guidance from Disciplined Agile Delivery to be a great help in customizing
our PMO governance for agile projects at CP Rail. The book will definitely be on the must-read
list for teams using agile delivery.”
—Larry Shumlich, project manager coach, Canadian Pacific Railway
“This book is destined to become the de facto standard reference guide for any organization trying to apply agile/scrum in a complex environment. Scott and Mark provide practical guidance
and experiences from successful agile teams on what it takes to bring an end-to-end agile delivery
lifecycle to the enterprise.”
—Elizabeth Woodward, IBM agile community leader, coauthor of
A Practical Guide to Distributed Scrum
“There are many ways to achieve the benefits of agility, so it’s really encouraging to see a pragmatic and usable ‘umbrella’ description that encapsulates most of these without becoming a
diluted kind of ‘best of’ compilation, or a one-size-fits-all. Great reading for anyone orientating
themselves in an ever-growing and complex field.”
—Nick Clare, agile coach/principal consultant, Ivar Jacobson International
“Scott and Mark have compiled an objective treatment of a tough topic. Loaded with insights
from successful application under game conditions, this book strikes a good balance between
progressive agilists looking to accelerate change and conservative organizational managers looking for scalable solutions.”
—Walker Royce, chief software economist, IBM
“Disciplined Agile Delivery, a hybrid and experience-based approach to software delivery,
reflects the growing trend toward pragmatism and away from the anti-syncretism that has plagued
the software development industry for over 40 years. I commend Scott and Mark for writing this
book and showing the leadership necessary to take our profession to the next level.”
—Mark Kennaley, CTO, Software-Development-Experts.com;
author of SDLC 3.0: Beyond a Tacit Understanding of Agile
“I’ve seen ‘certified agile’ run rampant in an organization and create more severe problems than it
solved. Finally, we have a definitive source on how to apply agile pragmatically with discipline to
deliver success. Thanks, Scott and Mark.”
—Carson Holmes, EVP, service delivery, Fourth Medium Consulting, Inc.
Disciplined Agile
Delivery
This page intentionally left blank
IBM WebSphere
Disciplined Agile
Delivery
[SUBTITLE ]
Deployment and Advanced
A Practitioner’s Guide to Agile
Configuration
Software Delivery in the Enterprise
Roland Barcia, Bill Hines, Tom Alcott, and Keys Botzum
Scott Ambler and Mark Lines
IBM Press
Pearson plc
Upper Saddle River, NJ • Boston • Indianapolis • San Francisco
New York • Toronto • Montreal • London • Munich • Paris • Madrid
Cape Town • Sydney • Tokyo • Singapore • Mexico City
Ibmpressbooks.com
The authors and publisher have taken care in the preparation of this book, but make no expressed or
implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed
for incidental or consequential damages in connection with or arising out of the use of the information or
programs contained herein.
© Copyright 2012 by International Business Machines Corporation. All rights reserved.
Note to U.S. Government Users: Documentation related to restricted right. Use, duplication, or disclosure
is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.
IBM Press Program Managers: Steven Stansel, Ellice Uffer
Cover design: IBM Corporation
Publisher: Paul Boger
Marketing Manager: Stephane Nakib
Publicist: Heather Fox
Acquisitions Editor: Bernard Goodwin
Managing Editor: Kristy Hart
Designer: Alan Clements
Project Editor: Betsy Harris
Copy Editor: Geneil Breeze
Indexer: Erika Millen
Compositor: Nonie Ratcliff
Proofreader: Debbie Williams
Manufacturing Buyer: Dan Uhrig
Published by Pearson plc
Publishing as IBM Press
IBM Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special
sales, which may include electronic versions and/or custom covers and content particular to your business,
training goals, marketing focus, and branding interests. For more information, please contact:
U. S. Corporate and Government Sales
1-800-382-3419
corpsales@pearsontechgroup.com
For sales outside the U. S., please contact:
International Sales
international@pearsoned.com
The following terms are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both: IBM, the IBM Press logo, Rational,
developerWorks, Rational Team Concert, Jazz, Rhapsody, Build Forge, Global Business Services,
WebSphere, Sametime, and Lotus. A current list of IBM trademarks is available on the web at “copyright
and trademark information” as www.ibm.com/legal/copytrade.shtml.
IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications
Agency which is now part of the Office of Government Commerce.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
Library of Congress Cataloging-in-Publication data is on file.
All rights reserved. This publication is protected by copyright, and permission must be obtained from the
publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or
by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding
permissions, write to:
Pearson Education, Inc.
Rights and Contracts Department
501 Boylston Street, Suite 900
Boston, MA 02116
Fax (617) 671-3447
ISBN-13: 978-0-13-281013-5
ISBN-10: 0-13-281013-1
Text printed in the United States on recycled paper at R.R. Donnelley in Crawfordsville, Indiana.
First printing June 2012
For Olivia, who will always be my little pumpkin. —Scott
To my beautiful family, Louise, Brian, and Katherine,
for your love and support. I am truly blessed… —Mark
Contents
Part 1: Introduction to Disciplined Agile Delivery (DAD)
Chapter 1
Disciplined Agile Delivery in a Nutshell . . . . . . . . . . . . . . . . . . . 1
Context Counts—The Agile Scaling Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What Is the Disciplined Agile Delivery (DAD) Process Framework? . . . . . . . . . . . . . . . . . . . . . . . . 5
People First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Learning Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A Hybrid Process Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IT Solutions over Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Goal-Driven Delivery Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Enterprise Aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Risk and Value Driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Scalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2
Introduction to Agile and Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Toward a Disciplined Agile Manifesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Disciplined Agile Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Disciplined Agile Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Lean Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Reality over Rhetoric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 3
Foundations of Disciplined Agile Delivery . . . . . . . . . . . . . . 41
The Terminology Tar Pit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Agile Modeling (AM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Agile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
xi
xii
Contents
Lean Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
IBM Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Open Unified Process (OpenUP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
And Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Those Who Ignore Agile Practices Put Their Business at Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Part 2: People First
Chapter 4
Roles, Rights, and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . 61
The Rights of Everyone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
The Responsibilities of Everyone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
The DAD Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 5
Forming Disciplined Agile Delivery Teams . . . . . . . . . . . . . 83
Strategies for Effective Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
The Whole Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Team Organization Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Building Your Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Interacting with Other Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Part 3: Initiating a Disciplined Agile Delivery Project
Chapter 6
The Inception Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
How the Inception Phase Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Aligning with the Rest of the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Securing Funding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Other Inception Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
When Do You Need an Inception Phase? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Inception Phase Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Inception Phase Anti-Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Chapter 7
Identifying a Project Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
What’s in a Vision? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
How Do You Create a Vision? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Capturing Your Project Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Contents
xiii
Bringing Stakeholders to Agreement Around the Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapter 8
Identifying the Initial Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Choosing the Appropriate Level of Initial Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Choosing the Right Types of Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Choosing a Modeling Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Choosing a Work Item Management Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Choosing a Strategy for Nonfunctional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chapter 9
Identifying an Initial Technical Strategy . . . . . . . . . . . . . . . 175
Choosing the Right Level of Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Choosing the Right Types of Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Choosing a Modeling Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Architecture Throughout the Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Chapter 10 Initial Release Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Who Does the Planning? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Choosing the Right Scope for the Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Choosing a General Planning Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Choosing Cadences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Formulating an Initial Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Estimating the Cost and Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Identifying Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Chapter 11 Forming the Work Environment . . . . . . . . . . . . . . . . . . . . . . . . 229
Forming the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Choosing Your Toolset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Organizing Physical Work Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Organizing Virtual Work Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Visual Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Adopting Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Chapter 12 Case Study: Inception Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Introducing the AgileGrocers POS Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Developing a Shared Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
xiv
Contents
Requirements Envisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Creating the Ranked Work Item List of User Stories to Implement the Solution . . . . . . . . . . . . . 264
Architecture Envisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Release Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Other Inception Phase Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Alternative Approach to Running Your Inception Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Concluding the Inception Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Part 4: Building a Consumable Solution Incrementally
Chapter 13 The Construction Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
How the Construction Phase Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
The Typical Rhythm of Construction Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
The Risk-Value Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
When Are You Ready to Deploy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Construction Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Construction Anti-Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Chapter 14 Initiating a Construction Iteration . . . . . . . . . . . . . . . . . . . . . . 289
Why Agile Planning Is Different . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Iteration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Visualizing Your Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Look-Ahead Planning and Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Chapter 15 A Typical Day of Construction . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Planning Your Team’s Work for the Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Collaboratively Building a Consumable Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Ongoing Activities Throughout the Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
A Closer Look at Critical Agile Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Stabilizing the Day’s Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Chapter 16 Concluding a Construction Iteration . . . . . . . . . . . . . . . . . . . 363
Demonstrate the Solution to Key Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Learn from Your Experiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Assess Progress and Adjust Release Plan if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Assess Remaining Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Deploy Your Current Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Contents
xv
Determine Strategy for Moving Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Chapter 17 Case Study: Construction Phase . . . . . . . . . . . . . . . . . . . . . . . . 383
Continuing Our Scenario with the AgileGrocers POS Case Study . . . . . . . . . . . . . . . . . . . . . . . . 383
Planning the Iteration’s Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Subsequent Construction Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Other Construction Phase Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Concluding the Construction Phase Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Part 5: Releasing the Solution
Chapter 18 The Transition Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
How the Transition Phase Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Planning the Transition Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Ensuring Your Production Readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Preparing Your Stakeholders for the Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Deploying the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Are Your Stakeholders Delighted? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Transition Phase Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Transition Phase Anti-Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Chapter 19 Case Study: Transition Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Planning the Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Collaborating to Deploy the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
AgileGrocers’ Delight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Part 6: Disciplined Agile Delivery in the Enterprise
Chapter 20 Governing Disciplined Agile Teams . . . . . . . . . . . . . . . . . . . . . 441
What Should Governance Address? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Why Is Governance Important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Why Traditional Governance Strategies Won’t Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Agile Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Agile Practices That Enable Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Fitting in with the Rest of Your IT Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Measuring Agile Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
xvi
Contents
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Chapter 21 Got Discipline? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Agile Practices Require Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Reducing the Feedback Cycle Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Continuous Learning Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Incremental Delivery of Consumable Solutions Requires Discipline . . . . . . . . . . . . . . . . . . . . . . 490
Being Goal-Driven Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Enterprise Awareness Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Adopting a Full Lifecycle Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Streamlining Inception Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Streamlining Transition Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Adopting Agile Governance Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Moving to Lean Requires Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Index
497
Foreword
The process wars are over, and agile has won. While working at Forrester, we observed that agile
methods had gone mainstream, with the majority of organizations saying that they were using
agile on at least 38% of their projects. But the reality of agile usage, as Scott and Mark point out,
is far from the original ideas described by the 17 thought leaders in 2001. Instead, agile is undermined by organizational inertia, politics, people’s skills, management practices, vendors, and
outsourced development. I observed that the reality of agile was something more akin to waterscrum-fall—water-scrum describing the inability of an organization to start any project without a
lengthy phase up front that defined all the requirements, planning the project in detail, and even
doing some of the design. Scrum-fall defines the release practices operated by most organizations
in which software is released infrequently, with costly and complex release practices that include
manual deployments and testing. Water-scrum-fall is not all bad, with some benefits to the development team working in an iterative, scrum-based way, but water-scrum-fall does not release the
power of agile. Enterprise agile not only creates the most efficient software development process
but more importantly delivers software of greater business value. It is my assertion that scaled,
enterprise-level agile is therefore not just important for your software-delivery organization but
crucial for business success. Fixing water-scrum-fall will increase business value and enable
organizations to compete. And this book provides a framework to make that happen.
In this book, Scott and Mark, two very experienced software-delivery change agents,
describe a detailed framework for how to scale agile to the enterprise. They show how change
leaders can amplify agile, making it not just about teams but about the whole value stream of software delivery. In many books about agile adoption, the really tricky problems associated with
governance and organizational control are often side-stepped, focusing on why it is stupid to do
something rather than how to change that something. Scott and Mark have not done this. They
have focused clearly on the gnarly problems of scale, describing practical ways of fixing governance models, staffing issues, and management approaches. Their use of lean positions their
xvii
xviii
Foreword
framework in a broader context, allowing change leaders to not only improve their delivery capability but also connect it directly to business value. But be warned: These problems are not easily
solved, and adopting these ideas does not just require agile skills but also draws on other process
models, change techniques, and good engineering practices.
Scott and Mark not only made me think, but they also reminded me of lots of things that I
had forgotten—things that the agile fashion police have made uncool to talk about. This book is
not about fashionable agile; it is about serious change, and it should be required reading for any
change leader.
Dave West @davidjwest
Chief Product Officer, Tasktop, and former VP and Research Director, Forrester Research
Preface
The information technology (IT) industry has an embarrassing reputation from the perspective of
our customers. For decades we have squandered scarce budgets and resources, reneged on our
promises, and delivered functionality that is not actually needed by the client. An outsider looking at our profession must be truly baffled. We have so many process frameworks and various
bodies of knowledge such that we ourselves have difficulty keeping up with just the acronyms, let
alone the wealth of material behind them. Consider: PMBOK, SWEBOK, BABOK, ITIL®,
COBIT, RUP, CMMI, TOGAF, DODAF, EUP, UML, and BPMN, to name a few. Even within the
narrow confines of the agile community, we have Scrum, XP, CI, CD, FDD, AMDD, TDD, and
BDD, and many others. There is considerable overlap between these strategies but also considerable differences. We really need to get our act together.
Why Agile?
On traditional/classical projects, and sadly even on “heavy RUP” projects, basic business and
system requirements often end up written in multiple documents in different fashions to suit the
standards of the various standards bodies. Although in some regulatory environments this proves
to be good practice, in many situations it proves to be a huge waste of time and effort that often
provides little ultimate value—you must tailor your approach to meet the needs of your situation.
Fortunately, agile methods have surfaced over the past decade so that we can save ourselves
from this madness. The beauty of agile methods is that they focus us on delivering working software of high business value to our customers early and often. We are free to adjust the project
objectives at any time as the business needs change. We are encouraged to minimize documentation, to minimize if not eliminate the bureaucracy in general. Who doesn’t like that?
xix
xx
Preface
More importantly, agile strategies seem to be working in practice. Scott has run surveys1
within the IT industry for several years now, and he has consistently found that the agile and
iterative strategies to software development have consistently outperformed both traditional and
ad-hoc strategies. There’s still room for improvement, and this book makes many suggestions for
such improvements, but it seems clear that agile is a step in the right direction. For example, the
2011 IT Project Success Survey revealed that respondents felt that 67% of agile projects were
considered successful (they met all of their success criteria), 27% were considered challenged
(they delivered but didn’t meet all success criteria), and only 6% were considered failures. The
same survey showed that 50% of traditional projects were considered successful, 36% challenged, and 14% failures. The 2008 IT Project Success survey found that agile project teams were
much more adept at delivering quality solutions, good return on investment (ROI), and solutions
that stakeholders wanted to work with and did so faster than traditional teams. Granted, these are
averages and your success at agile may vary, but they are compelling results. We’re sharing these
numbers with you now to motivate you to take agile seriously but, more importantly, to illustrate
a common theme throughout this book: We do our best to shy away from the overly zealous “religious” discussions found in many software process books and instead strive to have fact-based
discussions backed up by both experiential and research-based evidence. There are still some
holes in the evidence because research is ongoing, but we’re far past the “my process can beat up
your process” arguments we see elsewhere.
Alistair Cockburn, one of the original drafters of the Agile Manifesto, has argued that there
are three primary aspects of agile methodologies:
• Self-discipline, with Extreme Programming (XP) being the exemplar methodology
• Self-organization, with Scrum being the exemplar methodology
• Self-awareness, with Crystal being the exemplar methodology
As you’ll see in this book, Disciplined Agile Delivery (DAD) addresses Cockburn’s three
aspects.
Why Disciplined Agile Delivery?
Although agile strategies appear to work better than traditional strategies, it has become clear to
us that the pendulum has swung too far the other way. We have gone from overly bureaucratic and
document-centric processes to almost nothing but code. To be fair, agile teams do invest in planning, although they are unlikely to create detailed plans; they do invest in modeling, although are
unlikely to create detailed models; they do create deliverable documentation (such as operations
manuals and system overview documents), although are unlikely to create detailed specifications.
However, agile teams have barely improved upon the results of iterative approaches. The 2011 IT
1. The original questions, source data (without identifying information due to privacy concerns), and summary slide
decks for all surveys can be downloaded free of charge from www.ambysoft.com/surveys/.
Preface
xxi
Project Success survey found that 69% of iterative projects were considered successful, 25%
challenged, and 6% failures, statistically identical results as agile projects. Similarly, the 2008 IT
Project Success survey found that agile and iterative teams were doing statistically the same
when it came to quality, ability to deliver desired functionality, and timeliness of delivery and that
agile was only slightly better than iterative when it came to ROI. The reality of agile hasn’t lived
up to the rhetoric, at least when we compare agile strategies with iterative strategies. The good
news is that it is possible to do better.
Our experience is that “core” agile methods such as Scrum work wonderfully for small
project teams addressing straightforward problems in which there is little risk or consequence of
failure. However, “out of the box,” these methods do not give adequate consideration to the risks
associated with delivering solutions on larger enterprise projects, and as a result we’re seeing
organizations investing a lot of effort creating hybrid methodologies combining techniques from
many sources. The Disciplined Agile Delivery (DAD) process framework, as described in this
book, is a hybrid approach which extends Scrum with proven strategies from Agile Modeling
(AM), Extreme Programming (XP), and Unified Process (UP), amongst other methods. DAD
extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle2 from project initiation all the way to delivering the solution to its end users. The DAD
process framework includes advice about the technical practices purposely missing from Scrum
as well as the modeling, documentation, and governance strategies missing from both Scrum and
XP. More importantly, in many cases DAD provides 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.
Indeed there are an increasing number of high-profile project failures associated with agile
strategies that are coming to light. If we don’t start supplementing core agile practices with a
more disciplined approach to agile projects at scale, we risk losing the hard-earned momentum
that the agile pioneers have generated.
This book does not attempt to rehash existing agile ideas that are described in many other
books, examples of which can be found in the references sections. Rather, this book is intended to
be a practical guide to getting started today with agile practices that are structured within a disciplined approach consistent with the needs of enterprise-scale, mission-critical projects.
What Is the History?
The Disciplined Agile Delivery (DAD) process framework began as a concept in 2007 that Scott
worked on in his role as chief methodologist for agile and lean at IBM® Rational®. He was working with customers around the world to understand and apply agile techniques at scale, and he
2. A full system/product lifecycle goes from the initial idea for the product, through delivery, to operations and support
and often has many iterations of the delivery lifecycle. Our focus in DAD is on delivery, although we discuss how the
other aspects of the system lifecycle affect the delivery lifecycle.
xxii
Preface
noticed time and again that organizations were struggling to adopt mainstream agile methods
such as Extreme Programming (XP) and Scrum. At the same time Mark, also working with
organizations to adopt and apply agile techniques in practice, observed the same problems. In
many cases, the organization’s existing command-and-control culture hampered its adoption of
these more chaordic techniques. Furthermore, although many organizations were successful at
agile pilot projects, they struggled to roll out agile strategies beyond these pilot teams. A common
root cause was that the methods did not address the broader range of issues faced by IT departments, let alone the broader organization. Something wasn’t quite right.
Separately we began work on addressing these problems, with Scott taking a broad
approach by observing and working with dozens of organizations and Mark taking a deep
approach through long-term mentoring of agile teams at several organizations. In 2009 Scott led
the development of the DAD process framework within IBM Rational, an effort that continues to
this day. This work included the development of DAD courseware, whitepapers, and many blog
postings on IBM developerWorks®.3
What About Lean?
There are several reasons why lean strategies are crucial for DAD:
• Lean provides insights for streamlining the way that DAD teams work.
• Lean provides a solid foundation for scaling DAD to address complex situations, a topic
we touch on throughout the book but intend to address in greater detail in a future book.
• Lean principles explain why agile practices work, a common theme throughout this
book.
• Lean strategies, particularly those encapsulated by Kanban, provide an advanced adoption strategy for DAD.
So why aren’t we writing about Disciplined Lean Development (DLD) instead? Our experience is that lean strategies, as attractive and effective as they are, are likely beyond all but a
small percentage of teams at this time. Perhaps this “small” percentage is 10% to 15%—it’s certainly under 20%—but only time will tell. We’ve found that most development teams are better
served with a lightweight, end-to-end process framework that provides coherent and integrated
high-level advice for how to get the job done without getting bogged down in procedural details.
Having said that, many of the options that we describe for addressing the goals of the DAD
process framework are very clearly lean in nature, and we expect that many teams will evolve
their process from a mostly agile one to a mostly lean one over time.
DAD is the happy medium between the extremes of Scrum, a lightweight process framework that focuses on only a small part of the delivery process, and RUP, a comprehensive process
framework that covers the full delivery spectrum. DAD addresses the fundamentals of agile
3. https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/
Preface
xxiii
delivery while remaining flexible enough for you to tailor it to your own environment. In many
ways, Scrum taught agilists how to crawl, DAD hopes to teach agilists how to walk, and
agility@scale and lean approaches such as Kanban will teach us how to run.
How Does This Book Help?
We believe that there are several ways that you’ll benefit from reading this book:
• It describes an end-to-end agile delivery lifecycle.
• It describes common agile practices, how they fit into the lifecycle, and how they work
together.
• It describes how agile teams work effectively within your overall organization in an
“enterprise aware” manner, without assuming everyone else is going to be agile, too.
• It uses consistent, sensible terminology but also provides a map to terminology used by
other methods.
• It explains the trade-offs being made and in many cases gives you options for alternative
strategies.
• It provides a foundation from which to scale your agile strategy to meet the real-world
situations faced by your delivery teams.
• It goes beyond anecdotes to give fact-based reasons for why these techniques work.
• It really does answer the question “how do all these agile techniques fit together?”
Where Are We Coming From?
Both of us have seen organizations adopt Scrum and extend it with practices from XP, Agile
Modeling, and other sources into something very similar to DAD or to tailor down the Unified
Process into something similar to DAD. With either strategy, the organizations invested a lot of
effort that could have been easily avoided. With DAD, we hope to help teams and organizations
avoid the expense of a lengthy trial-and-error while still enabling teams to tailor the approach to
meet their unique situation.
Scott led the development of DAD within IBM Rational and still leads its evolution, leveraging his experiences helping organizations understand and adopt agile strategies. This book also
reflects lessons learned from within IBM Software Group, a diverse organization of 27,000
developers worldwide, and IBM’s Agile with Discipline (AwD) methodology followed by professionals in IBM Global Service’s Accelerated Solution Delivery (ASD) practice. In the autumn
of 2009 DAD was captured in IBM Rational’s three-day “Introduction to Disciplined Agile
Delivery” workshop. This workshop was rolled out in the first quarter of 2010 to IBM business
partners, including UPMentors, and Mark became one of the first non-IBMers to be qualified to
deliver the workshop. Since then, Mark has made significant contributions to DAD, bringing his
insights and experiences to bear.
xxiv
Preface
What’s The Best Way to Read this Book?
Most people will want to read this cover to cover. However, there are three exceptions:
• Experienced agile practitioners can start with Chapter 1, “Disciplined Agile Delivery in
a Nutshell,” which overviews DAD. Next, read Chapter 4, “Roles, Rights, and Responsibilities,” to understand the team roles. Then, read Chapters 6 through 19 to understand
in detail how DAD works.
• Senior IT managers should read Chapter 1 to understand how DAD works at a high level
and then skip to Chapter 20, “Governing Disciplined Agile Teams,” which focuses on
governing4 agile teams.
• People who prefer to work through an example of DAD in practice should read the case
study chapters first. These are: Chapter 12, “Initiating a Disciplined Agile Delivery
Project—Case Study”; Chapter 17, “Case Study: Construction Phase”; and Chapter 19,
“Case Study: Transition Phase.”
We hope that you embrace the core agile practices popularized by leading agile methods
but choose to supplement them with some necessary rigor and tooling appropriate for your organization and project realities.
Incidentally, a portion of the proceeds from the sale of this book are going to the Cystic
Fibrosis Foundation and Toronto Sick Kid’s Hospital, so thank you for supporting these worthy
causes.
The Disciplined Agile Delivery Web Site
www.DisciplinedAgileDelivery.com is the community Web site for anything related to DAD.
Mark and Scott are the moderators. You will also find other resources such as information
on DAD-related education, service providers, and supporting collateral that can be downloaded.
We invite anyone who would like to contribute to DAD to participate as a blogger. Join the
discussion!
4. Warning: Throughout the book we’ll be using “agile swear words” such as governance, management, modeling, and
yes, even the D-word—documentation. We’d like to apologize now for our use of foul language such as this.
Preface
xxv
Abbreviations Used in This Book
AD
Agile Data
AM
Agile Modeling
AMDD
Agile Model Driven Development
ASM
Agile Scaling Model
ATDD
Acceptance test driven development
AUP
Agile Unified Process
AwD
Agile with Discipline
BABOK
Business Analysis Book of Knowledge
BDD
Behavior driven development
BI
Business intelligence
BPMN
Business Process Modeling Notation
CASE
Computer aided software engineering
CD
Continuous deployment
CI
Continuous integration
CM
Configuration management
CMMI
Capability Maturity Model Integrated
COBIT
Control Objectives for Information and Related Technology
DAD
Disciplined Agile Delivery
DDJ
Dr. Dobb’s Journal
DevOps
Development operations
DI
Development intelligence
DODAF
Department of Defense Architecture Framework
DSDM
Dynamic System Development Method
EUP
Enterprise Unified Process
EVM
Earned value management
FDD
Feature Driven Development
GQM
Goal question metric
HR
Human resources
IT
Information technology
ITIL
Information Technology Infrastructure Library
JIT
Just in time
xxvi
Preface
MDD
Model driven development
MMR
Minimally marketable release
NFR
Non-functional requirement
NPV
Net present value
OSS
Open source software
PMBOK
Project Management Book of Knowledge
PMO
Project management office
ROI
Return on investment
RRC
Rational Requirements Composer
RSA
Rational Software Architect
RTC
Rational Team Concert™
RUP
Rational Unified Process
SCM
Software configuration management
SDLC
System development lifecycle
SLA
Service level agreement
SWEBOK
Software Engineering Book of Knowledge
TCO
Total cost of ownership
TDD
Test-driven development
TFD
Test first development
TOGAF
The Open Group Architecture Framework
T&M
Time and materials
TVO
Total value of ownership
UAT
User acceptance testing
UML
Unified Modeling Language
UI
User interface
UP
Unified Process
UX
User experience
WIP
Work in progress
XP
Extreme Programming
Acknowledgments
We’d like to thank the following people for their feedback regarding this book: Kevin Aguanno,
Brad Appleton, Ned Bader, Joshua Barnes, Peter Bauwens, Robert Boyle, Alan L. Brown, David
L. Brown, Murray Cantor, Nick Clare, Steven Crago, Diana Dehm, Jim Densmore, Paul Gorans,
Leslie R. Gornig, Tony Grout, Carson Holmes, Julian Holmes, Mark Kennaley, Richard Knaster,
Per Kroll, Cherifa Liamani, Christophe Lucas, Bruce MacIsaac, Trevor O. McCarthy, M.K.
McHugh, Jean-Louise Marechaux, Evangelos Mavrogiannakis, Brian Merzbach, Berne C.
Miller, Mike Perrow, Andy Pittaway, Emily J. Ratliff, Oliver Roehrsheim, Walker Royce, Chris
Sibbald, Lauren Schaefer, Paul Sims, Paula Stack, Alban Tsui, Karthikeswari Vijayapandian,
Lewis J. White, Elizabeth Woodward, and Ming Zhi Xie.
We’d also like to thank the following people for their ideas shared with us in online forums,
which were incorporated into this book: Eric Jan Malotaux, Bob Marshall, Valentin Tudor
Mocanu, Allan Shalloway, Steven Shaw, Horia Slusanschi, and Marvin Toll.
xxvii
About the Authors
Scott W. Ambler is Chief Methodologist for IT with IBM Rational, working with IBM customers around the world to help them to improve their
software processes. In addition to Disciplined Agile Delivery (DAD), he is
the founder of the Agile Modeling (AM), Agile Data (AD), Agile Unified
Process (AUP), and Enterprise Unified Process (EUP) methodologies and
creator of the Agile Scaling Model (ASM). Scott is the (co-)author of 20
books, including Refactoring Databases, Agile Modeling, Agile Database
Techniques, The Object Primer, 3rd Edition, and The Enterprise Unified
Process. Scott is a senior contributing editor with Dr. Dobb’s Journal. His personal home page is
www.ambysoft.com.
Mark Lines co-founded UPMentors in 2007. He is a disciplined agile
coach and mentors organizations on all aspects of software development. He
is passionate about reducing the huge waste in most IT organizations and
demonstrates hands-on approaches to speeding execution and improving
quality with agile and lean techniques. Mark provides IT assessments and
executes course corrections to turn around troubled projects. He writes for
many publications and is a frequent speaker at industry conferences. Mark is
also an instructor of IBM Rational and UPMentors courses on all aspects of
software development. His Web site is www.UPMentors.com. Mark can be reached at
Mark@UPMentors.com.
C
H A P T E R
1
Disciplined Agile
Delivery in a Nutshell
For every complex problem there is a solution that is simple, neat, and wrong. —H L Mencken
The agile software development paradigm burst onto the scene in the spring of 2001 with the publication of the Agile Manifesto (www.agilemanifesto.org). The 17 authors of the manifesto captured strategies, in the form of four value statements and twelve supporting principles, which they
had seen work in practice. These strategies promote close collaboration between developers and
their stakeholders; evolutionary and regular creation of software that adds value to the organization; remaining steadfastly focused on quality; adopting practices that provide high value and
avoiding those which provide little value (e.g., work smarter, not harder); and striving to improve
your approach to development throughout the lifecycle. For anyone with experience on successful software development teams, these strategies likely sound familiar.
Make no mistake, agile is not a fad. When mainstream agile methods such as Scrum and
Extreme Programming (XP) were introduced, the ideas contained in them were not new, nor were
they even revolutionary at the time. In fact, many of them have been described in-depth in other
methods such as Rapid Application Development (RAD), Evo, and various instantiations of the
Unified Process, not to mention classic books such as Frederick Brooks’ The Mythical Man
Month. It should not be surprising that working together closely in collocated teams and collaborating in a unified manner toward a goal of producing working software produces results superior
to those working in specialized silos concerned with individual rather than team performance. It
should also come as no surprise that reducing documentation and administrative bureaucracy
saves money and speeds up delivery.
While agile was once considered viable only for small, collocated teams, improvements in
product quality, team efficiency, and on-time delivery have motivated larger teams to take a closer
look at adopting agile principles in their environments. In fact, IBM has teams of several hundred
1
2
Chapter 1
Disciplined Agile Delivery in a Nutshell
people, often distributed around the globe, that are working on complex products who are applying agile techniques—and have been doing so successfully for years. A recent study conducted
by the Agile Journal determined that 88% of companies, many with more than 10,000 employees, are using or evaluating agile practices on their projects. Agile is becoming the dominant software development paradigm. This trend is also echoed in other industry studies, including one
conducted by Dr. Dobb’s Journal (DDJ), which found a 76% adoption rate of agile techniques,
and within those organizations doing agile, 44% of the project teams on average are applying
agile techniques in some way.
Unfortunately, we need to take adoption rate survey results with a grain of salt: A subsequent Ambysoft survey found that only 53% of people claiming to be on “agile teams” actually
were. It is clear that agile methods have been overly hyped by various media over the years, leading to abuse and misuse; in fact, the received message regarding agile appears to have justified
using little or no process at all. For too many project teams this resulted in anarchy and chaos,
leading to project failures and a backlash from the information technology (IT) and systems engineering communities that prefer more traditional approaches.
Properly executed, agile is not an excuse to be undisciplined. The execution of mainstream
agile methods such as XP for example have always demanded a disciplined approach, certainly
more than traditional approaches such as waterfall methods. Don’t mistake the high ceremony of
many traditional methods to be a sign of discipline, rather it’s a sign of rampant and often out-ofcontrol bureaucracy. However, mainstream agile methods don’t provide enough guidance for typical enterprises. Mature implementations of agile recognize a basic need in enterprises for a level
of rigor that core agile methods dismiss as not required such as governance, architectural planning, and modeling. Most mainstream agile methods admit that their strategies require significant
additions and adjustments to scale beyond teams of about eight people who are working together
in close proximity. Furthermore, most Fortune 1000 enterprises and government agencies have
larger solution delivery teams that are often distributed, so the required tailoring efforts can prove
both expensive and risky. The time is now for a new generation of agile process framework.
Figure 1.1 shows a mind map of the structure of this chapter. We describe each of the topics
in the map in clockwise order, beginning at the top right.
THE BIG IDEAS IN THIS CHAPTER
•
People are the primary determinant of success for IT delivery projects.
•
Moving to a disciplined agile delivery process is the first step in scaling agile
strategies.
•
Disciplined Agile Delivery (DAD) is an enterprise-aware hybrid software process
framework.
•
Agile strategies should be applied throughout the entire delivery lifecycle.
•
Agile teams are easier to govern than traditional teams.
Context Counts—The Agile Scaling Model
3
Context counts - the agile scaling model
What is the Disciplined Agile Delivery
(DAD) framework?
Scalable
Risk and value driven
Enterprise aware
Disciplined Agile Delivery
in a Nutshell
People first
Learning oriented
Goal-driven delivery lifecycle
IT solutions over software
Figure 1.1
Agile
A hybrid process framework
Outline of this chapter
Context Counts—The Agile Scaling Model
To understand the need for the Disciplined Agile Delivery (DAD) process framework you must
start by recognizing the realities of the situation you face. The Agile Scaling Model (ASM) is a
contextual framework that 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.
The ASM, depicted in Figure 1.2, defines three process categories:
1. Core agile development. Core agile methods—such as Scrum, XP, and Agile Modeling
(AM)—focus on construction-oriented activities. They are characterized by valuedriven lifecycles where high-quality potentially shippable software is produced on a
regular basis by a highly collaborative, self-organizing team. The focus is on small (
Purchase answer to see full
attachment