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