IBM Agile for Dummies

Trusted by over 1 million members

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.

































Ag A gile FOR

DUMmIES

‰

IBM LIMITED EDITION

by Scott W. Ambler and Matthew Holitza

















Agile For Dummies®, IBM Limited Edition Published by John Wiley & Sons, Inc. 111 River Street Hoboken, NJ 07030-5774 www.wiley.com www.wiley.com

Copyright © 2012 by John Wiley & Sons, Inc., Hoboken, NJ Published by John Wiley & Sons, Inc., Hoboken, NJ No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wile y & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/ http://www.wiley.com/go/permissions permissions. Trademarks: Wiley, Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. IBM and the IBM logo are registered trademarks of IBM. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book. LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ. For general information on our other products and services, please contact our Business Development Department in the U.S. at 317-572-3205. For details on how to create a custom For Dummies book for your business or organization, contact [email protected] . For information about licensing the For Dummies brand for products or services, contact [email protected] . ISBN: 978-1-118-30506-5 (pbk) ISBN: 978-1-118-30554-6 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1

















Table of Contents Introduction ......................................1 About This Book ................................................. .................................................................. ....................... ...... 1 Foolish Assumptions Assumptions ............................................... ................................................................ ................... 1 Icons Used in This Book.................................. ................................................... .......................... ......... 2

Chapter 1: 1: Getti tting the ABCs of Agile . . . . . . . . . . . . . . . . .3 Looking Back at Software Development Approaches ........... ........... 3 Code-and-Fix/Big Code-and-Fix/Big Bang development development ............................ ............................ 4 Waterfall...................................... ....................................................... .................................. ..................... .... 4 The Spiral model................................. .................................................. ............................. ............ 5 Introducing the Agile Manifesto Manifesto ................................ .............................................. ............... 7 The Manifesto.................. Manifesto................................... .................................. ................................ ............... 7 The 12 principles that drive the Agile Manifesto ........ 9 Redefining Today’s Agile.................................. .................................................... ...................... .... 10 Growing popularity.................... popularity..................................... .................................. ................... .. 10 Growing scalability .................................. .................................................... ...................... .... 10

Chapter 2: 2: Understanding Agile Roles . . . . . . . . . . . . . .11 .11 Being a Stakeholder Stakeholder ................................... .................................................... .............................. ............. 11 Representing Representing Stakeholders: The Product Owner ................ 12 Being a Team Member.................................. ................................................... ........................... .......... 13 Assuming the Team Lead.................................. .................................................... ...................... .... 13 Acting As the Architecture Owner .................................. ......................................... ....... 13 Stepping Up As an Agile Mentor ............................................ ............................................ 14 Looking at Agile Secondary Roles ................................... .......................................... ....... 14

Chapter 3: 3: Getti tting Starte rted with Agile . . . . . . . . . . . . . . .15 .15 Agile Planning ......................... .......................................... .................................. ................................. ................ 15 Attending the Daily Coordination Meeting ........................... ........................... 16 Creating User Stories................................. .................................................. .............................. ............. 16 Estimating Your Work .................................. ................................................... ........................... .......... 18 Tracking Velocity .............................. ................................................ ................................... ..................... .... 19 Measuring Progress with Burndown Reports ...................... ...................... 20 Test-Driven Development Development ................................. ................................................... ...................... .... 21 Continuous Integration and Deployment 22

















iv

Agile For Dummies, IBM Limited Edition

Chapter 4: 4: Choosing an Agile Approach . . . . . . . . . . . . .25 .25 SCRUM: Organizing Construction ................................... .......................................... ....... 25 XP: Putting the Customer First.................................. ............................................... ............. 26 Lean Programming: Producing JIT ................................. ........................................ ....... 27 Kanban: Improving on Existing Systems ............................... ............................... 28 Agile Modeling ..................... ...................................... .................................. ................................... .................... 28 Unified Process (UP) ................................. .................................................. .............................. ............. 30

