7.
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 info@dummies.biz. 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.

8.
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.

9.
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.

10.
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.

11.
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.

12.
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.

13.
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.

14.
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.

15.
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.

16.
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.

17.
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.

18.
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.

19.
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.

20.
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.

21.
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.

22.
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.

23.
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.

24.
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.

25.
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.

26.
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.

27.
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.

28.
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.

29.
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.

30.
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.

31.
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.

32.
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.

33.
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.

34.
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.

35.
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.

36.
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.

37.
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.

38.
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.

39.
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.

40.
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.

41.
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.

42.
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.

43.
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.

44.
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.

45.
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.

46.
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.

47.
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.

48.
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.

49.
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.

50.
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.

51.
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.

52.
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.

53.
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.