AGILE DEVELOPMENT WITH A CAPITAL A

Transcription

1 AGILEDEVELOPMENT WITHACAPITAL A

2 2 On June 3, 2009, Plante & Moran attended the Midwest Technology Leaders (MTL) Conference, an event that brings together top technology professionals in the Midwest to share trends, best practices, and opportunities. With the help of MTL, Table Sponsors, CIOs, and additional conference attendees, we conducted 12 roundtable discussions on a variety of timely and important IT topics. As an outgrowth of the roundtable discussions, we produced a series of educational white papers. Contents Abstract 2 Introduction 2 Agile Adoption Rate Survey 3 Conclusion 6 ABSTRACT Many organizations believe they re software development methodologies are agile. More still want to become agile. Interestingly, there are levels of agility. There s agile, and there s Agile. How do you really know when you re Agile with a capital A? Read on to learn more. INTRODUCTION In the late 1990s, several software development methodologies began to receive public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. However, they all emphasized close collaboration between the programming team and business experts; face to face communication (which has been proven to be far more efficient than written documentation); frequent delivery of new, deployable business value; tight, self organizing teams; and, sometimes, unique ways to craft the code and the team such that the inevitable requirements churn was not a crisis. In the context of software and systems development, the term "agile" (with a small "a") means that development teams are nimble, flexible, responsive to business needs, and able to adopt new technologies and techniques that can improve software delivery. We ve seen development organizations trying to become more agile for a number of reasons, including: Competition: "If we can't deliver new features or products quickly, we'll lose business to our competitors." Credibility: "Our customers and business users hate us; they have no confidence that we will deliver what they want or need at least in this lifetime."

3 3 Fear: "If we don't improve our quality and speed up our project delivery, the company will outsource development to someone else." There are many ways that a software development team can become more agile. Delivering software in smaller, more frequent releases; instituting frequent feedback cycles from customers; and using componentand service based architectures are just a few examples. All of these can improve a team's ability to meet users' needs and deliver value to the business. And, developers can adopt these techniques incrementally, without having to disrupt or overhaul their current development process or environments. The widely used Rational Unified Process (RUP) is agile. RAD approaches are agile. Even running repeated series of short waterfall projects, rather than delivering one large release, can make you a bit more agile. In contrast, the term "Agile" (with a capital "A") refers to a very specific set of processes that have evolved over the past 15 years, including extreme Programming (XP), Scrum, Feature driven Development (FDD), Crystal, DSDM, and Lean Software Development. The Agile Alliance ( a nonprofit organization created by the thought leaders behind most of the Agile processes, promotes a core set of values that all Agile processes must follow: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Every Agile process supports these values, albeit in different ways. Some, like Scrum, address team management. Others, including XP or DSDM, address core development activities or other activities of the development life cycle. Note that users of Agile processes do not have to follow all of a process's Agile practices, nor does use of one process preclude the use of another. Many, such as Scrum and XP, are quite complementary. Why is this distinction important? We have two main reasons for stressing the difference between "Agile" and "agile" processes: 1. Companies adopting Agile processes must be prepared to really change the way they build software, and this change is hard. But companies that do achieve this change will realize some significant benefits in the productivity, quality, and value of the software that they deliver. 2. Companies that aren t ready or able to undertake this level of change can still become more responsive and flexible in the ways that they build software. Then they'll become more agile and will begin to reap the benefits that Agile practices can deliver. This incremental approach can ultimately lead to a truly Agile shop, but at some point the organization will have to step back and acknowledge that it's not a direct path. Agile Adoption Rate Survey: February 2008 The survey was performed in early February 2008, and there were 642 respondents. Some findings include: 1. 69% of respondents indicated that their organizations are doing one or more agile projects. Of those that hadn't yet started, 15% believed their organizations would do so within the next year % of developers think that their organizations are doing agile development, whereas 78% of management thinks so % of organizations doing agile were beyond the pilot project phase.

4 4 4. Respondents overwhelmingly indicated that agile teams are producing higher quality, have greater productivity, and enjoy greater stakeholder satisfaction. See Figure Agile success rates: 82% for co located teams, 72% for near located (people in different cubes, on different floors, working from home), 60% for significantly distributed (planes would be involved to get people together). See Figure % of agile teams have iteration lengths of 4 weeks or less, and 2 week iterations are the most popular. 7. Although, on average, the costs are lower on agile teams, 23% of respondents believe they re experiencing higher average costs. 40% said costs were unchanged, and 37% had lower costs. 8. Co located agile projects are more successful on average than non co located, which in turn are more successful than projects involving offshoring.

5 5 Figure1.Effectivenessofagilesoftwaredevelopmentcomparedwithtraditionalapproaches. Figure2.Agilesuccessratesbylevelofteammemberdistribution.

6 6 CONCLUSION There are still some limitations of the agile process Agile projects in most organizations are influenced by non Agile elements. When external factors come into play, it skews the agility of the process to a certain extent. If an Agile project has a dependency on a project that s non Agile, then its priorities get rearranged to accommodate the non Agile element. Project dates are preset into a definite number of sprints to do a predetermined scope of work. Though these limitations are worked around, it definitely does impact the Agility of the process. Being Agile and working on overcoming these limitations is what this process is all about. Agile is not a solution to all the IT development process shortcomings, but it definitely bridges the gap between IT and business value more than any other process. Overall, Agile is a big step toward more efficient development, but it s still a long way from being "mature. Sources Cited Liz Barnett. "Agile Versus agile Development" =com_content&do_pdf=1&id=18 Agile Alliance. Scott W. Ambler "Why Agile Software Development Techniques Work: Improved Feedback" sfeedback.html THANK YOU Plante & Moran would like to thank Chris Beale, Table Sponsor from Pillar Technologies, Gary Baker, CIO at Gale Cengage, and all roundtable participants for their contributions. For more information, please contact: Doug Wiescinski [email protected]