Chapter 5: 5: Using Using Disc Discipl iplined ined Agile Agile Deliv Delivery ery (DAD) (DAD) . . . 31 Understanding Understanding the Attributes of DAD ............................... ................................... .... 31 People first............................ first.............................................. ................................... ........................ ....... 32 Learning-oriented Learning-oriented .................................. ................................................... ........................ ....... 32 Agile................................................ ................................................................. ................................. ................ 33 Hybrid ................................. .................................................. .................................. ........................... .......... 33 IT solution focused .................................. .................................................... ...................... .... 34 Delivery focused .................................... ..................................................... ........................ ....... 35 Goal driven .......................................... ........................................................... ........................... .......... 3 8 Risk and value driven ................................. .................................................. ................... .. 3 8 Enterprise aware................................. .................................................. ........................... .......... 38 Understanding Understanding the DAD Life Cycle .................................... ........................................ .... 39 Inception................. Inception .................................. .................................. ................................... ...................... .... 40 Construction............................ ............................................. ................................... ...................... .... 40 Transition ................................ ................................................. ................................... ...................... .... 40

Chapter 6: 6: Scaling Agile Practices . . . . . . . . . . . . . . . . .41 .41 Understanding Understanding What It Means to Scale ................................. ................................. 41 Large teams ......................................... .......................................................... ........................... .......... 42 Distributed teams .................................. ................................................... ........................ ....... 42 Compliance....................................... ........................................................ .............................. ............. 42 Domain complexity.................................. .................................................... ...................... .... 43 Organization distribution ............... ................................ .............................. ............. 43 Technical complexity ................................. .................................................. ................... .. 43 Organizational Organizational complexity ........................................... ........................................... 43 Enterprise discipline ............................... ................................................. ...................... .... 44 Organizing Large Teams ............................................ ......................................................... ............. 44

Chapter 7: 7: Evaluating Agile Tools . . . . . . . . . . . . . . . . . . 4477 Considering Key Criteria for Selecting Agile Tools.............. 47 Exploring the Jazz Initiative................................. .................................................. ................... .. 48 Using the Best Tool for the Job ............. 49



















Table of Contents Planning ................................ .................................................. ................................... ........................ ....... 50 Transparency/project Transparency/project health ............................. ....................................... .......... 51 Broad Platform Support Support ................................ ............................................... ................ 52 Extending tooling beyond core agile development ... 52

Chapter 8: 8: Making the Move to Agile: IBM’s Story. Story. . . . 5 3 Setting Teams Up for Success .................. ................................... .............................. ............. 54 Training............................................. .............................................................. .............................. ............. 54 Collaboration capabilities .......................................... ............................................ .. 54 Changing culture................................. .................................................. ........................... .......... 54 Changing roles ................................. .................................................. .............................. ............. 55 Team structure ................................................. .............................................................. ............. 55 Updating Processes for Distributed Teams .......................... .......................... 56 Working with New Tools ................................. .................................................. ........................ ....... 57 Reaping the Benefits of Agile.................................. .................................................. ................ 58

Chapter 9: 9: Ten Ten Com Commo mon n Agi Agile le Adop Adopti tion on Pitf Pitfal alls ls . . . . . . 59 Focusing Only on Construction................... Construction.................................... ........................... .......... 59 Becoming Agile Zombies................................. .................................................. ........................ ....... 60 Improper Planning ..................................... ...................................................... .............................. ............. 60 Excluding the Entire Organization .................................. ......................................... ....... 60 Lack of Executive Support ................................... .................................................... ................... .. 61 Going Too Fast ................................................. .................................................................. ........................ ....... 61 Insufficient Insufficient Coaching ........................... ............................................ .................................. ................... .. 61 Retaining Traditional Governance .................................. ......................................... ....... 62 Skimping on Training................................. .................................................. .............................. ............. 62 Skimping on Tooling .................................. ................................................... .............................. ............. 62

Chapter 10: 10: Ten Myths about Agile . . . . . . . . . . . . . . . . . 63 63 Agile Is a Fad ................................. .................................................. .................................. ........................... .......... 63 Agile Isn’t Disciplined ................................ ................................................. .............................. ............. 63 Agile Means “We Don’t Plan” .................................. .................................................. ................ 64 Agile Means “No Documentation” Documentation”................................... .......................................... ....... 64

v



















