Last Updated Nov 06, 2009 — Enterprise Agile Planning expert
Five Myths of Agile Development: Myth #5 / Agile is Just Another Fad
Enterprise Agile PlanningYesterday, we refuted Myth #4 / Agile Development Does Not Scale>. Concluding this series is Myth #5 / Agile Development is Just Another Fad. Fads typically involve a great deal of hype with little sustained substance. In a span of less than five years, agile development has become the preferred development approach for many of the world's leading technology companies. Many of the industry's leading visionaries and practitioners have embraced and promoted agile development. And while five years ago agile development was primarily being adopted by small, collocated teams, many of today's adopters include large divisions and software organizations of enterprise IT. In the Forrester report Corporate IT Leads The Second Wave Of Agile Adoption, author Carey Schwaber discusses the second wave of adoption that's now underway, with enterprise IT shops taking the lead. Results compiled within the report indicate that agile development processes are already in use in 14% of North American and European enterprises, and another 19% of enterprises are either interested in adopting agile or already planning to do so. Enterprise IT shops have found that by turning to agile processes they are better able to cut time/to/market, improve quality, and strengthen their relationships with business stakeholders. The broad/based acceptance of agile development is clearly a significant shift in the industry over the last few years. In a recent survey of VersionOne's own customers, the results corroborate those found by Forrester. The top three reasons noted for transitioning to agile development included accelerating delivery, aligning business and market needs with IT, and improving visibility into the software development process. These are not the evaluation results of a fad, but instead business criteria based on real business results. Finally, understanding agile team dynamics and collaborative decision/making techniques is important in part because agile requirements definition involves more than just the BA and the product owner. These skills enable the BA to accept input from all the team members, specify a more robust solution that meets the evolving needs of the business, and help create a strong sense of confidence that the solution can be delivered to market. (For insight into the impact of agile development methodologies on the business analyst community, check out The Agile BA white paper.) Ultimately, every software organization will need to evaluate agile development methods in order to determine applicability and value. While some teams may determine that agile does not make sense in their environment, they should do so based on facts rather than the myths we've discussed in this series. With any new way of doing business, there is often a fear associated with the unknown. Fortunately, many software industry leaders and early adopters have been breaking down barriers and addressing the issues and challenges associated with agile development for five to ten years now. Throughout this process, the true leaders and practitioners of agile development have continued to demand a high degree of discipline in each and every practice they promote, from test/driven development to continuous integration, to release planning and daily stand/ups. Indicative of the growing momentum within the software industry is that corporate IT is now driving the adoption of agile development on a much broader scale. Agile is definitely not just for small, collocated teams any more. While accelerating time/to/market is serving as the primary catalyst for most companies transitioning to agile, surveys show that many teams are also benefiting from improved visibility, productivity, value, quality, and an overall reduction of risk in the development process. The ultimate vote of confidence we hear is that a vast majority of adopters of agile development could not imagine returing to their old ways of building softare, and that speaks volumes.
Read the other posts in this series:Myth #1 / Agile is UndisciplinedMyth #2 / Agile Teams Do Not PlanMyth #3 / Agile is Not PredictableMyth #4 / Agile Does Not ScaleIf you'd like to download this blog series in document (PDF) format, get the Five Myths of Agile Development white paper.