9 Myths About Agile
Setting the record straight on the most common misconceptions about an increasingly popular—and controversial—approach to software development.
Agile has proven a polarizing force since a group of veteran software developers first proposed it in 2001 as a reaction to traditional “Waterfall” development, which they perceived as slow and dysfunctional. Unlike the Waterfall method, Agile encourages rapid and flexible responses to changing business needs and user requirements.
Some in both the IT and business communities are justifiably enthusiastic about achieving desired results more quickly, and welcome the move away from traditional software development approaches. Others are vehemently opposed to Agile for a variety of reasons, including that it requires making disruptive changes to established processes and may place additional burdens on users.¹ The reality of Agile probably lies somewhere in the middle.
Certain myths permeate the often-heated discussions taking place among IT and business leaders considering Agile.
Myth 1: Agile means “no planning.”
Reality: Detailed planning is as essential to the effectiveness of Agile as it is to Waterfall. The difference between the two approaches lies in timing. Planning is ongoing in Agile versus taking place primarily at the project outset in Waterfall. Agile’s incremental planning approach limits upfront startup costs and allows projects to adapt rapidly to changes (in requirements, priorities, scope, etc.) as the projects progress. At the beginning of each sprint, there is a planning meeting to obtain agreement on the requirements that will be addressed which requires a high degree of accuracy in estimating the time to complete each requirement. During the sprint, the daily standup meeting is utilized to define the activities for the day at a detailed level.
One of the challenges of an incremental planning approach is the need to properly manage technical debt (cost of code quality) and willingness to revisit prior decisions as the project progresses and more information becomes available. To counter this challenge, it is important to capture both user requirements and system requirements and effectively prioritize each as part of the backlog grooming process.
Myth 2: With Agile, there won’t be any project documentation.
Reality: In any application development effort, documentation serves as a road map: It delineates how a system will work and what it will contain, and helps keep the respective objectives of the business, end users, and developers aligned. Increased collaboration throughout Agile development projects provides all stakeholders with a better understanding of the end product as it is being created, thus reducing the need for some design documentation. Agile does, in fact, produce documentation, even though it differs from that of Waterfall. For example, rather than create a single, lengthy document listing all project requirements, project managers might compile a collection of user stories that can be actively updated and maintained using software, prioritized on the fly, and used to provide real-time visibility into development progress.
Myth 3: Agile only works with small projects.
Reality: The Agile team model—small, cross-functional groups that collaborate throughout the development process—proves equally effective on small, point solution projects and larger multifaceted efforts to develop complex systems.² The tendency of Agile teams to “divide and conquer” can be particularly beneficial on large projects: Organizing solution teams by system functionality and/or architectural components can help minimize redundancy during development. For example, a scrum of scrums meeting—in which scrum teams discuss their work, specifically areas of overlap and integration—is an important technique in scaling scrum to larger project teams.³
Myth 4: Agile requires that stakeholders and developers work in a single location.
Reality: Agile emphasizes heavy stakeholder involvement throughout a development effort. As a result, many assume that team members must all work in the same location for Agile to be successful. With modern technology, this is no longer the case. Teleconferencing systems can facilitate daily meetings among far-flung workers. Likewise, screen-sharing tools often prove effective for impromptu meetings between two colleagues. Bottom line: It’s real-time communication and collaboration that matter, not where or how they occur.
Myth 5: With Agile, the final product remains unknown until development is complete.
Reality: In Waterfall development, the end product is fully defined via requirements before the first line of code is written. While this approach is helpful in cases where all product details are known upfront, any design uncertainty or unanticipated changes in business processes, stakeholder needs, or data requirements can result in costly delays. Agile, in contrast, plans for uncertainty by calling only for a broad, overarching plan during the early stages of development, with the details to be progressively refined as the system is built. This approach provides stakeholders a better understanding of what they can expect to receive in the near-term (e.g., a discrete set of functionality during the current development iteration) and the long-term (the accomplishment of the project vision as defined by the completion requirements and constrained by team efficiency, funding, timeframes, etc.).
Myth 6: Agile processes are less disciplined and structured than those of waterfall.
Reality: Mature Agile frameworks prescribe a disciplined, repeatable approach to implementing software. Successful Agile implementations are more process-driven and coordinated than traditional waterfall implementations. From scope management (via user story prioritization) to project management (via defined roles and events), Agile requires more discipline because a project’s scope is actively managed from planning to launch, with stakeholders reviewing progress at set intervals and providing feedback every step of the way. The flexibility of this process includes built-in safeguards (e.g., suppressing the addition of new requirements or user stories in the middle of a sprint) to prevent never-ending release cycles.
Myth 7: Agile = Scrum.
Reality: Known for its flexibility and its ability to accommodate last-minute changes, Scrum is an Agile framework often deployed in projects that are particularly complex. Yet despite its popularity among software developers, scrum is not the only Agile approach: Lean programming,extreme programming, and several hybrid approaches all have their own champions. For that matter, developers don’t have to adopt any particular Agile approach but can tailor existing processes to incorporate one or more Agile principles to help increase stakeholder collaboration, deliver software incrementally, and better adapt to changing stakeholder needs. For example, some federal agencies have successfully tailored their existing SELC and the way stakeholders collaborate throughout the lifecycle to achieve some of the benefits of Agile without having to adopt a specific Agile framework.4
Myth 8: Agile is incompatible with development requirements for federal software.
Reality: Federal regulations do not preclude using Agile methods. However, certain standard federal practices may present challenges for agencies considering contracting with software developers that embrace Agile methods. Broadly, challenges fall in the following three areas—acquisitions, enterprise architecture, and security certification & accreditation (C&A). More specifically, consider this: Before putting a software development contract out to bid, an agency typically creates a long list of project requirements and a detailed description of the desired final product. In doing so, the agency hopes to buy a specific outcome from a chosen vendor. But what if the desired outcome changes during the course of a project? With its flexibility and embrace of last-minute changes, an Agile method could accommodate agency requests without the change orders, delays, and budget overruns that can plague typical projects. When all project requirements are finalized and spelled out in vendor contracts—as they typically are on federal projects—changes can be much more difficult to make. As a result, Agile contracting may require a shift in focus from fixed scope to fixed timelines and buying capacity (e.g., a set number of sprints or user stories).
Myth 9: Agile is a cure-all for software development challenges.
Reality: Agile proponents often tout clearer stakeholder alignment, quicker delivery of working functionality, and earlier issue/risk identification, among others, as the method’s advantages over Waterfall. As such, some are tempted to believe that Agile can be effective in every situation, which is untrue. There are many reasons why software projects fail and improper execution of a software development method is just one of them. Agile may not be the best approach in projects that cannot be broken down into small units of work that can be completed in one- to four week increments. It also relies on active stakeholder involvement and a willingness to adopt an incremental delivery approach, which are not easily achieved in some organizations. Analytics, mobile, and social project implementations naturally lend themselves to Agile software development approaches. Others, such as ERP or large-scale system modernization initiatives, may not be as ideally suited.
—by Eric Bristow, director, Deloitte Consulting LLP and Azunna Anyanwu, specialist leader, Deloitte Consulting LLP
1. Esther Schindler, “Why Your Users Hate Agile Development and What You Can Do About It”, IT World, June 4, 2013
2. “Twitter Engineering SVP Chris Fry on the Power of Stable Teams”, First Round Review
3. Mike Cohn, “Advice on Conducting the Scrum of Scrums Meeting”, Scrum Alliance, May 7, 2007
4. “Effective Practices and Federal Challenges in Applying Agile Methods”, U.S. Government Accountability Office, July 27, 2012
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.