Publisher’s Acknowledgments We’re proud of this book and of the people who worked on it. For details on how to create a custom For Dummies book for your business or organization, contact info@ dummies.biz. For details on licensing the For Dummies brand for products or services, contact [email protected] . Some of the people who helped bring this book to market include the following: Acquisitions, Editorial, and Vertical Websites

Project Editor: Carrie A. Burchfield Development Editor: Colleen Totz-Diamond

Composition Services

Senior Project Coordinator: Kristie Rees Layout and Graphics: Jennifer Creasey, Lavonne Roberts, Christin Swinford Proofreader: Jessica Kramer

Editorial Manager: Rev Mengle Senior Acquisitions Editor: Katie Feltman Business Development Representative: Sue Blessing Custom Publishing Project Specialist: Michael Sullivan

Publishing and Editorial for Technology Dummies Richard Swadley, Vice President and Executive Group Publisher Andy Cummings, Vice President and Publisher Mary Bednarek, Executive Director, Acquisitions Mary C. Corder, Editorial Director Publishing and Editorial for Consumer Dummies Kathleen Nebenhaus, Vice President and Executive Publisher Composition Services Debbie Stailey, Director of Composition Services Business Development Lisa Coleman, Director, New Market and Brand Development



















Introduction

A

gile development principles have gone from something used only by cutting-edge teams to a mainstream approach used 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 the airplanes you fly in)

✓

Legacy systems (which means systems that have been around for a while, such as mainframe)

✓

Embedded, real-time systems (such as pacemakers or life-support systems)

✓

High-compliance environments (such as healthcare, insurance, or banking)

Abou Aboutt This This Book Book Agile For For Dummie Dummiess, IBM Limited Edition. You’ve Welcome to Agile probably been hearing about agile for a long time, which isn’t surprising. If you’re not using agile methods already though, or if you’ve only been exposed to agile on small projects here and there, you may wonder how to get started with it. Can agile ever



















2

Agile For Dummies, IBM Limited Edition ✓

You may have tried out some agile practices in an ad hoc manner, and you encountered some difficulties. Don’t worry; many teams experience some missteps when first moving to agile.

✓

You’ve had some project success, and you’re looking to grow the agile practice beyond your team. You’re looking for ways to coordinate multiple teams with the same outcomes you experienced on your small team.

✓

You want to try agile, but your environment has complexities that need to be addressed. Maybe you have globally distributed teams or are subject to regulatory compliance mandates. You’re wondering if agile practices can be effective in this environment.

But, no matter who you are, this book helps explain and reinforce the successful software development practices available today. There’s great food for thought here, even if your current team or organization isn’t ready to make the agile leap just yet.

Icon Iconss Used Used in This This Book Book Sometimes, information deserves special attention. The icons in this book identify such information for you. Here’s a brief explanation for each icon so you’ll recognize them when they turn up. The Tip icon points to information that describes a special benefit of working with agile.



















Chapter 1

Getting Getting the the ABCs of Agile Agile In This This Chapter Chapter ▶ Understanding where software development has been ▶ Dissecting the Agile Manifesto ▶ Defining agile today

I

f you’re reading this book, you’ve seen software being made. Regardless of your role on the project, you know it’s not a perfect process. You know it’s hard to do well. Software development doesn’t face problems for lack of trying or for lack of brain power. People in the software business tend to be some very bright, hardworking people. They don’t plan to deliver software over budget, past deadline, and with defects (or without features people need). So what’s been at the root of all these issues?

Agile Agile is an attempt to make the process of software development better and more effective, and it’s seen increasing popularity and success. In this chapter, you discover how agile is an incremental, iterative approach to delivering high-quality software with frequent deliveries to ensure value throughout the process. It places a high value on individuals, collaboration, and the ability to respond to change.





















4

Agile For Dummies, IBM Limited Edition always tailored to suite their unique needs. Each model has its benefits and drawbacks. A model or or methodology is is just a fancy word for a process or approach to creating software, usually with specific steps or phases used to manage it. The common thinking is that it’s better to have an approach in mind than to have none at all. Agile itself is just a newer, best-of-breed collection of methodologies used to develop and maintain software.

