These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
AgileFORDUMmIES‰IBM LIMITED EDITIONby Scott W. Ambler andMatthew HolitzaThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1About This Book......................................................................... 1Foolish Assumptions.................................................................. 1Icons Used in This Book............................................................. 2Chapter 1: Getting the ABCs of Agile. . . . . . . . . . . . . . . . . 3Looking Back at Software Development Approaches............ 3Code-and-Fix/Big Bang development............................. 4Waterfall............................................................................. 4The Spiral model............................................................... 5Introducing the Agile Manifesto................................................ 7The Manifesto................................................................... 7The 12 principles that drive the Agile Manifesto......... 9Redefining Today’s Agile......................................................... 10Growing popularity........................................................ 10Growing scalability......................................................... 10Chapter 2: Understanding Agile Roles . . . . . . . . . . . . . . 11Being a Stakeholder.................................................................. 11Representing Stakeholders: The Product Owner................. 12Being a Team Member.............................................................. 13Assuming the Team Lead......................................................... 13Acting As the Architecture Owner.......................................... 13Stepping Up As an Agile Mentor............................................. 14Looking at Agile Secondary Roles........................................... 14Chapter 3: Getting Started with Agile. . . . . . . . . . . . . . . 15Agile Planning............................................................................ 15Attending the Daily Coordination Meeting............................ 16Creating User Stories................................................................ 16Estimating Your Work.............................................................. 18Tracking Velocity...................................................................... 19Measuring Progress with Burndown Reports....................... 20Test-Driven Development........................................................ 21Continuous Integration and Deployment............................... 22Presenting Results at the Iteration Review............................ 23Collecting Feedback in the Iteration Review Meeting.......... 23Learning and Improving at the Iteration Retrospective...... 24These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited EditionivChapter 4: Choosing an Agile Approach. . . . . . . . . . . . . 25SCRUM: Organizing Construction........................................... 25XP: Putting the Customer First................................................ 26Lean Programming: Producing JIT......................................... 27Kanban: Improving on Existing Systems................................ 28Agile Modeling........................................................................... 28Unified Process (UP)................................................................ 30Chapter 5: Using Disciplined Agile Delivery (DAD). . . 31Understanding the Attributes of DAD.................................... 31People first...................................................................... 32Learning-oriented........................................................... 32Agile.................................................................................. 33Hybrid.............................................................................. 33IT solution focused......................................................... 34Delivery focused............................................................. 35Goal driven...................................................................... 38Risk and value driven..................................................... 38Enterprise aware............................................................. 38Understanding the DAD Life Cycle......................................... 39Inception.......................................................................... 40Construction.................................................................... 40Transition........................................................................ 40Chapter 6: Scaling Agile Practices. . . . . . . . . . . . . . . . . 41Understanding What It Means to Scale.................................. 41Large teams..................................................................... 42Distributed teams........................................................... 42Compliance...................................................................... 42Domain complexity......................................................... 43Organization distribution.............................................. 43Technical complexity..................................................... 43Organizational complexity............................................ 43Enterprise discipline...................................................... 44Organizing Large Teams.......................................................... 44Chapter 7: Evaluating Agile Tools. . . . . . . . . . . . . . . . . . 47Considering Key Criteria for Selecting Agile Tools.............. 47Exploring the Jazz Initiative..................................................... 48Using the Best Tool for the Job............................................... 49Process awareness and customizability...................... 49Team awareness............................................................. 50These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Table of Contents vPlanning........................................................................... 50Transparency/project health........................................ 51Broad Platform Support................................................. 52Extending tooling beyond core agile development.... 52Chapter 8: Making the Move to Agile: IBM’s Story. . . . 53Setting Teams Up for Success................................................. 54Training............................................................................ 54Collaboration capabilities............................................. 54Changing culture............................................................. 54Changing roles................................................................ 55Team structure............................................................... 55Updating Processes for Distributed Teams........................... 56Working with New Tools.......................................................... 57Reaping the Benefits of Agile................................................... 58Chapter 9: Ten Common Agile Adoption Pitfalls. . . . . . 59Focusing Only on Construction.............................................. 59Becoming Agile Zombies.......................................................... 60Improper Planning.................................................................... 60Excluding the Entire Organization.......................................... 60Lack of Executive Support....................................................... 61Going Too Fast.......................................................................... 61Insufficient Coaching................................................................ 61Retaining Traditional Governance.......................................... 62Skimping on Training................................................................ 62Skimping on Tooling................................................................. 62Chapter 10: Ten Myths about Agile. . . . . . . . . . . . . . . . . 63Agile Is a Fad.............................................................................. 63Agile Isn’t Disciplined............................................................... 63Agile Means “We Don’t Plan”................................................... 64Agile Means “No Documentation”........................................... 64Agile Is Only Effective for Collocated Teams........................ 64Agile Doesn’t Scale.................................................................... 64Agile Is Unsuitable for Regulated Environments.................. 65Agile Means We Don’t Know What Will Be Delivered.......... 65Agile Won’t Work at My Company.......................................... 65It’s Enough for My Development Team to Be Agile.............. 66Agile Is a Silver Bullet............................................................... 66These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Publisher’s AcknowledgmentsWe’re proud of this book and of the people who worked on it. For details on how tocreate a custom For Dummies book for your business or organization, contact firstname.lastname@example.org. For details on licensing the For Dummies brand for products orservices, contact BrandedRights&Licenses@Wiley.com.Some of the people who helped bring this book to market include the following:Acquisitions, Editorial, and VerticalWebsitesProject Editor: Carrie A. BurchfieldDevelopment Editor:Colleen Totz-DiamondEditorial Manager: Rev MengleSenior Acquisitions Editor:Katie FeltmanBusiness Development Representative:Sue BlessingCustom Publishing Project Specialist:Michael SullivanComposition ServicesSenior Project Coordinator: Kristie ReesLayout and Graphics: Jennifer Creasey,Lavonne Roberts, Christin SwinfordProofreader: Jessica KramerPublishing and Editorial for Technology DummiesRichard Swadley, Vice President and Executive Group PublisherAndy Cummings, Vice President and PublisherMary Bednarek, Executive Director, AcquisitionsMary C. Corder, Editorial DirectorPublishing and Editorial for Consumer DummiesKathleen Nebenhaus, Vice President and Executive PublisherComposition ServicesDebbie Stailey, Director of Composition ServicesBusiness DevelopmentLisa Coleman, Director, New Market and Brand DevelopmentThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
IntroductionAgile development principles have gone from somethingusedonly by cutting-edge teams to a mainstream approachused by teams large and small for things as varied as the following: ✓ Startup software development projects ✓ Enterprise-sized development efforts ✓ Complex, large-scale systems engineering initiatives(such as the electronics in the cars you drive and theairplanes you fly in) ✓ Legacy systems (which means systems that have beenaround for a while, such as mainframe) ✓ Embedded, real-time systems (such as pacemakers orlife-support systems) ✓ High-compliance environments (such as healthcare,insurance, or banking)About This BookWelcome to Agile For Dummies, IBM Limited Edition. You’veprobably been hearing about agile for a long time, which isn’tsurprising. If you’re not using agile methods already though, orif you’ve only been exposed to agile on small projects here andthere, you may wonder how to get started with it. Can agile everwork in your environment? Relax. This book is here to help.Foolish AssumptionsMany people and teams can benefit most from this book, butwe took the liberty to assume the following: ✓ You’re looking to pilot a project using agile. You’re a projectmanager, a technical lead, or an aspiring product owner whowants to adopt agile practices but isn’t sure where to start.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition2 ✓ You may have tried out some agile practices in an ad hocmanner, and you encountered some difficulties. Don’tworry; many teams experience some missteps when firstmoving to agile. ✓ You’ve had some project success, and you’re looking togrow the agile practice beyond your team. You’re lookingfor ways to coordinate multiple teams with the sameoutcomes you experienced on your small team. ✓ You want to try agile, but your environment hascomplexities that need to be addressed. Maybe you haveglobally distributed teams or are subject to regulatorycompliance mandates. You’re wondering if agile practicescan be effective in this environment.But, no matter who you are, this book helps explain andreinforce the successful software development practicesavailable today. There’s great food for thought here, evenif your current team or organization isn’t ready to make theagile leap just yet.Icons Used in This BookSometimes, information deserves special attention. The iconsin this book identify such information for you. Here’s a briefexplanation for each icon so you’ll recognize them when theyturn up. The Tip icon points to information that describes a specialbenefit of working with agile. This icon identifies pitfalls and problems to avoid in youragile journey. The Remember icon presents you with tidbits that you won’twant to forget after you finish the book. This icon points out content that gets a little deeper into theweeds of agile development or explains agile jargon you mayencounter. The info isn’t crucial to your journey, so you canskip it if you like.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 1GettingtheABCsofAgileIn This Chapter▶ Understanding where software development has been▶ Dissecting the Agile Manifesto▶ Defining agile todayIf you’re reading this book, you’ve seen software being made.Regardless of your role on the project, you know it’s not aperfect process. You know it’s hard to do well. Software develop-ment doesn’t face problems for lack of trying or for lack of brainpower. People in the software business tend to be some verybright, hardworking people. They don’t plan to deliver softwareover budget, past deadline, and with defects (or without featurespeople need). So what’s been at the root of all these issues?Agile is an attempt to make the process of software developmentbetter and more effective, and it’s seen increasing popularityand success. In this chapter, you discover how agile is anincremental, iterative approach to delivering high-qualitysoftware with frequent deliveries to ensure value throughoutthe process. It places a high value on individuals, collaboration,and the ability to respond to change.Looking Back at SoftwareDevelopment ApproachesTo understand how agile has been successful, take a momentto look back at some of the software development approachesthat have gone before it. As software development hasevolved over the last 70-plus years, it has had several dominantmodels or methodologies. Each had reasons for coming intobeing, and really no model is used as is; models are almostThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition4always tailored to suite their unique needs. Each model hasits benefits and drawbacks. A model or methodology is just a fancy word for a process orapproach to creating software, usually with specific steps orphases used to manage it. The common thinking is that it’sbetter to have an approach in mind than to have none at all.Agile itself is just a newer, best-of-breed collection ofmethodologies used to develop and maintain software.Code-and-Fix/Big BangdevelopmentThe original approach to software development was Code-and-Fix development, where you wrote some code and then fixedthings that were incorrect as you found them (or when othersfound them for you). Software was delivered all at once, ina “big bang” — hence the term, Big Bang — and softwaredevelopers waited to find out what they may have donewrong, both in the form of outright errors and in the form ofnot meeting user needs or expectations.This approach is a challenging way to deliver software evenon the smallest, simplest scale. As the amount of code grewand became more complicated, this method was obviouslytoo risky and expensive an approach to software development.Something better was needed.WaterfallTo overcome the problems with the Big Bang/Code-and-Fixmodel (see the preceding section), software developmentbegan to take on specific stages:1. Requirements.2. Design.3. Development.4. Integration.5. Testing.6. Deployment.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 1: Getting the ABCs of Agile 5This kind of sequential, stage-based approach becamepopular in the mid-1950s. Not until 1970 did this modelbecome known as the Waterfall model — described as awaterfall because after finishing any one phase and moving onto the next, moving backward to make changes or correctionswas very difficult (water going the wrong way up a waterfall ispretty hard). Waterfall presented a step forward from Code-and-Fix and isstill used in many industries to this day. Despite wide adoptionand continued use, however, the model has problems: ✓ Schedule risk: Unless the system being designed isalready well understood, Waterfall has a higher-than-normal risk of not meeting schedule. Business needs maychange during a long project, and developers may beasked to squeeze in “one more thing,” which can have anincremental impact on test and deployment teams. Thesechanges in scope add up — an effect known as scopecreep. ✓ Limited flexibility: The Waterfall model locks downrequirements very early in the process, producing littlewiggle room to add late discoveries or needed changesthroughout the process. This is why scope creep (see thepreceding bullet) is problematic with this model. In addition, with testing held until the end of the process,defects in the form of code errors are discovered longafter the developers have written the code, making it notonly harder for the developer to find and fix but also canpotentially trigger the need for major design changestoward the end of the project. ✓ Reduced customer involvement: Involvement withcustomers in a Waterfall approach is limited and cancause companies to miss the market need. Studies showthat customers either always or often use the capabilitiesof a typical system only 20 percent of the time.The Spiral modelBy the mid-1980s, developers were experimenting withalternatives to Waterfall (see the preceding section). Iterativeand incremental approaches became popular:These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition6 ✓ An incremental approach regularly delivers working codein small chunks. ✓ An iterative approach plans on learning from feedback onthe deliveries and sets aside time to use this feedback tomake improvements. An incremental approach can be iterative because the smallchunks result in feedback; feedback leads to changes in thechunks already delivered, and shapes future direction. Thisprocess happens much more rapidly with incrementaldelivery than waiting until the end of a long-release cycle.Besides, if you wait until the end of a long-release cycle, theusers already have a long list of new features they need.The Spiral model, introduced in 1988, was a landmark softwaredevelopment methodology. It used prototyping andincremental delivery process to manage project risk. It wasdesigned to be especially effective for systems that had a highlevel of uncertainty around what exactly needed to be built.These kinds of projects struggle in the Waterfall approach(see the preceding section) because the detailed specifica-tions created ahead of time ran aground in the project whenthe problem space was better understood.The Spiral model — both incremental and iterative — deliveredthe final version of working software, and this archetypefollowed something closer to the Waterfall model. But it gotits name because of the way the model conceptualized itsincremental deliveries and the iterative work following adelivery.In the 1990s, more lightweight approaches gained popularity inan effort to come up with an effective alternative to Waterfall.RAD, or Rapid Application Development, relied on buildingprototypes to allow requirements to emerge and elicitfrequent feedback. The Scrum and XP (Extreme Programming)methodologies took root, both placing a heavy focus on shortiterations to allow frequent delivery of software. In general, toserve business needs and improve software project successrates.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 1: Getting the ABCs of Agile 7Introducing the Agile ManifestoIn February of 2001, a group of developers interested inadvancing lightweight development methodologies gottogether to talk about their views and to find common ground,and agile was born. The developers who created agileunderstood the importance of creating a model in which eachiteration in the development cycle “learned” from the previousiteration. The result was a methodology that was moreflexible, efficient, and team-oriented than any of the previousmodels.All the agile methods look to the Agile Manifesto and 12core principles for guidance. The adherence to the guidanceprovided by the manifesto and principles is what makes asoftware development team agile, not a specific process, tool,label.The ManifestoThe Manifesto for Agile Software Development is a compact68 words (now that’s lightweight!) that stresses four values.Manifesto for Agile Software Development*We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more.* Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave ThomasThis declaration may be freely copied in any form, but only in its entirety through this notice.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition8No boxes with arrows, no swim-lane diagrams here. The AgileManifesto is straightforward, but don’t let the brevity foolyou. This is powerful stuff. The following sections break downthe components of the manifesto.Individuals and interactions over processes and toolsRecognizing that software is made by people, not processesor tools, agile places a higher premium on people workingtogether effectively. Processes and tools can aid in that butcan’t replace it.Working software over comprehensive documentationValuing working software over comprehensive documentationstands in stark opposition to the Waterfall model. A highlydetailed, accurate, and comprehensive specification docu-ment is of no value if it doesn’t result in working software thatmeets users’ needs. Working software may involvedocumentation, but agile only uses it in service to creatingworking software, not as an end (almost) unto itself.Customer collaboration over contract negotiationWhile agile isn’t ignoring the reality of contracts, it values activecollaboration throughout the software development processas a better way to deliver value instead of a carefully wordedcontract. A contract is no proxy for actual communication whenyou’re doing something as challenging as creating software.Responding to change over following a planExcept for the most incredibly simple systems, it’s massivelydifficult to think of every feature, every piece of data, andevery possible use case for software. That means, in acollaborative process with the customer, a lot is discoveredduring the process of developing software. Also, the worldchanges pretty fast: Business needs and priorities can shiftin the months or even years it can take for a large system tobe fully built. Agile values the ability to change in responseto new discoveries and needs over sticking to a plan createdbefore everything was known.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 1: Getting the ABCs of Agile 9The 12 principles that drivethe Agile ManifestoThe people who wrote the Agile Manifesto later assembled12 principles that inform and reinforce the manifesto.These further illuminate the things agile values in softwaredevelopment.The Agile Manifesto follows these principles: 1. The highest priority is to satisfy the customer throughearly and continuous delivery of valuable software. 2. Welcome changing requirements, even late indevelopment. Agile processes harness change for thecustomer’s competitive advantage. 3. Deliver working software frequently, from a couple ofweeks to a couple of months, with a preference to theshorter timescale. 4. Business people and developers must work togetherdaily throughout the project. 5. Build projects around motivated individuals. Givethem the environment and support they need, andtrust them to get the job done. 6. The most efficient and effective method of conveyinginformation to and within a development team isface-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development.The sponsors, developers, and users should be able tomaintain a constant pace indefinitely. 9. Continuous attention to technical excellence and gooddesign enhances agility. 10. Simplicity — the art of maximizing the amount of worknot done — is essential. 11. The best architectures, requirements, and designsemerge from self-organizing teams. 12. At regular intervals, the team reflects on how tobecome more effective and then tunes and adjusts itsbehavior accordingly.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition10The Agile Manifesto and the principles behind it are publishedat http://www.agilemanifesto.org.Redefining Today’s AgileSince the time when the Agile Manifesto was drafted, agilehas grown in popularity, and its use has been extended toincreasingly larger organizations and more complex projects.Growing popularityAgile is a widely accepted and adopted approach to softwaredevelopment. Hundreds of books on agile exist, coveringeverything from how to manage agile development to how toapply it in specific industries to how to apply it with specificprogramming languages. You can attend agile training coursesand be an agile coach. Practitioners old and new are bloggingabout their challenges, discoveries, and successes.As businesses gain greater competitive advantage by beingable to move and change faster, agile approaches are beingused to develop many kinds of systems, including web-basedapplications, mobile applications, business intelligence (BI)systems, life-critical systems, and embedded software. Agileapproaches are adopted by varied organizations, includingfinancial companies, retailers, healthcare organizations,manufacturers, and government agencies — includingdefense.Growing scalabilityAs the advantages of agile become clear and the numberof success stories grows, more and more teams have beenattempting to scale agile practices to ever larger and morecomplex software development projects. Teams are findingsuccess with hybrid approaches that stay true to core agileprinciples and extend them beyond the software developmentstage to the entire software life cycle. Chapter 6 covers thescaling of agile practices.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 2UnderstandingAgileRolesIn This Chapter▶ Discovering the primary roles on agile teams▶ Taking a look at additional team positionsOn a disciplined agile project, any given person can be inone or more roles, and he can also change his role(s)over time. Roles aren’t positions, nor are they meant to be.Teams practicing agile adapt to styles that suit their needsand may vary in their exact execution. However, all tend tohave the same kinds of roles and very similar processes attheir core. Agile deemphasizes specialized roles and consid-ers all team members equal — everyone works to deliver asolution regardless of their job. With the exception of stake-holder, everyone’s effectively in the role of team member. Inthis chapter, you explore the roles, arming you with a basisfor understanding any style you may experience.Being a StakeholderA stakeholder is someone who’s financially impacted by theoutcome of the solution and is clearly more than an end-user.A stakeholder may be one of the following: ✓ A direct or indirect user ✓ A manager of users ✓ A senior manager ✓ An operations or IT staff member ✓ The “gold owner” who funds the project ✓ An auditor(s)These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition12 ✓ Your program/portfolio manager ✓ A developer(s) working on other systems that integrateor interact with the one under development ✓ A maintenance professional(s) potentially affected by thedevelopment and/or deployment of a software projectRepresenting Stakeholders:The Product OwnerThe product owner is the team member who speaks as the“one voice of the customer.” This person represents theneeds and desires of the stakeholder community to the agiledelivery team. He clarifies any details regarding the solutionand is also responsible for maintaining a prioritized list ofwork items that the team will implement to deliver the solution.While the product owner may not be able to answer allquestions, it’s his responsibility to track down the answer in atimely manner so the team can stay focused on its tasks. Eachagile team, or subteam in the case of large projects organizedinto a team of teams, has a single product owner.The product owner has the following additional roles: ✓ Communicates the project status and represents thework of the agile team to key stakeholders ✓ Develops strategy and direction for the project and setslong- and short-term goals ✓ Understands and conveys the customers’ and otherbusiness stakeholders’ needs to the development team ✓ Gathers, prioritizes, and manages product requirements ✓ Directs the product’s budget and profitability ✓ Chooses the release date for completed functionality ✓ Answers questions and makes decisions with thedevelopment team ✓ Accepts or rejects completed work during the sprint ✓ Presents the team’s accomplishments at the end of eachsprintThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 2: Understanding Agile Roles 13Being a Team MemberThe role of team member focuses on producing the actualsolution for stakeholders. Team members perform testing,analysis, architecture, design, programming, planning,estimation, and many more activities as appropriate throughoutthe project. Not every team member has every single skill (at least notyet), but they have a subset of them and strive to gain moreskills over time. Team members identify, estimate, sign-up for,and perform tasks and track their completion status.Assuming the Team LeadThe team lead guides the team in performing managementactivities instead of taking on these responsibilities herself.She’s a servant-leader to the team, upholding the conditionsthat allow the team’s success. This person is also an agilecoach who helps keep the team focused on delivering workitems and fulfilling its iteration goals and commitments tothe product owner. The team lead facilitates communication,empowers the team to self-optimize its processes, ensuresthat the team has the resources it needs, and manages issueresolution in a timely manner. While an experienced team lead brings skills to a new team,this person can’t be a true coach without mentoring. So forteams new to agile, you may have a part-time experiencedcoach working with the team for a few iterations.Acting As the ArchitectureOwnerArchitecture is a key source of project risk, and someone hasto be responsible for ensuring the team mitigates this risk.The architecture owner is the person who owns the architecturedecisions for the team and who facilitates the creation andevolution of the overall solution design.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition14 You may not have to formally designate a team member as anarchitecture owner on small teams, because the person in therole of team lead often is the architecture owner, too.Stepping Up As an Agile MentorA mentor is a great idea for any area in which you want todevelop new expertise. The agile mentor, sometimes called anagile coach, implements agile projects and shares that experi-ence with a project team. He provides valuable feedback andadvice to new project teams and to project teams that want toperform at a higher level. On an agile project, the agile mentor is ✓ A coach only and isn’t part of the team ✓ Often from outside the organization and objective inguidance without personal or political considerations ✓ Experienced in implementing agile techniques andrunning agile projects in different situationsLooking at Agile Secondary RolesYour project may include the need to add some or all thefollowing roles: ✓ Domain expert: Someone with deep business/domainknowledge beyond that of the product owner. ✓ Specialist: Although most agile team members aregeneralizing specialists, sometimes, particularly at scale,specialists such as business analysts or even project/program managers are required. ✓ Technical expert: Technical experts are brought in asneeded to help the team overcome a difficult problem and totransfer their skills to one or more developers on the team. ✓ Independent tester: Some agile teams are supportedby an independent test team working in parallel thatvalidates work throughout the life cycle. ✓ Integrator: For complex environments, your team mayrequire one or more people in the role of integratorresponsible for building the entire system from its varioussubsystems.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3GettingStartedwithAgileIn This Chapter▶ Looking at agile planning practices▶ Managing and tracking your progress▶ Reflecting for future improvementIn this chapter, you explore how the agile team organizesthe software development process. Everything thestakeholders want in their software is broken down intosmall chunks, ranked, worked on in priority order overshort iterations (typically one to four weeks), reviewed forapproval, and delivered to production. This process repeatsuntil the prioritized list is finished, called a release. An agileteam expects re-prioritization, additions to the list, andsubtractions from the list throughout the process butembraces them as a means to deliver the most value and thebest possible solution.Agile PlanningTeams following agile software development methods typi-cally divide their release schedule into a series of fixed-lengthdevelopment iterations of two to four weeks — shorter isgenerally better than longer. Planning involves scheduling thework to be done during an iteration or release and assigningindividual work items to members of the team.To be effective and to reflect the team’s position and direction,plans need to be accessible to everyone on the team andto change dynamically over the course of the iteration.Automated planning tools are available to facilitate thisprocess, or you can have at it the old-fashioned way withwhiteboards, index cards, or sticky notes.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition16 During an agile project, planning occurs at three levels: ✓ Release planning: Release plans contain a releaseschedule for a specific set of features. The product ownercreates a release plan at the start of each release. ✓ Iteration planning: Team members gather at the beginningof the iteration (referred to as a sprint in the Scrummethodology) to identify the work to be done duringthat iteration. This is referred to as self-organization. ✓ Daily planning: Development teams begin each day withstandup meetings to plan the day. These meetings aregenerally 5 to 15 minutes long.Attending the Daily CoordinationMeetingOn agile projects, you make plans throughout the entireproject daily. Agile development teams start each workdaywith a 15-minute (or less) daily coordination meeting to notecompleted items, to identify impediments, or roadblocks,requiring team lead involvement, and to plan their day.In the daily coordination meeting, often called a daily standupmeeting, each development team member makes the followingthree statements: ✓ Yesterday, I completed [state items completed]. ✓ Today, I’m going to take on [state task]. ✓ My impediments are [state impediments, if any]. Daily coordination meetings can actually be quite fun whenusing the right tools. For example, the Taskboard view inRational Team Concert (RTC) is a capability that arranges allwork items as cards on a board with multiple columns. Formore info on the Taskboard view, see Chapter 8.Creating User StoriesWhen stakeholders realize the need for a new softwaresystem, feature set, or application, the agile process beginsThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Getting Started with Agile 17with the product owner defining what the software will do andwhat services it provides to its users. Instead of following themore traditional process of product managers and businessanalysts writing lengthy requirements or specifications, agiletakes a lightweight approach of writing down brief descriptionsof the pieces and parts that are needed. These become workitems and are captured in the form of user stories. A user storyis a simple description of a product requirement in terms ofwhat that requirement must accomplish for whom. Your userstory needs to have, at a minimum, the following parts: ✓ Title: <a name for the user story> ✓ As a <user or persona> ✓ I want to <take this action> ✓ So that <I get this benefit>The story should also include validation steps — steps to taketo know that the working requirement for the user story iscorrect. That step is worded as follows: ✓ When I <take this action>, this happens <description ofaction>User stories may also include the following: ✓ An ID: A number to differentiate this user story fromother user stories. ✓ The value and effort estimate: Value is how beneficial auser story is to the organization creating that product.Effort is the ease or difficulty in creating that user story. ✓ The person who created the user story: Anyone on theproject team can create a user story. For user stories that are too large to be completed in asingle iteration or sprint, some teams use Epics. Epics arebasically a higher-level story that’s fulfilled by a group ofrelated user stories.Figure 3-1 shows a typical user story card, back and front.The front has the main description of the user story. The backshows how you confirm that the requirement works correctlyafter the development team has created the requirement.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition18TitleAsI want toso thatTransfer money between accountsCarol,review fund levels in my accountsand transfer funds between accountsI can complete the transfer and see thenew balances in the relevant accounts.Value AuthorJenniferEstimateTitleAsI want toso that<personal/user><action><benefit>Value Author EstimateFigure 3-1: Card-based user story example.The product owner gathers and manages the user stories.However, the development team and other stakeholders alsowill be involved in creating and decomposing user stories. User stories aren’t the only way to describe productrequirements. You could simply make a list of requirementswithout any given structure. However, because user storiesinclude a lot of useful information in a simple, compactformat, they tend to be very effective at conveying exactlywhat a requirement needs to do.Estimating Your WorkWhen the product owner sets the scope of an iteration, sheneeds to know that the scope is the right size — that thereisn’t too much work to get done in the iteration. Like anyother developers, agile team members estimate their work.Unlike other developers, agile team members estimate insomething called points. Points represent a size-based,complexity-based approach to estimation. Points are assignedin whole numbers (1, 2, 3, and so on with no fractions ordecimals) and represent relative sizes and complexity of workitems. Small and simple tasks are one point tasks, slightlylarger/more complex tasks are two point tasks, and so on. Points are kind of like t-shirt sizes. There are small, medium,large, extra large, and potentially other sizes (extra small andextra extra-large). These sizes are relative — no regulationdictates how much larger medium is compared to small. Sizesvary a bit from manufacturer to manufacturer. T-shirt sizingsucceeds not because of high precision — it’s pretty imprecise,actually — but through its general accuracy.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Getting Started with Agile 19In practice, one team’s three-point size estimate for a workitem may correlate to another team’s two-point estimate foran identical work item. Teams need only agree on what sizeand complexity corresponds to what point count and remaininternally consistent in their use. You may be tempted to equate points to hours. Don’t do it!An agile team gains consistency by using point values thatdon’t vary based on the ability of the person doing the work.A five-point story has the same size and complexity on agiven team regardless of who does the work. The team stillaccommodates faster and slower team members in thenumber of points assigned in a single iteration, but the valuedelivered to the product owner and stakeholders (measuredby size and complexity) remains consistent. If you want totrack effort and hours, keep it separate from points.Tracking VelocityAt the end of each iteration, the agile team looks at therequirements it has finished and adds up the number of storypoints associated with those requirements. The total numberof completed story points is the team’s velocity, or workPlanning PokerAs you refine your requirements, youneed to refine your estimates as well.Planning Poker is a technique todetermine user story size and to buildconsensus with the developmentteam members. Planning pokeris a popular and straightforwardapproach to estimating story size.To play planning poker, you need adeck of cards with point values onthem. There are free online planningpoker tools and mobile apps, or youcan make your own with index cardsand markers. The numbers on thecards are usually from the Fibonaccisequence.Only the development team playsestimation poker. The team lead andproduct owner don’t get a deck anddon’t provide estimates. However,the team lead can act as a facilitator,and the product owner reads theuser stories and provides details onuser stories as needed.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition20output, for that iteration. After the first few iterations, you’llstart to see a trend and will be able to calculate the averagevelocity. The average velocity is the total number of story pointscompleted, divided by the total number of iterations completed.For example, if the development team’s velocity was . . .Iteration 1 = 15 pointsIteration 2 = 19 pointsIteration 3 = 21 pointsIteration 4 = 25 points. . . your total number of story points completed is 80. Youraverage velocity is 20 to 80 story points divided by fouriterations. After you’ve run an iteration and know the team’svelocity, you can start forecasting the remaining time on yourproject.Measuring Progress withBurndown ReportsBurndown reports track the number of points completed andare used for monitoring single iterations, releases, and theentire project backlog. They get their name from the conceptthat the iteration or project backlog gets “burned down,”completed, and cleared away. Burndown reports show progress,reflecting both the value delivered (in points) and the team’svelocity. See Figure 3-2 for a simple project burndown report,with iterations along the X-axis and the points in the entireproduct backlog on the Y-axis.You may also find that you need to re-estimate the backlog.As the team progresses through a project, it discovers moreabout that project, its technology, and the business concernsthe project addresses. Greater understanding leads to betterestimates, so the points associated with some work items inthe backlog can become more accurate over time.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Getting Started with Agile 21Project BurndownIterationPoints1 2 3 4 5 6 7 8 9 10BacklogPoints400350300250200150100500Figure 3-2: A project burndown report.Test-Driven DevelopmentTesting occurs throughout the agile life cycle. While anindependent tester may or may not be a member of the cross-functional team, developers are expected to test their code.Some of you are saying, “Hold on, developers can’t test theirown work. They don’t want to. They’re not good at it!” Buttrust me; it’s not as bad as you think. In fact, it’s not bad at all.Agile teams use two common practices to handle their testing: ✓ Test-Driven Development (TDD) ✓ Automated unit testsWhen used together, they’re a powerful force.Performing TDD means that before the developer writes apiece of code, she first writes a small test that validates thecode she’s about to write. She runs the test to make sure itfails and then writes the code that makes the test pass. Thismay seem odd, but with practice it’s much more efficient thanThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition22writing a lot of code, running it, and going back later to figureout everywhere it’s broken (a process known as debugging).This process puts the developer in a testing mindset whilewriting code, which leads to higher-quality code.When a developer executes a small test against code she’swritten, it’s called a unit test. When these tests are run inbatches all at once (automated), they become very powerful.Agile teams write a lot of unit tests, automate them, and runthem frequently against the code they write as individualsand against their combined code that makes up the entireapplication. Running automated unit tests frequently againstthe code reveals problems quickly so they can be addressedquickly. This approach finds defects long before they’d everreach a traditional test cycle, which means higher-qualityapplications.Continuous Integrationand DeploymentContinuous integration (CI) is the practice of regularlyintegrating and testing your solution to incorporate changesmade to its definition. Changes include updating the sourcecode, changing a database schema, or updating a configurationfile. Ideally, when one or more changes are checked into yourconfiguration management system, the solution should berebuilt (recompiled), retested, and any code or schemaanalysis performed on it. Failing that, you should strive to doso at least once if not several times a day.Continuous deployment (CD) enhances CI by automaticallydeploying successful builds. For example, when the build issuccessful on a developer’s workstation, she may automaticallydeploy her changes to the project integration environment,which would invoke the CI system there. A successfulintegration in that environment could trigger an automaticdeployment into another environment and so on.On a developer’s workstation, the integration job could runat specific times, perhaps once an hour, or better every timethat she checks in something that is part of the build. Thiswhole process of continuously integrating a developer’s codewith the rest of a team’s code in and then running automatedThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 3: Getting Started with Agile 23test regressions in an integration environment is a criticalpart of agile done right. CI ensures high-quality workingsoftware at all times, and CD ensures that the software isrunning in the right place.Presenting Results atthe Iteration ReviewThe iteration review, or sprint review in Scrum, is a meeting toreview and demonstrate the user stories that the developmentteam completed during the iteration. The iteration review isopen to anyone interested in reviewing the iteration’saccomplishments. This means that all stakeholders get achance to see progress on the product and provide feedback.Preparation for the iteration review meeting should not takemore than a few minutes. Even though the iteration reviewmight sound formal, the essence of showcasing in agile isinformality. The meeting needs to be prepared and organized,but that doesn’t require a lot of flashy materials. Instead,the iteration review focuses on demonstrating what thedevelopment team has done.Collecting Feedback in theIteration Review MeetingGather iteration review feedback informally. The productowner or team lead can take notes on behalf of the developmentteam, as team members often are engaged in the presentationand resulting conversation. New user stories may come out ofthe iteration review. The new user stories can be new featuresaltogether or changes to the existing code. In the first couple of iteration reviews, the team lead mayneed to remind stakeholders about agile practices. Somepeople hear the word demonstration and immediately expectfancy slides and printouts. The team lead has a responsibilityto manage these expectations and uphold agile values andpractices.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition24The product owner needs to add any new user stories tothe product backlog and rank those stories by priority. Theproduct owner also adds stories that were scheduled for thecurrent iteration, but not completed, back into the productbacklog, and ranks those stories again based on the mostrecent priorities. The product owner needs to completeupdates to the product backlog in time for the next iterationplanning meeting.Learning and Improving atthe Iteration RetrospectiveAfter the iteration review is over (see the preceding section),the iteration retrospective begins. The iteration retrospectiveis a meeting where the team lead, the product owner, and thedevelopment team discuss how the iteration went and whatthey can do to improve the next iteration. If the team wantsto, other stakeholders can attend as well. If the team regularlyinteracts with outside stakeholders, and it should, then thosestakeholders’ insights can be valuable. You may want to take a break between the iteration reviewand the iteration retrospective. The team needs to come intothe retrospective ready to inspect its processes and presentideas for adaptation.The goal of the iteration retrospective is to continuouslyimprove your processes. Improving and customizing processesaccording to the needs of each individual team increases teammorale, improves efficiency, and increases velocity — workoutput.Agile approaches quickly reveal problems within projects.Data from the iteration backlog shows exactly where thedevelopment team has been slowed down, so the productowner should revisit the backlog to prepare for the nextiteration. Have priorities shifted? Have important new issuesappeared? The product owner has to actively manage thebacklog in preparation for the next iteration.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 4ChoosinganAgileApproachIn This Chapter▶ Understanding various agile approaches▶ Looking at the strengths and weakness of each approachYou can use several agile methods as a base to tailor astrategy to meet the unique needs of your situation. Thischapter discusses these varied approaches.Scrum: Organizing ConstructionScrum is the most popular approach to agile softwaredevelopment. With this approach, any adjustments thedevelopment team makes to any aspect of the project is basedon experience, not theory. Scrum provides four deliverables: ✓ Product backlog: The full list of requirements that definethe product ✓ Sprint backlog: The list of requirements and associatedtasks in a given sprint (Scrum calls iterations sprints) ✓ Burndown charts: Visual representations of the progresswithin a sprint and within the project as a whole. ✓ Shippable functionality: The usable product that meetsthe customer’s business goalsFive practices, covered in detail in Chapter 3, are key to Scrum.They are release planning, sprint planning, the daily scrummeeting, the sprint review meeting, and the sprint retrospective.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition26XP: Putting the Customer FirstA popular approach to product development, specific tosoftware, is Extreme Programming (XP). The focus of XP iscustomer satisfaction. XP teams achieve high customersatisfaction by developing features when the customer needsthem. New requests are part of the development team’s dailyroutine, and the team must deal with requests whenever theycrop up. The team organizes itself around any problem thatarises and solves it as efficiently as possible. The followingare XP practices: ✓ Coding standard: Team members should followestablished coding guidelines and standards. ✓ Collective ownership: Team members may view andedit other team members’ code or any other projectartifact. Collective ownership encourages transparencyand accountability for work quality. ✓ Continuous integration: Team members should check inchanges to their code frequently, integrating the systemto ensure that their changes work, so the rest of the teamis always working with the latest version of the system. ✓ Test-Driven Development (TDD): In TDD the first step isto quickly code a new test — basically just enough codefor the test to fail. This test could either be high-levelacceptance or a more detailed developer test. You thenupdate your functional code to make it pass the new test,get your software running, and then iterate. ✓ Customer tests: Detailed requirements are capturedjust-in-time (JIT) in the form of acceptance tests (alsocalled story tests). ✓ Refactoring: Refactoring is a small change to something,such as source code, your database schema, or userinterface, to improve its design and make it easier tounderstand and modify. The act of refactoring enablesyou to evolve your work slowly over time. ✓ Pair programming: In this practice, two programmerswork together on the same artifact at the same time. Oneprogrammer types the code while the other programmerlooks at the bigger picture and provides real-time codereview.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 4: Choosing an Agile Approach 27 ✓ Planning game: The purpose of the planning game is toguide the product into successful delivery. This includeshigh-level release planning to think through and monitorthe big issues throughout the project as well as detailedJIT iteration/sprint planning. ✓ Simple design: Programmers should seek the simplestway to write their code while still implementing theappropriate functionality. ✓ Small releases: Frequent deployment of valuable, workingsoftware into production is encouraged. Frequentdeployments build confidence in the team and trust fromthe customer. ✓ Sustainable pace: The team should be able to sustain anenergized approach to work at a constant and graduallyimproving velocity. ✓ Whole team: Team members should collectively have allthe skills required to deliver the solution. Stakeholdersor their representatives should be available to answerquestions and make decisions in a timely manner.Lean Programming: Producing JITLean has its origins in manufacturing. In the 1940s in Japan, asmall company called Toyota wanted to produce cars for theJapanese market but couldn’t afford the huge investment thatmass production requires. The company studied supermarkets,noting how consumers buy just what they need, becausethey know there will always be a supply, and how the storesrestock shelves only as they empty. From this observation,Toyota created a JIT process that it could translate to thefactory floor.The result was a significant reduction in inventory of partsand finished goods and a lower investment in the machines,people, and space. The JIT process gives workers the abilityto make decisions about what is most important to do next.The workers take responsibility for the results. Toyota’s successwith JIT processes has helped change mass manufacturingapproaches globally.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition28The seven principles of lean manufacturing can be appliedto optimize the whole IT value stream. The lean softwaredevelopment principles are eliminate waste, build in quality,create knowledge, defer commitment, deliver quickly, respectpeople, and optimize the whole.Kanban: Improving onExisting SystemsThe Kanban method is a lean methodology, describingtechniques for improving your approach to softwaredevelopment. Two Kanban principles critical to success are ✓ Visualizing workflow: Teams use a Kanban board (oftena whiteboard, corkboard, or electronic board) thatdisplays kanbans (indications of where in the process apiece of work is). The board is organized into columns,each one representing a stage in the process, a workbuffer, or queue; and optional rows, indicating theallocation of capacity to classes of service. The board isupdated by team members as work proceeds, andblocking issues are identified during daily meetings. ✓ Limit work in progress (WIP): Limiting WIP reducesaverage lead time, improving the quality of the workproduced and increasing overall productivity of yourteam. Reducing lead time also increases your ability todeliver frequent functionality, which helps build trustwith your stakeholders. To limit WIP, understand whereyour blocking issues are, address them quickly, andreduce queue and buffer sizes wherever you can.Agile ModelingAgile Modeling (AM) is a collection of values, principles, andpractices for modeling software that can be applied on asoftware development project in an effective and lightweightmanner. AM was purposely designed to be a source of strategiesthat can be tailored into other base processes.With an Agile Model Driven Development (AMDD) approach,you typically do just enough high-level modeling at theThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 4: Choosing an Agile Approach 29beginning of a project to understand the scope and potentialarchitecture of the system. During construction iterations youdo modeling as part of your iteration planning activities andthen take a JIT model storming approach where you modelfor several minutes as a precursor to several hours of coding.AMDD recommends that practitioners take a test-drivenapproach to development although doesn’t insist on it.The Agile Modeling practices include the following: ✓ Active stakeholder participation: Stakeholders (or theirrepresentatives) provide info, make decisions, and areactively involved in the development process. ✓ Architecture envisioning: This practice involveshigh-level architectural modeling to identify a viabletechnical strategy for your solution. ✓ Document continuously: Write documentation for yourdeliverables throughout the life cycle in parallel to thecreation of the rest of the solution. Some teams chooseto write the documentation one iteration behind to focuson capturing stable information. ✓ Document late: Write deliverable documentation as lateas possible to avoid speculative ideas likely to change infavor of stable information. ✓ Executable specifications: Specify detailed requirements inthe form of executable customer tests and your detaileddesign as executable developer tests. ✓ Iteration modeling: Iteration modeling helps identifywhat needs to be built and how. ✓ Just barely good enough artifacts: A model needs to besufficient for the situation at hand and no more. ✓ Look-ahead modeling: Invest time modeling requirementsyou intend to implement in upcoming iterations.Requirements near the top of your work item list arefairly complex so explore them before they’re popped offthe top to reduce overall project risk. ✓ Model storming: Do JIT modeling to explore the detailsbehind a requirement or to think through a design issue. ✓ Multiple models: An effective developer has a range ofmodels in his toolkit, enabling him to apply the rightmodel for the situation at hand.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition30 ✓ Prioritized requirements: Implement requirements inpriority order, as defined by your stakeholders. ✓ Requirements envisioning: Invest your time at the startof an agile project to identify the scope of the project andcreate the initial prioritized stack of requirements. ✓ Single-source information: Capture info in one placeonly. ✓ TDD: Quickly code a new test and update your functionalcode to make it pass the new test.Unified Process (UP)The Unified Process (UP) uses iterative and incrementalapproaches within a set life cycle. UP focuses on thecollaborative nature of software development and works withtools in a low-ceremony way. It can be extended to addressa broad variety of project types, including OpenUP, AgileUnified Process (AUP), and Rational Unified Process (RUP).UP divides the project into iterations focused on deliveringincremental value to stakeholders in a predictable manner.The iteration plan defines what should be delivered withinthe iteration, and the result is ready for iteration review orshipping. UP teams like to self-organize around how toaccomplish iteration objectives and commit to delivering theresults. They do that by defining and “pulling” fine-grainedtasks from a work items list. UP applies an iteration life cyclethat structures how micro-increments are applied to deliverstable, cohesive builds of the system that incrementallyprogress toward the iteration objectives.UP structures the project life cycle into four phases:Inception, Elaboration, Construction, and Transition. Theproject life cycle provides stakeholders and team memberswith visibility and decision points throughout the project.This enables effective oversight and allows you to make “go orno-go” decisions at appropriate times. A project plan definesthe life cycle, and the end result is a released application.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5UsingDisciplinedAgileDelivery(DAD)In This Chapter▶ Listing the characteristics of DAD▶ Getting to know the DAD life cycleDisciplined Agile Delivery (DAD) is a process frameworkthat encompasses the entire solution life cycle, acting likean umbrella over best practices from many agile approaches(for the varied approaches, flip back to Chapter 4). DAD seesthe solution through initiation of the project through construc-tion to the point of releasing the solution into production. When you adopt agile, you’re likely to encounter a few speedbumps along the way, so it’s important to collaborate with otheragile practitioners to get ideas on what methods to start with,how to grow your practice, and what common pitfalls to avoid(see Chapter 9). To get started, join an online agile community,such as the Agile Transformation Zone. Visit http://ibm.co/getagile.At this point, DAD works splendidly to help you avoidthe pitfalls, all while providing a comprehensive life cyclemanagement solution.Understanding theAttributes of DADThe DAD process framework has several importantcharacteristics that are detailed in this section.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition32People firstWith DAD, people, and the way they work together, are thefirst order of business. In an agile environment, the boundariesbetween disciplines are torn down and handoffs are minimizedin the interest of working as a team instead of a group ofspecialized individuals. But in DAD, cross-functional teamsare made up of cross-functional people. You don’t havehierarchy within the team, and team members are encouragedto be cross-functional in their skill sets and perform workrelated to disciplines other than their specialty. Because teammembers gain understanding beyond their primary discipline,resources are used more effectively, and formal documentationand sign-offs, by and large, aren’t necessary. When you adopt an agile approach, people are pushed outsidetheir comfort zone. Taking on work outside of their establishedskill sets may not be something they’re accustomed to doing.They also may be reluctant to give up the work where theyfeel they have the most expertise, for fear of losing relevance.By eliminating hierarchy and providing roles that incorporatecross-functional skill sets, DAD paves the way for this transitionto go a little more smoothly.The five primary roles of DAD include the following: ✓ Stakeholder ✓ Product owner ✓ Team member ✓ Team lead ✓ Architecture ownerFor details on each of these roles, check out Chapter 2.Learning-orientedOrganizations working with traditional approaches to life cyclemanagement often don’t get the most out of every opportunityfor their staff to learn about the way effective solutions areproduced, yet the most effective organizations are the onesthat promote a learning-oriented environment for their staff.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5: Using Disciplined Agile Delivery (DAD) 33An important aspect of DAD is the iteration retrospectivemeetings (covered in Chapter 3). These meetings occurthroughout the solution life cycle. In this way, team memberscan make corrections to their processes as they go, leading toa more efficient and effective outcome and learning from theirown mistakes to make each sprint better.AgileThe DAD process framework adheres to and enhances thevalues and principles of the Agile Manifesto (described inChapter 1).Teams following either iterative or agile processeshave been shown to ✓ Produce higher quality: High quality is achieved throughtechniques such as continuous integration (CI), developerregression testing, test-first development, and refactoring. ✓ Provide greater return on investment (ROI): ImprovedROI comes from focusing more on high-value activities,working in priority order, automating as much of the ITdrudgery as possible, self-organizing, close collaborating,and working smarter, not harder. ✓ Provide greater stakeholder satisfaction: Greaterstakeholder satisfaction is achieved by enabling activestakeholder participation, incrementally delivering apotentially consumable solution with each iteration,and enabling stakeholders to evolve their requirementsthroughout the project. ✓ Deliver quicker: Quicker delivery as compared to eithera traditional/waterfall approach or an ad-hoc (no definedprocess) approach.HybridThe DAD process framework is a hybrid: It adopts and tailorsstrategies from a variety of sources. A common pattern withinorganizations is that they adopt the Scrum process frame-work and then do significant work to tailor ideas from othersources to flesh it out. This sounds like a great strategy, andit certainly is if you’re a consultant specializing in agile adop-tion, until you notice that organizations tend to tailor Scrumin the same sort of way.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition34DAD is a more robust process framework that has alreadydone this common work. The DAD process framework adoptsstrategies from the following methods: ✓ Scrum: DAD adopts and tailors many ideas from Scrum,such as completing a stack of work items in priority order,having a product owner responsible for representingstakeholders, and producing a potentially consumablesolution from each iteration. See Chapter 4 for morebackground information on Scrum. ✓ Extreme programming (XP): XP is an important sourceof development practices for DAD, including but notlimited to continuous integration (CI), refactoring,test-driven development (TDD), collective ownership,and many more. See Chapter 4 for more info on XP. ✓ Agile Modeling (AM): DAD models its documentationpractices after requirements envisioning, architectureenvisioning, iteration modeling, continuous documentation,and just-in-time (JIT) model storming. See Chapter 4 formore info about AM. ✓ Unified Process (UP): DAD adopts several governancestrategies from UP. In particular, this includes strategiessuch as having lightweight milestones and explicitphases and focusing on the importance of proving outthe architecture in the early iterations and reducing alltypes of risk early in the life cycle. Read more about UPin Chapter 4. ✓ Agile Data (AD): DAD adopts several agile databasepractices from AD such as database refactoring, databasetest-in, and agile data modeling. It is also an importantsource of agile enterprise strategies, such as how agileteams can work effectively with enterprise architects andenterprise data administrators. ✓ Kanban: DAD adopts two critical concepts — limitingwork in progress and visualizing work — from Kanban.Read more about Kanban in Chapter 4.IT solution focusedMuch of the focus within the agile community is on softwaredevelopment. DAD teams realize that in addition to softwarethey must also address hardware, documentation, businessThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5: Using Disciplined Agile Delivery (DAD) 35process, and even organizational structure issues pertainingto their overall solution. The DAD process frameworks promotes activities thatexplicitly address user experience (UX), database, businessprocess, and documentation issues (to name a few) to helpproject teams think beyond software development alone.Delivery focusedDAD addresses the entire life cycle from the point of initiatingthe project through construction to the point of releasing thesolution into production. The project is carved into phaseswith lightweight milestones to ensure that the project isfocused on the right things at the right time, such as initialvisioning, architectural modeling, risk management, anddeployment planning.This differs from methods such as Scrum and XP, which focuson the construction aspects of the life cycle. Details about howto perform initiation and release activities, or even how they fitinto the overall life cycle, are typically vague and left up to you.The life cycle of a DAD project is shown in Figure 5-1.This lifecycle has three critical features: ✓ A delivery life cycle: The DAD life cycle extends the Scrumconstruction life cycle to explicitly show the full delivery lifecycle from the beginning of a project to the release of thesolution into production (or the marketplace). ✓ Explicit phases: The DAD life cycle is organized intothree distinct phases. See the section “Understanding theDAD Life Cycle” for more information on these phases. ✓ Context: The DAD life cycle indicates that pre-projectactivities as well as post-project activities occur.See Figure 5-2 for the advanced DAD life cycle based on Kanban.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition36DailyWorkDailyCoordinationMeetingIterationreview&retrospective:Demotostakeholders,determinestrategyfornextiteration,andlearnfromyourexperiencesInitialArchitecturalVisionHighestPriorityWorkItemsIdentify,prioritize,andselectprojectsInitialvisionandfundingInitialmodeling,planning,andorganizationInitialRequirementsandReleasePlanWorkingSystemWorkingSolutionEnhancementRequestsandDefectReportsReleasesolutionintoproductionOperateandsupportsolutioninproductionIterationBacklogTasksWorkItemsOneormoreshortiterationsInceptionStakeholderconsensusProvenarchitectureFundingFeedbackConstructionSufficientfunctionalityTransitionOneormoreshortiterationsProductionreadyDelightedstakeholdersProjectviability(several)ManyshortiterationsproducingapotentiallyconsumablesolutioneachiterationIterationplanningsessiontoselectworkitemsandidentifyworktasksforcurrentiterationIterationFigure 5-1: The basic DAD life cycle.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5: Using Disciplined Agile Delivery (DAD) 37Identify,prioritize,andselectprojectsInitialmodeling,planning,andorganizationInitialArchitecturalVisionNewfeaturesStandardReplenishmentmodelingsessionWorkitemsarepulledwhencapacityisavailabletoaddressthemNewfeaturesDemoFeedbackDailyworkLearningsRetrospectiveStrategyReleasesolutionintoproductionOperateandsupportsolutioninproductionCoordinationMeetingEnhancementRequestsandDefectReportsFixedDeliveryDateExpediteInceptionConstructionTransitionStakeholderconsensusContinuousstreamofdevelopmentSufficientfunctionalityProductionreadyDelightedstakeholdersIntangibleOptionsInitialvisionandfundingInitialRequirementsFigure 5-2: The advanced DAD life cycle.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition38Goal drivenThe DAD process framework strives to meet goals in eachphase (Inception, Construction, Transition). For example,goals during the inception phase include understanding theinitial scope, identifying a technical strategy, performing initialrelease planning, and initiating the team. Each goal then hasdifferent issues to be addressed. Instead of prescribing a single approach, DAD describes thegoals you need to address, potential strategies for doing so,and the trade-offs that you face. It also suggests some gooddefault options to help get you started.Risk and value drivenThe DAD process framework adopts what is called a risk-valuelife cycle; effectively, this is a lightweight version of the strategypromoted by the UP. DAD teams strive to address commonproject risks, such as coming to stakeholder consensus aroundthe vision and proving the architecture, early in the life cycle.DAD also includes explicit checks for continued project viability,whether sufficient functionality has been produced, and whetherthe solution is production ready. It is also value-driven, in thatDAD teams produce potentially consumable solutions regularly.Enterprise awareDAD teams work within your organization’s enterpriseecosystem, as do other teams, and explicitly try to takeadvantage of the opportunities presented to them. Disciplinedagilists act locally and think globally.These teams work closely with the following teams andindividuals:These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5: Using Disciplined Agile Delivery (DAD) 39 ✓ Enterprise technical architects and reuse engineers toleverage and enhance the existing and “to be” technicalinfrastructure ✓ Enterprise business architects and portfolio managers tofit into the overall business ecosystem ✓ Senior managers who govern the various teamsappropriately ✓ Data administrators to access and improve existing datasources ✓ IT development support people to understand and followenterprise IT guidance (such as coding, user interface,security, and data conventions) ✓ Operations and support staff to understand their needsto ensure a successful deployment (one part of DAD’soverall support for Development and Operations) With the exception of start-up companies, agile delivery teamsdon’t work in a vacuum. There are often existing systemscurrently in production, and minimally your solutionshouldn’t impact them although your solution should leverageexisting functionality and data available in production.Understanding the DAD Life CycleThe ongoing goals of DAD include the following: ✓ Fulfill the project mission ✓ Grow team members’ skills ✓ Enhance existing infrastructure ✓ Improve team process and environment ✓ Leverage existing infrastructureThe DAD life cycle has three phases.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition40InceptionThe first phase of DAD is inception. Before going full-speedahead, this phase takes typically between a few days and afew weeks to initiate the project. The inception phase endswhen the team has developed a vision for the release that thestakeholders agree to and has obtained support for the rest ofthe project (or at least the next stage of it).ConstructionThe construction phase in DAD is the period of time when therequired functionality is built. The timeline is split up into anumber of time-boxed iterations. The time-boxed iterationsshould be the same duration for a given project — typicallyone to four weeks, with two and four weeks being the mostcommon — and typically don’t overlap. At the end of eachiteration, demonstrable increments of a potentially consumablesolution have been produced and regression tested.The construction phase ends where there’s sufficientfunctionality to justify the cost of transition — sometimesreferred to as minimally marketable release (MMR) — andwhich the stakeholders believe is acceptable to them.TransitionThe transition phase focuses on delivering the solution intoproduction (or into the marketplace in the case of a consumerproduct). The time and effort spent transitioning varies fromproject to project. This phase ends when the solution isreleased into production.For more information on this topic, see Disciplined Agile Delivery:A Practitioner’s Guide to Agile Software Delivery in the Enterprise,by Scott W. Ambler and Mark Lines (IBM Press, 2012).These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 6ScalingAgilePracticesIn This Chapter▶ Seeing how agile can scale▶ Incorporating additional roles on large teamsAgile approaches have been adapted to work in a widerange of situations, not just the small, collocated teamenvironments that dominate the early agile literature. Agilestrategies are being applied throughout the entire softwaredelivery life cycle, not just construction, and very often invery complex environments that require far more than asmall, collocated team.Every project team finds itself in a unique situation, with itsown goals, its abilities, and challenges to overcome. Whatthey have in common is the need to adopt and then tailoragile methods, practices, and tools to address those uniquesituations.Understanding WhatIt Means to ScaleIn the early days of agile, projects managed via agiledevelopment techniques were small in scope and relativelystraightforward. The small, collocated team strategies ofmainstream agile processes still get the job done in thesesituations. Today, the picture has changed significantly andorganizations want to apply agile development to a broaderset of projects.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition42Organizations often deal with problems that require largeteams; they want to leverage a distributed workforce; theywant to partner with other organizations; they need to complywith regulations and industry standards; they have significanttechnical or cultural environmental issues to overcome; andthey want to go beyond the single-system mindset and trulyconsider cross-system enterprise issues effectively. Not every project team faces all these scaling factors or eachscaling factor to the same extent, but all these issues addcomplexity to your situation, and you must find strategies toovercome these challenges.To deal with the many business, organization, and technicalcomplexities your development organization faces, yourdisciplined agile delivery process needs to adapt, or scale.The following sections describe the factors most organizationsencounter when scaling their agile projects.Large teamsMainstream agile processes work very well for smaller teamsof 10 to 15 people, but what if the team is much larger? Whatif it’s 50 people? 100 people? 1,000 people? As your team-sizegrows, the communication risks increase and coordinationbecomes more difficult. As a result paper-based, face-to-facestrategies start to fall apart.Distributed teamsWhat happens when the team is distributed — perhaps onfloors within the same building, different locations within thesame city, or even in different countries? What happens if youallow some of your engineers to work from home? Whathappens when you have team members in different timezones? Suddenly, effective collaboration becomes morechallenging and disconnects are more likely to occur.ComplianceWhat if regulatory issues — such as Sarbanes Oxley, ISO 9000,or FDA CFR 21 — are applicable? This may mean that the teamhas to increase the formality of the work that it does and theartifacts that it creates.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 6: Scaling Agile Practices 43Domain complexitySome project teams find themselves addressing a verystraightforward problem, such as developing a data entryapplication or an informational website. Sometimes theproblem domain is more intricate, such as the need to monitor abio-chemical process or air traffic control. Or perhaps thesituation is changing quickly, such as financial derivativestrading or electronic security assurance. More complexdomains require greater emphasis on exploration andexperimentation, including — but not limited to — prototyping,modeling, and simulation.Organization distributionSometimes a project team includes members from differentdivisions, different partner companies, or from external servicesfirms. The more organizationally distributed teams are, themore likely the relationship will be contractual in natureinstead of collaborative. A lack of organizational cohesion can greatly increase risk toyour project due to lack of trust, which may reduce willingnessto collaborate and may even increase the risks associatedwith ownership of intellectual property (IP).Technical complexitySome applications are more complex than others. Sometimesyou’re working with existing legacy systems and legacy datasources that are less than perfect. Other times, you’re buildinga system running on several platforms or by using severaldifferent technologies. And at different times the nature of theproblem your team is trying to solve is very complex in itsown right, requiring a complex solution.Organizational complexityYour existing organization structure and culture may reflectwaterfall values, increasing the complexity of adopting andscaling agile strategies within your organization. Or some groupswithin your organization may wish to follow strategies that aren’tperfectly compatible with the way yours wants to work.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition44Enterprise disciplineMost organizations want to leverage common infrastructureplatforms to lower cost, reduce time to market, improveconsistency, and promote a sustainable pace. This can bevery difficult if your project teams focus only on theirimmediate needs. To leverage common infrastructure, project teams need totake advantage of effective enterprise architecture, enterprisebusiness modeling, strategic reuse, and portfolio managementdisciplines. These disciplines must work in concert with, andbetter yet enhance, your disciplined agile delivery processes.But this doesn’t come free.Your agile development teams need to include as stakeholdersEnterprise Architecture professionals — such as enterpriseand solution architects and reuse engineers — if notdevelopment team members in their own right. The enterpriseprofessionals also need to learn to work in an agile manner,a manner that may be very different compared to theway that they work with more traditional teams. For moreinformation on this topic, visit http://bit.ly/79mLoJ.Organizing Large TeamsWhen a disciplined agile team consists of 30 or more people,it’s considered large. A large team is divided into subteams(see Figure 6-1). Large teams add explicit roles required forcoordination, particularly those within the leadership team.These roles for coordination are sometimes referred to asthe coordination team. Large teams sometimes incorporate anintegrator, but this is an optional role and not always used.The leadership team is typically headed up by someone in therole of program manager, sometimes referred to as a projectmanager, who’s responsible for overall team coordination. AsFigure 6-1 indicates, the leadership team consists of the peoplein senior roles on the individual subteams. Together, thesepeople address the following aspects of team collaboration:These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 6: Scaling Agile Practices 45ProgramManagerProductOwnerTeamLeaderTeamMemberSpecialist(s)TechnicalExpert(s)Integrator(s)ArchitectureOwnerProject ManagementTeamProjectOwner TeamArchitectureOwner TeamProducesProducesFeature/ComponentConsumable SolutionLeadership TeamDAD SubteamSupporting CastDomainExpert(s)IndependentTestersFigure 6-1: The structure of a large DAD team. ✓ Project management coordination: The individual teamleads are each part of the project management team.They’re responsible for coordinating fundamentalmanagement issues, such as schedule dependencies,staffing, conflicts between subteams, and overall costand schedule tracking. The program manager typicallyheads up the project management team. ✓ Requirements coordination: Because there aredependencies between requirements and betweenwork items in general, product owners must coordinaterequirements and work items across subteams, includingensuring that the same requirement isn’t being workedon unknowingly by two or more subteams and that thepriorities of each subteam are consistent.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition46 If requirement dependencies aren’t coordinated acrosssubteams, producing a consumable solution for eachiteration becomes nearly impossible, and the developmentprocess can fall apart. The Chief Product Owner leadsthe team of product owners in this effort. ✓ Technical coordination: Technical dependencies, suchas the need to invoke services or functions provided byanother part of the solution, exist between each subsystem/component or feature. This requires the appropriatesubteams to coordinate with one another — work that’stypically initiated by the architecture owners on eachsubteam but often involves other team members asneeded. Another aspect of technical coordination is regularintegration of the overall system. Very large or complexteams have one or more people in the role of integrator —while the architecture owner is responsible for integrationwithin their subteam, the integrator(s) is responsible forsolution integration and coordinates accordingly withthe architecture owners and other team members of thesubteams.The leadership subteams (project management, productowners, architecture owners) coordinate any issues via teamcoordination meetings and electronic means as needed. Manyteams discover that these coordination issues have differentcadences. For example, requirements and technical coordina-tion occur daily at the beginning of an iteration but diminishlater in the iteration, but project management coordination isneeded daily throughout the iteration.A greater need exists for shared models, documentation, andplans, particularly if the team is geographically dispersed.Use of integrated tooling that’s instrumented to provide keymeasures, which in turn are displayed on project dashboards,can provide greater visibility of what is happening within theteam and thereby aid coordination.For more information on this topic, see Disciplined Agile Delivery:A Practitioner’s Guide to Agile Software Delivery in the Enterprise,by Scott W. Ambler and Mark Lines (IBM Press, 2012).These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 7EvaluatingAgileToolsIn This Chapter▶ Knowing the key criteria for selecting agile tools▶ Recognizing the value of an open platform solution▶ Managing your agile process with Rational Team ConcertTo support and automate the agile process into yourorganization, you can consider incorporating tools thatfacilitate a streamlined process for your agile teams. Thischapter helps you make smart decisions when consideringsoftware purchases that serve your agile development needs.Considering Key Criteriafor Selecting Agile ToolsEach team approaches agile in a different way. Some teamsstart small, adopting Scrum and simple approaches usingopen source tools, while others require more extensive agilelife cycle management solutions. Regardless of where theyattain them, most agile teams make use of specific agile toolsthat help them get the most from their agile process.Before you decide to use a new tool, determine whether it’sthe best tool for your needs. The easiest way to do this is tokeep these seven key criteria in mind as you make yourselection: ✓ Core agile capabilities: First and foremost, the agiletool must support people over process by facilitatingcollaboration, planning, and productivity among the agileteam, product owners, and other stakeholders.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition48 ✓ Integrated and open agile delivery: The agile tool mustallow you to protect investments in existing tooling andminimize tool maintenance with simplified integrations. ✓ Team collaboration in context: The ability for teammembers, customers, managers and stakeholders towork together in context of the task at hand allows theteam to focus on delivering working software. ✓ Life cycle traceability: The ability to understand howyour actions affect others, to find gaps in test coverage,and be aware of defects that are blocking progresshelp your team identify and mitigate potential risks andreduce friction across the agile delivery life cycle. ✓ Agile development analytics: Arming managers and agileteam members with real-time metrics to make informeddecisions helps reduce friction and accelerate thevelocity of agile teams. ✓ Adaptability and flexibility: Your tool should supportyour team regardless of its process or size. Look foradaptable process support that evolves as your needschange. ✓ Agility at scale: As your organization grows, it mostlikely needs a well-defined agile scaling process, teamstructure, and tooling to address real-world complexities,such as those faced by distributed teams or teamsaddressing compliance requirements. The right tools can help you succeed, regardless of your entrypoint. Your challenge is to identify your greatest need today,the improvements you need to make to current practices, andwhether new tools are really the solution.For more information on evaluating agile tools, visit www.ibm.com/rational/agile.Exploring the Jazz InitiativeInspired by the artists who transformed musical expression,Jazz is an initiative to transform software and systems deliveryby making it more collaborative, productive, and transparentthrough integration of information and tasks throughout thedelivery life cycle. The Jazz initiative consists of three elements:These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 7: Evaluating Agile Tools 49 ✓ Platform: The Jazz platform is an open and flexibleplatform, which allows for greater integration capability. ✓ Products: In keeping with agile principles, Jazz productsare designed to put the team first. ✓ Community: The Jazz community site is the livedevelopment infrastructure for the Jazz technology andproducts.Using the Best Tool for the JobThe ideal agile tool addresses project planning, work itemtracking, source code management, continuous builds, andadaptive process support, enabling agile project teams andstakeholders to work together effectively.IBM Rational Team Concert (RTC) is built on the Jazz platformand provides all these features in one integrated tool to helpthe project team collaboratively plan, execute, and deliverworking applications. The following sections describe thekey capabilities RTC offers to support agile teams. For moreinformation on RTC features, visit https://jazz.net/projects/rational-team-concert/features. RTC provides core capabilities, including source code manage-ment optimized for distributed teams; continuous integra-tion supporting personal, team, and integration builds; andcustomizable work item tracking to support agile and formalteams.Process awareness andcustomizabilityRegardless of the size or maturity of your agile team, youragile tooling should give you the ability to deploy, customize,enact, and improve agile processes. RTC can improve theproductivity of your teams and the quality of the work theyproduce by allowing each team to teach the tool its bestpractices. RTC uses this knowledge to automate team processes,allowing team members to focus on building great software.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition50Team awarenessYour agile tooling should make collaboration easier acrossall stages of the life cycle. All team members, includingstakeholders, should have access to real-time, role-relevantinformation with full traceability to related tasks, as well asthe ability to easily make contributions to projects.RTC knows your project teams, their internal organization,and the artifacts they are working on. It greatly simplifies theaccess to team-related information or performing team-relatedoperations. In addition, RTC integrates with Lotus Sametime,GoogleTalk, and Skype, which help enhance collaborationwhen teams are geographically distributed.PlanningAgile planning is all about keeping everyone on the same pageand marching to the same beat. RTC provides capabilitiesto create product, release, and iteration plans for teams; tocreate individual plans for developers; to track the progressduring an iteration; and to balance the workload of developers.In addition, RTC provides planning views to support differentagile approaches including Taskboards for daily standups andKanban to manage flow (see Figure 7-1). RTC also providescross-project plans that allow tracking of work items thathave dependencies on other work items in other projects.Figure 7-1: The Taskboard planning view.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 7: Evaluating Agile Tools 51 Regardless of the process used, plans are accessible toeveryone on the team via the web, Eclipse, or Visual Studio.All plans change dynamically over the course of the project toreflect the team’s position and direction.Transparency/project healthTransparency and the ability to monitor status in real-time isvital to a successful agile project. Team members should havevisibility to potential issues that could impede their progress,and managers need to have real-time information to proactivelymanage risks.The RTC dashboards and reports help all team memberskeep tabs on the health of their projects. The Web Dashboard(Figure 7-2) provides a personalized view of plan status, workitems, event feeds, reports, and other items that are critical tounderstanding your progress. Reports provide both real-timeviews and historical trends of velocity, builds, streams, workitems, and other artifacts that your team works with. Inaddition, RTC supports the use of OpenSocial Gadgets andIBM iWidgets to extend visibility to other commercial andopen source life cycle tools.Figure 7-2: Web Dashboard.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition52Broad Platform SupportThe trend toward more interconnected mobile and cloud sys-tems is leading to an increasing number of cross technologydevelopment projects that are deployed on multiple targetplatforms. RTC provides the ability to centrally manage, develop,and track multi-platform projects, providing visibility to allteam members and stakeholders. RTC supports populardevelopment platforms, including Windows, Linux, IBMSystem z, IBM Power, and Solaris. RTC not only provides cross platform support but alsoprovides integrated development environments (IDE) forEclipse and Microsoft Visual Studio that allow developersto collaborate across teams, track projects, manage sourcecode, resolve defects, and execute builds.Extending tooling beyondcore agile developmentWhile RTC serves as the core agile development tool, IBMRational also provides depth and breadth of tools that alloworganizations to adapt and automate beyond developmentacross the entire life cycle. Depending on which scalingfactors apply (see Chapter 6), organizations can extend RTCwith a vast portfolio of capabilities including: more vigorousrequirements envisioning and management, test management,deployment automation, architecture and asset management,and business collaboration.In addition, leveraging the Jazz platform RTC can be integratedwith popular open source tools, including Subversion, Git,CVS, Maven, Hudson, and Jenkins. For a complete list of inte-grations see www.jazz.net/projects/rational-team-concert/integrations.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 8MakingtheMovetoAgile:IBM’sStoryIn This Chapter▶ Empowering development teams▶ Creating processes to work with distributed teams▶ Tooling up for success▶ Seeing the benefits of using agileIn 2006, IBM faced a unique challenge. In a period of aboutfive years, the company made 70 software acquisitionswith 90 major labs and employed a variety of people whoworked remotely. This feat translated to approximately 27,000people working over five continents. And, yet, IBM struggledin the software development area.In the IBM Rational organization, for example, IBM onlydelivered software on time 47 percent of the time. The costof poor quality was high. The company released productswith defects or delayed releases until defects were fixed. As aresult, products that were supposed to be high-flyers actuallycrash-landed because the cost of fixing defects was so high.IBM also used tools that didn’t integrate with each other.IBM needed to be more agile. The success of IBM’s agileadoption depended on significant changes in three key areas:the people, the adopted processes, and the implementedtools for success.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition54Setting Teams Up for SuccessAgile requires empowering people to make the significantchange in how software is developed. IBM made adjustmentswith the areas covered in this section.TrainingIBM helped the software teams change by setting up a centerof excellence, holding a two-day disciplined agile workshopthat trained approximately 9,000 people over a period of twoyears, and running additional focused workshops for in-depthtraining on practices that included a collaborative leadershipworkshop. IBM identified key resource dependencies (eitherpeople or technology) and made them available to the teamswhen they needed help adopting agile.Collaboration capabilitiesAlthough studies show that face-to-face collaboration is bestfor agile development, in IBM’s case, it wasn’t always possible.So the company deployed tools, such as IBM Rational TeamConcert (see Chapter 7 for more info), that could bring largeteams together. This included support for team memberssharing immediate office space or sitting on the other side ofthe globe. These tools informed individual users, teams, andteams of teams about project changes as they happened.IBM also enabled continuous planning and change management.So, if a project lead and management had a conversationabout a change, everyone on the team was notified about it,the reason for it, who’s affected, and how they’re affected.These tools also have repositories so plan and work items canbe stored and used in the future by others.Changing cultureA change in culture can be a challenge for some people. In anumber of cases, particularly at the beginning, some teamsstruggled to accept or adopt agile because they were sodispersed, and their components were done in differentgeographic locations. So, IBM sent a coach who understoodThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 8: Making the Move to Agile: IBM’s Story 55agile to each location for three to six months. Having an agilepractitioner in these locations was worth the cost, becausethe rate of failure dropped.IBM also had to change the views of development at the top.The executives were used to having an initial state and planand relating them to waterfall measurements. They worked toaccept that scope changes over time and that this was a goodthing — as long as IBM kept release rates and quality levelsthe same (or better).Changing rolesTo support evolving culture to a more agile strategy, IBM usedautomation to support new habits and get rid of old ones.For example, traditional project managers used to canvasindividuals about progress, but by the time they could enterthe notes into a spreadsheet, the team had moved to the nextactivity. Now, tools track progress and agile team leads focuson how people work with each other. At the same time, theteam leads refocused on leadership activities over technicalmanagement activities, thereby adding greater value to theirteams and to IBM as a whole.Team structureBecause IBM’s complex products vary from testing tools tocompilers to database management systems to applicationservers and more, it needed to have more than one type ofteam. So, IBM created teams, depending on the types ofcapabilities it was looking for, via the following strategies: ✓ Feature teams: Responsible for a complete customerfeature (products and components). The goal was tooptimize customer value. Feature teams minimizedependencies, use iterative development, and trackdependencies between adoptions with an adoption tool. ✓ Component teams: Responsible for only part of acustomer feature. The development is more sequentialand dependencies between teams lead to additionalplanning. They track execution in plan items — either inwork areas or work items.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition56 ✓ Internal open source: When a component needs toevolve quickly yet is needed by multiple developmentteams, IBM uses open source strategies as an effectivedevelopment method. IBM has deep experience in opensource development, so this was an easy team structureto adopt.Updating Processes forDistributed TeamsAfter agile was implemented in a number of developmentteams, some teams were successful, but many more teamshad trouble. The teams with the most success were housed ina single location and collaborative. The teams that struggledwere globally distributed with hundreds of people. IBM realizedthat it had to change some processes to make agile workbetter in these distributed teams.A big change was in IBM’s auditable process, which, in 2006,was to “ask for forgiveness” if quality, scope, resources, andtime to market changed. This process took a great deal oftime and effort, so IBM approached scope differently, whilestill locking in the other pieces of the project, by dividing itinto two types: ✓ Release-defining scope: Usually consumes about 70percent of the schedule, which is all the things that willcause the project to slip if problems arise. ✓ Extended content: Consists of things that won’t causeproblems if they aren’t shipped.IBM is now better at delivering what’s release defining and,and in almost all cases, additional content that its customersand sales force don’t know about in advance. This improvementreduced time and effort spent asking for forgiveness. Also,IBM teams have a clearer picture of what’s important andwhat’s optionally important.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 8: Making the Move to Agile: IBM’s Story 57Other changes IBM made to its processes are as follows: ✓ Work with stakeholders every iteration for timely andeffective feedback ✓ Organize its agile methodology into smaller, consumablepractices that can be adopted easily ✓ Make all parts of the production process agile, not justdevelopment The goal was to make it difficult to go back to oldwaterfall ways, and the process has been successful. ✓ Adopt a robust planning strategy Each activity, whether it was going on vacation orwriting code or testing, is a work item that’s estimatedand prioritized.Working with New ToolsBecause IBM is a large organization, it has to be intentionalabout the way it communicates and collaborates. IBMdetermined that tooling was necessary to provide a way forteams to exchange information and stay on the same page —much like smaller teams do. The key to collaboration is that teams want a way tocollaborate and exchange information in a way that feelsnatural. Posting a bunch of information to a wiki won’t getpeople to pay attention. Exchanging information has to feelnatural to and fit into the context of the teams’ work.IBM instituted technology that unified people beyond justthe development team, including documentation, training,translation, and release management. Everyone could see thestatus on complementary work activities that took place. Thisinnovation created better visibility to overall team progress.When you have a transparent view of the work items thatare complete, the items that still need to be done, and teamvisibility into how certain tasks are taking more effort thanoriginally scoped, they help the team get better at agileplanning and drive conversations about whether the teamneeds to realign resources to stay on track.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition58Reaping the Benefits of AgileIBM’s agile transformation took some adjustments. The companymade some mistakes along the way, sure, but it learned fromthem and has now experienced extensive improvements in qual-ity, time-to-market, and customer satisfaction. IBM is proof thatthe rewards of agile adoption far outweigh the obstacles. IBM’s results from agile adoption include the following: ✓ A 31/69 percent ratio of maintenance to innovation (startwas 42/58 and goal was 50/50) ✓ Customer touches increased from 10 to 400 ✓ Customer calls decreased to 19 percent ✓ Customer defect arrivals decreased from 6,900 to 2,200 ✓ Defect backlog reduced to 3 months from 9 months or more ✓ Reduced cost of poor quality (cut almost in half)The software reuse initiativeComponent reuse is one the holygrails of software development. If youreuse code, you typically get betterquality and productivity, reduced riskof development efforts, and moreconsistency for your user experience.You can try to mandate reuse, but thatreally doesn’t work well. So instead,IBM created a site that emulated anopen source environment and calledit community sourcing. With this site,developers can create their ownprojects, share those projects withothers, gain access to the code, anddecide whether the projects meettheir needs. By using a combination ofRational Team Concert, Rational AssetManager,andLotusConnections,IBMprovided an environment conducive tocommunity and sharing.IBM now has over 30,000 developersusing the community source siteand 4,800 uses of components inits products now. For example,a component that helps IBM’sinstallation has been reused by 152products, and one component forsecurityhasbeenusedby175projects.One of the nice benefits of this type ofcommunity sourcing initiative is that itconnects people in new and excitingways. IBM has seen people reachingacross divisions and functionalboundaries because they were usinga common component. With thecommunity source site, this type ofcollaboration happens organically.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 9TenCommonAgileAdoptionPitfallsIn This Chapter▶ Knowing what mistakes to avoid▶ Creating a better agile adoption experienceThe ability to avoid common agile adoption pitfalls mayseem daunting, but there’s a light at the end of the tunnel.With over 10 years of experience helping customers manageand execute their agile transformations, we present you withthis chapter to help briefly explore some common pitfallsorganizations make when adopting agile strategies. Andhopefully, with this advice, you can skip over making thesame mistakes.Focusing Only on ConstructionYou can realize the spirit of the Agile Manifesto through manyapproaches. Ironically, most of these approaches focus onone phase or discipline within the delivery life cycle — whichgoes against the spirit of lean, which advises to consider thewhole. Most approaches focus on the construction phase.Construction is typically a straightforward area to focus onwhen taking on an agile transformation, but if organizationsonly change the way they construct software, they can’tnecessarily call themselves agile. The development teamscould be humming along, delivering new working softwareevery two weeks, but if the processes in Operations onlyallow for deployment every six months or if the Help Desk isThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition60unable to handle the churn or if customer stakeholders aren’tprepared to meet regularly, the organization isn’t realizing allthe benefits agile can provide.Becoming Agile ZombiesOrganizations fall into the trap that if they attend a class andmandate a certain out-of-the-box (OOTB) process, that theyare now agile. They train their teams to blindly follow andenforce the anointed process not considering which practicesmay need to change to meet their organizations’ unique needs. Agile isn’t a prescribed process or set of practices; it’s aphilosophy that can be supported by a practice and no twoagile approaches are the same. One OOTB methodology thatfulfills all needs doesn’t exist.Improper PlanningThat old adage, “If you fail to plan, plan to fail,” is reallytrue. Planning is core to the success of any agile adoption.Organizations should answer these questions: ✓ Why do we want to be agile, and what benefits will agileprovide? ✓ How will we achieve and measure agility? ✓ What cultural, technological or governance barriersexist, and how do we overcome them? Without a plan that clearly shapes the initiative andincludes addressing and resolving constraints to agility(for example, removing waterfall process checkpoints orgetting support from other required entities), it is moredifficult to shape the initiative, staff it, fund it, manageblockers and maintain continued executive sponsorship.Excluding the Entire OrganizationYou can quickly short circuit an agile adoption by working inthe vacuum of a single software or system delivery team. Asingle team can gain some benefit from agile, but to be trulyThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 9: Ten Common Agile Adoption Pitfalls 61successful, you need to look at the whole process aroundsolution delivery. And many people are involved in that process. Agile should be a change in culture for the entire organization.Find champions in Operations, lines of business, productmanagement, Marketing, and other functional areas toincrease your success.Lack of Executive SupportAn effective agile adoption requires executive sponsorship atthe highest level. This involvement means more than showingup at a kickoff meeting to say a few words. Without executivesponsorship supporting the overall initiative, the agile adoptionis often doomed because agile initiatives require an upfrontinvestment of resources and funding — two areas thatexecutives typically control.Going Too FastMoving to agile is very exciting, and it can be tempting tojump right in, pick a process, get some tools, and hit theground running. Unfortunately, if a proper roadmap forcoaching, process, and tooling isn’t outlined early in theadoption you can run into issues like the following: ✓ No defined processes for dealing with multiple dependentor distributed teams ✓ Scalability issues with the core agile tools ✓ Extending the tool to support deployment, testing, orbusiness collaborationInsufficient CoachingBecause an agile adoption isn’t just a matter of a new deliveryprocess, but is also major cultural shift, coaching is imperative.Developers don’t like change and many people like working intheir own world. As a result, the concept of not only changingthe way they develop, but adding the concept that now theyhave to work closely with five, six, or ten other people all thetime can be downright horrifying.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition62A coach can work with these team members and help themthrough the early phases of agile adoption. Have you knownof a teacher or coach that possessed a unique ability toinspire students to stretch their skills and perform at higherlevels? Good agile coaching can have the same affect andmake the difference between the success and failure of anagile adoption.Retaining Traditional GovernanceWhen an organization plans its agile adoption, it needs toevaluate all current processes and procedures and whetherthey inhibit or enhance agility. Existing traditional governanceprocesses can be very difficult to change due to internalpolitics, company history, or fear that compliance mandatesmay be negatively impacted. Some common governance areasthat are overlooked but can have dramatic impacts to agilityare project funding, change control, and phase gates.Skimping on TrainingOrganizations often see agile practice training, like coaching,as an area where they can save money, sending only a few keyleads to learn the new process in hopes that they can trainthe rest of the organization while trying to implement the newapproach. Agile involves a change in behavior and process. Itis critical to send all team members to the appropriate trainingand provide them with ongoing training to reinforce agilevalues and update team members on processes that mayhave changed.Skimping on ToolingAgile tooling should support and automate an organization’sprocess. Ensuring all team members consistently usetools impacts the success of the project. If tools are usedinconsistently, metrics may not correctly reflect the correctstatus, builds could be run incorrectly, and overall flow andquality issues result. See Chapter 7 for more information onagile tools.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 10TenMythsaboutAgileIn This Chapter▶ Sorting agile facts from the fiction▶ Understanding how agile can work for youAlthough agile is an established development approach,it represents a new way of life for the organizations thatadopt it. The prospect of working in iterations instead of witha linear approach is unsettling to managers and developerswho are deciding whether to make the leap to agile. They fearthat focused efforts will be compromised and that control overprojects and development teams will be sacrificed. Nothing isfurther from the truth.This chapter debunks these myths and others to show thatagile is most organizations’ best bet for success.Agile Is a FadThe agile approach to project management is far from a fad.Agile has been in use for many decades even though it wasonly recently formalized with the Agile Manifesto and itsassociated principles. Agile exists because it works. Comparedwith traditional project management approaches, agile isbetter at producing successful projects.Agile Isn’t DisciplinedSometimes agile can seem chaotic because it’s a very collabora-tive process. Agile is a departure from the rigid assembly-lineprocess. The iterative approach requires rapid response timesand flexibility from the team. In fact, agile demands greaterThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition64discipline than what’s typical of traditional teams. Agilerequires teams to reduce the feedback cycle on many activities,incrementally deliver a consumable solution, work closely withstakeholders throughout the life cycle, and adopt individualpractices which require discipline in their own right.Agile Means “We Don’t Plan”With agile’s reliance on collaboration instead of big documents,it may seem like no planning occurs. But in reality, the planningis incremental and evolutionary, which has been proven suc-cessful (instead of planning all at once early in a project).Agile Means “No Documentation”Agile teams keep documentation as lightweight as possible,but they do document their solutions as they go. They followstrategies, such as documenting continuously and writingexecutable specifications.Agile Is Only Effectivefor Collocated TeamsSure, ideally agile teams are located within proximity of oneanother, but in this day and age, most development teams aredistributed. Just remember, to succeed, you need to adoptpractices and tooling that build team cohesion. If you use theproper tools, your team doesn’t have to be collocated to workeffectively together.Agile Doesn’t ScaleAgile definitely scales. Large teams must be organized dif-ferently. They need more than index cards and whiteboardsketches. Large agile teams succeed by using products likethe following: ✓ IBM Rational Requirements Composer for requirementsmodelingThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 10: Ten Myths about Agile 65 ✓ IBM Rational Build Forge for large-scale continuousintegration ✓ IBM Rational Quality Manager to support parallelindependent testing IBM is one of the world’s largest agile adoption projects,transforming teams ranging in size from 5 to 600 teammembers. For more information on agility at scale, visitibm.com/rational/talks.Agile Is Unsuitable forRegulated EnvironmentsRegulated environments are those that are subject to someregulatory mandates, such as medical device companies,business in the finance area, governmental departments andoffices, the healthcare field, and more. These organizationsare audited from time to time for compliance with regulations.With agile, these organizations can feel confident when theyendure these audits. They benefit from faster delivery of dataand higher quality of their output.Agile Means We Don’t KnowWhat Will Be DeliveredBecause agile is an iterative process, it provides the opportunitynot just for greater control but better control over building theright things in the life cycle than one would have with the moretraditional Waterfall approaches. At the end of each iteration, thedevelopment team presents a completed product to the productowner for feedback. Furthermore, Disciplined Agile Delivery(DAD) teams explicitly explore high-level requirements at thebeginning of the project and seek to gain stakeholder agreementaround the requirements. See Chapter 5 for more details.Agile Won’t Work at My CompanyFor many companies, the biggest challenge they face whenconsidering changing to agile is the cultural change makingThese materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.
Agile For Dummies, IBM Limited Edition66the change requires. Agile has explicit means of frequentfeedback and loops, which means that developers and managersmay feel more exposed to scrutiny. But that doesn’t mean thatagile won’t work at your company.Agile is a team approach. It’s not like football where oneplayer at a time moves the ball down the field to score atouchdown. Agile is more like rugby — the whole team movesthe ball down the field together. Roles are cross-functionaland shared. Developers become testers and more frequentdelivery creates more exposure and personal accountability. For an organization to successfully adopt agile, executivesupport is also critical. Agile can succeed without it, but if youhit a bump in the road, you’ll want that vote of confidence tohelp you keep everything moving in the right direction.It’s Enough for My DevelopmentTeam to Be AgileFor agile to work properly, all teams have to buy in. So if yourdevelopment team is gung ho, but your testing team is blasé,you won’t get your best results. Your agile delivery process isonly going to be as effective as your slowest group. To makeagile succeed at its greatest potential, make each piece of thechain as efficient as possible.Agile Is a Silver BulletAgile isn’t needed for every team in every situation. It isn’ta cure-all. Agile is a superb solution for projects that are indevelopment or undergoing radical changes. For other projects,such as those that are in maintenance mode, agile isn’t asgood a fit. If your project has a stable customer base and isn’tundergoing a lot of change in the code, you may not need touse agile for that particular project. But for projects that areunder new product or rapid development, agile really is thebest way to go.These materials are the copyright of John Wiley & Sons, Inc. and anydissemination, distribution, or unauthorized use is strictly prohibited.