Better Software - November 2007 - (Page 7)

Technically Speaking Twelve Ways Agile Adoptions Fail by Jean Tabaka The following article, originally published on StickyMinds.com as “11 Ways Agile Adoptions Fail,” has been updated by the author to include additional helpful information for the agile adopter. Agile methodologies have taken some heat when they appear to have failed to deliver expected benefits to an organization. In my travels as an agile coach, I have found that agile practices don't fail—rather the variations on agile adoption fail. Here are my top twelve failure modes. See which ones may be painfully familiar to you: 1. Ineffective Use of the Retrospective—Agile is all about inspecting and adapting. When I walk into an organization to help it evaluate its adoption of agile, my first question is, “When was the last time you ran a retrospective, and what did you do with the recommendations from that meeting?” Agile adoption hungers for the nutrients that real retrospection brings. 2. Inability to Get Everyone in the Planning Meetings—I’ve worked with several organizations who insist they are “agile” and yet still have a subset of team leads completing all the iteration plans: tasking, estimates, and assignments. Agile requires full-team collaboration on any commitment of the plan; without this commitment, a team stays stuck in the myopia of command-and-control. 3. Failure to Pay Attention to the Infrastructure Required—A good “first focus” of agile teams is to adopt the regular flow of functionality through fixed time boxes. But time boxes alone do not make an agile team. Good agile adopters continuously improve infrastructure that eliminates waste and increases the value flow. 4. Bad ScrumMasters—I work primarily with Scrum teams, and those that struggle the most typically have a command-and-control project manager or a decision-oriented technical lead as ScrumMaster. Without a facilitative, servant-leader mode of team guidance, the agile adoption will be only a thin veneer over non-empowered, demoralized teams. 5. Product Owner Is Consistently Unavailable, or There Are Too Many Owners Who Disagree— Product owners not passionately engaged in the agile adoption hold the software development team hostage until the expected benefits have been delivered. Unavailable product owners create wait-time waste, which means decreased value delivery. Multiple product owners who don't agree present a similar problem: They create waste as the team waits for them to come to consensus about their priorities. 6. Failure to Pull Testing Forward— Teams eager to adopt an agile approach can very often be hampered by the organizational blinders associated with a waterfall approach. While the team may attempt to deliver valuable functionality in time boxes, their definition of “done” for these functions may not include “fully tested and integrated.” Without “pulling testing forward,” an agile adoption will continue to suffer the same plight as the waterfall approach: a growing backlog of defects with unknown complexity and unknown effort to remove them. 7. Reverting to Form—Agile is simple but hard. Giving up when it feels hard undermines the ability of the adoption to succeed. Teams need time and support to adopt the dis- ciplines necessary for agile success. 8. Obtaining Only “Checkbook Commitments” from Executive Management—I call this “phoning in their role.” An executive who announces, “We are going agile,” yet fails to provide resources and commitment and fails to change measures of success, ultimately demoralizes a team. Agile adoption requires a passionately engaged sponsor willing to make tough organizational changes that serve agile teams and their success. 9. Teams Lacking Authority and Decision-Making Ability—The Agile Manifesto stresses individuals and interaction. It also stresses collaboration and self-organization. Like No. 2 and No. 4, an agile adoption will fail if a team truly does not own its decisions, assignments, estimates, agreements, and its ability to alter these when the team learns something new. 10. Not Having an Onsite Evangelist for Remote Locations—Agile adoption for distributed teams and offshore teams is difficult in the best of circumstances. These remote satellite locations not only need rich support for increased communication, but they also need their own onsite evangelist who can keep the team engaged and in tune with how team members either are (continued on page 45) www.StickyMinds.com NOVEMBER 2007 BETTER SOFTWARE 7 http://www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2007

Better Software - November 2007 Contents MarkYour Calendar Technically Speaking What’s Happening @StickyMinds.com Code Craft Test Connection Management Chronicles The Measure of a Management System Behind the Scenes A Story About User Stories and Test-Driven Development Product Announcements The Last Word Ad Index

Better Software - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.