Code-and-Fix/Big Bang devel develop opme ment nt The original approach to software development was Code-and- Fix development, where you wrote some code and then fixed things that were incorrect as you found them (or when others found them for you). Software was delivered all at once, in a “big bang” — hence the term, Big Bang — and software developers waited to find out what they may have done wrong, both in the form of outright errors and in the form of not meeting user needs or expectations. This approach is a challenging way to deliver software even on the smallest, simplest scale. As the amount of code grew





















Chapter 1: Getting the ABCs of Agile

5

This kind of sequential, stage-based approach became popular in the mid-1950s. Not until 1970 did this model become known as the Waterfall model — described as a waterfall because after finishing any one phase and moving on to the next, moving backward to make changes or corrections was very difficult (water going the wrong way up a waterfall is pretty hard). Waterfall presented a step forward from Code-and-Fix and is still used in many industries to this day. Despite wide adoption and continued use, however, the model has problems:

✓ Schedule risk: Unless the system being designed is already well understood, Waterfall has a higher-thannormal risk of not meeting schedule. Business needs may change during a long project, and developers may be asked to squeeze in “one more thing,” which can have an incremental impact on test and deployment teams. These changes in scope add up — an effect known as scope creep. ✓ Limited flexibility: The Waterfall model locks down requirements very early in the process, producing little wiggle room to add late discoveries or needed changes throughout the process. This is why scope creep (see the preceding bullet) is problematic with this model.





















6

Agile For Dummies, IBM Limited Edition ✓ An incremental approach regularly delivers working code in small chunks. ✓ An iterative approach plans on learning from feedback on the deliveries and sets aside time to use this feedback to make improvements. An incremental approach can be iterative because the small chunks result in feedback; feedback leads to changes in the chunks already delivered, and shapes future direction. This process happens much more rapidly with incremental delivery than waiting until the end of a long-release cycle. Besides, if you wait until the end of a long-release cycle, the users already have a long list of new features they need. The Spiral model, introduced in 1988, was a landmark software development methodology. It used prototyping and incremental delivery process to manage project risk. It was designed to be especially effective for systems that had a high level 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 specifications created ahead of time ran aground in the project when the problem space was better understood. The Spiral model — both incremental and iterative — delivered the final version of working software, and this archetype






















7

Intr Introd oduc ucin ingg the the Agil Agilee Mani Manife fest stoo In February of 2001, a group g roup of developers interested in advancing lightweight development methodologies got together to talk about their views and to find common ground, and agile was born. The developers who created agile understood the importance of creating a model in which each iteration in the development cycle “learned” from the previous iteration. The result was a methodology that was more flexible, efficient, and team-oriented than any of the previous models. All the agile methods look to the Agile Manifesto and 12 core principles for guidance. The adherence to the guidance provided by the manifesto and principles is what makes a software development team agile, not a specific process, tool, label.

The Manifesto The Manifesto for Agile Software Development is is a compact 68 words (now that’s lightweight!) that stresses four values.

Manifesto for Agile Software Development*





















8

Agile For Dummies, IBM Limited Edition No boxes with arrows, no swim-lane diagrams here. The Agile Manifesto is straightforward, but don’t let the brevity fool you. This is powerful stuff. The following sections break down the components of the manifesto.

Individuals Individuals and interact interactions ions over processes processes and and tools tools Recognizing that software is made by people, not processes or tools, agile places a higher premium on people working together effectively. Processes and tools can aid in that but can’t replace it.

Working software over comprehensive documentation Valuing working software over comprehensive documentation stands in stark opposition to the Waterfall model. A highly detailed, accurate, and comprehensive specification document is of no value if it doesn’t result in working software that meets users’ needs. Working software may involve documentation, but agile only uses it in service to creating working software, not as an end (almost) unto itself.

Customer collaboration over contract negotiation While agile isn’t ignoring the reality of contracts, it values active collaboration throughout the software development process as a better way to deliver value instead of a carefully worded contract. A contract is no proxy for actual communication when
























9

The 12 principles that drive the Agile Manifesto The people who wrote the Agile Manifesto later assembled 12 principles that inform and reinforce the manifesto. These further illuminate the things agile values in software development. The Agile Manifesto follows these principles: 1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of























10

