Вы находитесь на странице: 1из 3

Agile Myths: Busted!

Learn the truth about 9 common agile myths.

By Jim Elvidge

Learn the truth about 9 common agile myths.

By Jim Elvidge Ever run across these guys? People whose lack of experience or fear of change cause them conjure up all kinds of reasons why agile wont work for their project? Lets bust those myths! Myth: Agile Doesnt Work for Projects in the Highly Regulated Medical Environment The reason usually given is that FDA regulations require detailed requirements prior to project approval; hence, waterfall. However, in reality, you can develop in phases, with small incremental sets of requirements and the FDA requires only enough documentation to demonstrate your process. Truth: Abbott Labs overcame medical device regulation and stringent Class 3 certification and developed the m2000 Real-time PCR Diagnostics System, a human blood analysis tool, with four agile teams. Compared to the prior methodology in use, this project resulted in a less cumbersome process, fewer defects, a reduction in costs of 43%, and a reduction in cycle time of 25% (Rasmussen, Hughes, Jenks, & Skach, 2009). Myth: Agile Doesnt Work in Government Truth: The FBI overcame a CMMI level 3, ISO 9001, government-mandated document-driven waterfall life cycle and developed the Domestic Terrorist Database & Data Warehouse with three agile teams. Compared to the prior methodology in use, this project resulted in significant improvements in release planning, developer satisfaction, and a focus on the true goal: to catch bad guys (Babuscio, 2009). For another example, the U.S. Department of Defense developed the Strategic Knowledge Integration Website utilizing three agile teams. Compared to the prior methodology in use, this project resulted in improved quality, fewer defects, better teamwork, and a 200% productivity increase (Fruhling, McDonald, & Dunbar, 2008) Myth: Agile Doesnt Work for Large Products & Agile Doesnt Work with Distributed Teams Truth: Googles AdWords product busts both of these myths. With 20 teams and 140 people across 5 different countries, this large agile program was a groundbreaking success at Google and resulted in more predictable releases, higher quality, and an improved ability to accommodate changes, as compared to the prior methodology in use (Striebeck, 2006). Myth: Agile Doesnt Work in the Regulated Telecom environment Truth: British Telecom moved their entire IT department to agile, starting with 2000 people from 20042007. This large transformation resulted in an improvement from 10% value stream effectiveness to 55%, created an attitude of delivering real value to the business through IT, and shifted the companys perception of IT from a service provider to an integral part of the business solutions (The Agilista PM) (Watts & Leaton).

Myth: Agile Doesnt Work for Client-Based Projects & Agile Doesnt Work for Fixed-Price Projects & Agile Doesnt Work Well When Integrating a Third-Party Product

Truth: I coached an agile team at a prominent consulting company through a project with a client who was a well-known record label. They built a new, fully rebranded, eCommerce website using open source CMS and Search engine, and a third party eCommerce provider. The site included product bundling, integrated music player, and social networking integration. It was implemented using Scrum/XP with a single team of about 12 people over 5 months. The result was an award-nominated site that improved conversion rates dramatically, ultimately profitable for and considered a strong success for both the agency and the client. Myth: Agile Doesnt Work for Manufacturing Vehicles Truth: Wikispeed developed a 4-passenger, 100 mpg, street-legal road car in 3 months using modular, off-the-shelf, carbon-fiber body construction, with no capital investment, and no paid employees. Agile processes were utilized with a single international team. The project went beyond the prototype phase and cars are available online (Rudd). What else ya got?1 Works Cited Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference, 96-100. Fruhling, A., McDonald, P., & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), 464-473. Rasmussen, R., Hughes, T., Jenks, J., & Skach, J. (2009). Adopting Agile in an FDA Regulated Environment. Proceedings of the Agile 2009 Conference, 151-155. Rudd, C. (n.d.). Retrieved 1 7, 2012, from Solutions IQ: http://www.solutionsiq.com/the-agile-ceo/ bid/51480/Agile-Innovation-or-How-to-Design-and-Build-a-100-MPG-Road-Car-in-3-Months Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference, 193201. The Agilista PM. (n.d.). Casestudy_British_Telecom. Retrieved 1 5, 2012, from The Agilista PM: http:// www.agilistapm.com/casestudy-british-telecom/ Watts, G., & Leaton, R. (n.d.). Scrum at BT.pdf. Retrieved 1 16, 2012, from Scaling Software Agility: http://scalingsoftwareagility.files.wordpress.com/2008/06/scrumbt-v14.pdf

Note: Leads for some of these case studies came from David Ricos presentation on Lean & Agile Project Management for Large Programs & Projects