Agile For Dummies, IBM Limited Edition The Agile Manifesto and the principles behind it are published at http://www.agilemanifesto.org .

Redefining Today’s Agile Since the time when the Agile Manifesto was drafted, agile has grown in popularity, and its use has been extended to increasingly larger organizations and more complex projects.

Growing popularity Agile is a widely accepted and adopted approach to software development. Hundreds of books on agile exist, covering everything from how to manage agile development to how to apply it in specific industries to how to apply it with specific programming languages. You can attend agile training courses























Chapter 2

Understanding Agile Roles In This This Chapter Chapter ▶ Discovering the primary roles on agile teams ▶ Taking a look at additional team positions

O

n a disciplined agile project, any given person can be in one or more roles, and he can also change his role(s)























12

Agile For Dummies, IBM Limited Edition ✓ Your program/portfolio manager ✓ A developer(s) working on other systems that integrate or interact with the one under development ✓ A maintenance professional(s) potentially affected by the development and/or deployment of a software project

Representing Stakeholders: The Product Owner The product The product owner is is the team member who speaks as the “one voice of the customer.” This person represents the needs and desires of the stakeholder community to the agile delivery team. He clarifies any details regarding the solution and is also responsible for maintaining a prioritized list of work items that the team will implement to deliver the solution.























Chapter 2: Understanding Agile Roles

13

Being a Team Member The role of team member focuses focuses on producing the actual solution for stakeholders. Team members perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate throughout the project. Not every team member has every single skill (at least not yet), but they have a subset of them and strive to gain more skills over time. Team members identify, estimate, sign-up for, and perform tasks and track their completion status.

Assu Assumi ming ng the the Team Team Lead Lead The team lead guides guides the team in performing management management

























14

Agile For Dummies, IBM Limited Edition You may not have to formally designate a team member as an architecture owner on small teams, because the person in the role of team lead often is the architecture owner, too.

Step Steppi ping ng Up As an Agil Agilee Ment Mentor or A mentor is a great idea for any area in which you want to develop new expertise. The agile mentor, sometimes mentor, sometimes called an agile coach, implements coach, implements agile projects and shares that experience with a project team. He provides valuable feedback feedback and

























Chapter 3

Getting Started with Agile In This This Chapter Chapter ▶ Looking at agile planning practices

























16

Agile For Dummies, IBM Limited Edition During an agile project, planning occurs at three levels:

✓ Release planning: Release planning: Release plans contain a release schedule for a specific set of features. The product owner creates a release plan at the start of each release. ✓ Iteration planning: Team planning: Team members gather at the beginning of the iteration (referred to as a sprint in in the Scrum methodology) to identify the work to be done during that iteration. This is referred to as self-organization. ✓ Daily planning: Development planning: Development teams begin each day with

























Chapter 3: Getting Started with Agile

17

with the product owner defining what the software will do and what services it provides to its users. Instead of following the more traditional process of product managers and business analysts writing lengthy requirements or specifications, agile takes a lightweight approach of writing down brief descriptions of the pieces and parts that are needed. These become work items and are captured in the form of user stories. A user story is a simple description of a product requirement in terms of what that requirement must accomplish for whom. Your user story needs to have, at a minimum, the following parts:

























18

Agile For Dummies, IBM Limited Edition Title As

Transfer Tr ansfer money between accounts

Title As

Carol,

I want to

I want to

so that

so that

Value

review fund levels in my accounts and transfer funds between accounts I can complete the transfer and see the new balances in the relevant accounts. Jennifer Author

Estimate

Value

Author

Estimate

Figure 3-1: Card-based user story example.

The product owner gathers and manages the user stories.



























Chapter 3: Getting Started with Agile

Planning Poker

19



























20

Agile For Dummies, IBM Limited Edition output, for that iteration. After the first few iterations, ite rations, you’ll start to see a trend and will be able to calculate the average velocity.



























Chapter 3: Getting Started with Agile Project Burndown 400 350

21



























22

Agile For Dummies, IBM Limited Edition writing a lot of code, running it, and going back later to figure out everywhere it’s broken (a process known as debugging ). This process puts the developer in a testing mindset while writing code, which leads to higher-quality code.



























Chapter 3: Getting Started with Agile test regressions in an integration environment is a critical part of agile done right. CI ensures high-quality working software at all times, and CD ensures that the software is running in the right place.

23





















































































































































































































































































































































































































































































































































































































































































64

Agile For Dummies, IBM Limited Edition discipline than what’s typical of traditional teams. Agile requires teams to reduce the feedback cycle on many activities, incrementally deliver a consumable solution, work closely with stakeholders throughout the life cycle, and adopt individual practices which require discipline in their own right.

Agil Agilee Mean Meanss “We “We Don’ Don’tt Plan Plan” ” With agile’s reliance on collaboration instead of big documents, it may seem like no planning occurs. But in reality, the planning is incremental and evolutionary, which has been proven successful (instead of planning all at once early in a project).

Ag Agile Means “No Documentation” Agile teams keep documentation as lightweight as possible, but they do document their solutions as they go. They follow strategies, such as documenting continuously and writing executable specifications.

Agil Agilee Is Only Only Effe Effect ctiv ivee for Collocated Teams Sure, ideally agile agile teams are located within proximity of one another, but in this day and age, most development teams are distributed. Just remember, to succeed, you need to adopt practices and tooling that build team cohesion. If you use the proper tools, your team doesn’t have to be collocated to work effectively together.

Agil Agilee Does Doesn’ n’tt Scal Scalee Agile definitely scales. Large teams must be organized differently. They need more than index cards and whiteboard

















Chapter 10: Ten Myths about Agile

65

✓ IBM Rational Build Forge for Forge for large-scale continuous integration ✓ IBM Rational Quality Manager to to support parallel independent testing IBM is one of the world’s largest agile adoption projects, transforming teams ranging in size from 5 to 600 team members. For more information on agility at scale, visit ibm.com/rational/talks.

Agil Agilee Is Unsu Unsuit itab able le for for Regulated Environments Regulated environments are those that are subject to some regulatory mandates, such as medical device companies, business in the finance area, governmental departments and offices, the healthcare field, and more. These organizations are audited from time to time for compliance with regulations. With agile, these organizations can feel confident when they endure these audits. They benefit from faster delivery of data and higher quality of their output.

Agil Agilee Mean Meanss We Don’ Don’tt Know Know What Will Be Delivered Because agile is an iterative process, it provides the opportunity not just for greater control but better control control over building the right things in the life cycle than one would have with the more traditional Waterfall approaches. At the end of each iteration, the development team presents a completed product to the product owner for feedback. Furthermore, Disciplined Agile Delivery (DAD) teams explicitly explore high-level requirements at the beginning of the project and seek to gain stakeholder agreement around the requirements. See Chapter 5 for more details.

















66

Agile For Dummies, IBM Limited Edition the change requires. Agile has explicit means of frequent feedback and loops, which means that developers and managers may feel more exposed to scrutiny. But that doesn’t mean that agile won’t work at your company. Agile is a team approach. It’s not like football where one player at a time moves the ball down the field to score a touchdown. Agile is more like rugby — the whole team moves the ball down the field together. Roles are cross-functional and shared. Developers become testers and more frequent delivery creates more exposure and personal accountability. For an organization to successfully adopt agile, executive support is also critical. Agile can succeed without it, but if you hit a bump in the road, you’ll want that vote of confidence to help you keep everything moving in the right direction.

It’s It’s Enou Enough gh for for My Deve Develo lopm pmen entt Team to Be Agile For agile to work properly, all teams teams have to buy in. So if your development team is gung ho, but your testing team is blasé, you won’t get your best results. Your agile delivery process is only going to be as effective as your slowest group. To make agile succeed at its greatest potential, make each piece of the chain as efficient as possible.

Agil Agilee Is a Silv Silver er Bull Bullet et Agile isn’t needed for every team in every situation. It isn’t a cure-all. Agile is a superb solution for projects that are in development or undergoing radical changes. For other projects, such as those that are in maintenance mode, agile isn’t as good a fit. If your project has a stable customer base and isn’t undergoing a lot of change in the code, you may not need to use agile for that particular project. But for projects that are under new product or rapid development, agile really is the

IBM Agile for Dummies

Recommend Documents