It’s been more than a year since I penned, “Before Making the Leap to Agile”, an article intended to guide everyone from C-level executives to IT project managers on the adoption of Agile. The goal was to offer up some of the lessons I learned through actual implementations, so that readers could avoid of some of the pitfalls associated with Agile adoption. While a few saw it as an assault on Agile, many understood that my goal was to assist Agile adopters and thanked me for writing it.
Five-thousand-plus page views later on the last article, and I’ve finally cleared my plate enough to address an equally important topic: why people, and organizations, are making the shift to Agile from the more typical Waterfall. After all, Agile is a revolutionary approach to software development and it continues to grow in popularity, so I think it’s important for those who do not yet use Agile to understand why others have embraced it.
Why are people abandoning Waterfall and moving to Agile?
1. Agile is Adaptive. For the project team, as well as the business, Agile enables you to make quick changes in direction so that your software product and your business can respond to a rapidly changing business environment.
How? Agile teams use two-to-four week iterations, often called sprints, in which to develop and then release a working product. At the end of each sprint, the team uses retrospectives to look back on the work completed and see how productivity can be improved; the team also works with the customer to determine which work should be accomplished during the next sprint. One technique enables continuous improvement, the other enables the business to re-prioritize work based on changes in the business climate. Together, they make Agile highly adaptive when compared to a Waterfall approach that effectively locks the team in to both a process and business strategy for a number of months.
2. WYSIWYG (What You See Is What You Get) Development. Many of us are familiar with this wonderful cartoon that shows how projects really work — at least in a Waterfall world. Notice how there’s an enormous disconnect between the first image, “what the customer asked for”, and the last, “what the customer really needed”.
Arguably, this happens because those of us in software development listen dutifully to what our customer says, document their words in the form of requirements, and then go off and build it, assuming all along that our customer knows not only what they want – but what their end customers want. In reality, many of us have a rough idea of what we want and often less of an idea of what our customers want, particularly with software products that serve the masses (sure, focus groups and usability testing make a big difference, but still fall short in many instances).
Agile takes an entirely different approach to requirements gathering. Product features are identified for development and then the team works together with the business customer to build the features cooperatively. In many cases, user stories are written, screen mockups are drawn and simple business rules are written, but nothing too sophisticated. Instead, the Agile team relies upon heavy interaction with the customer or product owner to elicit requirements on-the-fly.
For example, not sure what the business customer wanted on a particular screen? Show them what you’ve got and see if it fits their expectations. Even if it is what they asked for, see if it’s going to serve their customer’s needs as they intended, or if it needs some refinement. Either way, if they want a change, change it. Using this nimble approach, there is little risk of misinterpretation of requirements and even less risk that the finished product misses the mark.
3. Shorter Time-to-Market. Let’s be honest here – who among us hasn’t reported to a C-level who has a great idea and wants something on the market – yesterday. (Heck, I’ve been guilty of this myself). Using a Waterfall approach, delivering anything to the marketplace takes months and sometimes years. But, by taking an Agile approach, the bare-bones features of a new product can be delivered in weeks, then, further enhanced to provide a truly robust solution. Again, the secret to shorter time-to-market lies in the use of iterations (sprints), with the end of each sprint another opportunity to deliver more features to the customer. Agile has this – Waterfall doesn’t.
4. Greater Employee Satisfaction. One of the oft-cited byproducts of Agile development is greater employee satisfaction – both by the project team and the line-of-business responsible for delivering the product. According to Steve Greene and Chris Fry, Salesforce.com reported an 89% employee satisfaction rating after adopting Agile when compared to only 40% before adoption.
In a similar vein, research by Grigori Melnick and Frank Maurer from the University of Calgary showed 82% of employees at Agile-adopting businesses were satisfied or very satisfied with their jobs, while only 41.2% were satisfied or very satisfied in non-Agile shops (2006, Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams).
5. Higher Quality. By most accounts, adopting Agile reduces defects and results in higher product quality. While personally I have seen Agile projects head in the wrong direction and suffer from higher defect rates initially, many sources have noted significantly higher quality on Agile projects. According to a 2008 survey by Version One, 68% of respondents to a survey on Agile adoption and corresponding results reported improved product quality as one of the benefits (3rd Annual Survey on the State of Agile Development). Similarly, David Rico, et. al report on average a 75% improvement in quality by adopting Agile (The Business Value of Agile Software Methods, 2009, J Ross Publishing).
6. Higher ROI. If there’s one single reason for the corner office to be sold on Agile, it has to be higher ROI. Because Agile reduces project overhead, delivers beneficial work more quickly and produces higher quality products, Agile also delivers a higher ROI to the businesses who adopt it. According to research that compiled data from multiple different sources, including Microsoft, Version One and the University of Maryland, Agile projects average an 1788% ROI when compared with Waterfall projects at 173% (The Business Value of Agile Software Methods, 2009, J Ross Publishing). While these numbers appear to be skewed toward the low side for Waterfall because the comparison only included CMMI-adopting organizations, that hardly makes up for a 10-fold difference between the two.
With all of this evidence residing squarely in the corner “for” Agile adoption, it’s sometimes hard to understand why Waterfall is still practiced. But the truth is, adopting Agile takes a paradigm shift in thinking that is not easy for individuals, much less organizations, to make. It also takes experience not only in practicing Agile, but also in managing organizational change, two qualities critical in Agile consultants.
This is why the Cedar Point Consulting team tailors its Agile implementations to each organization, choosing the tools and techniques that best match your industry and needs so that you avoid many of the pitfalls and have a successful adoption. It’s also why I have personally put so much time and effort into making Agile even more robust, not only by exploring Agile at Scale, but also by off-setting some of Agile’s weaknesses with common-sense approaches that nearly every business can implement.
So, go ahead, make the leap to Agile. Just be certain you’re taking the right approach to Agile adoption for your organization before you begin.
Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.
|It’s been nearly a decade since Martin Fowler, Ken Schwaber and fifteen other experts in the software industry wrote the Agile Manifesto outlining an approach to software development radically different from the Waterfall model that dominated the 1980’s and 1990’s. Since that eventful time in 2001, Agile software development methodologies, including the use of Scrum, XP (Extreme Programming) and Crystal, are all the rage throughout business and government, attracting praise like a miracle drug. As of early 2010, Agile is till one of the more popular buzzwords in software development.
If you’re in the captain’s chair as a C-Level IT executive (CIO/CTO), the head of software development, the head of your Project Management Office (PMO) for your business, or the lead project manager in a small organization, you may be considering the leap to Agile seriously. The good news is that Agile is working well for many businesses and on many software development projects.
The bad news is that Agile is not the magic bullet many are claiming it to be. As many successes as there are in Agile development, there are also many failures in both the adoption and use of Agile in software development. (Here’s a list here of some cautionary tales, provided to support my statements, not to completely turn you away from Agile: The Great Pyramid of Agile, Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong, Agile: Anatomy of a Failed Project, A Scrum Project That Failed.)
The fact is that seasoned business and IT leaders, particularly those at larger businesses, should take a closer look before plunging in to the Agile world with reckless abandon. Agile has a number of weaknesses that many disciples of Agile fail to acknowledge. After all, they’re in the business of developing with and helping you to adopt Agile, so they’re not likely to tell you about its problems and limitations.
Need Help Adopting Agile?
Together with my friends and fellow associates at Cedar Point Consulting, we’ve come up with this list of Agile weaknesses, which apply to Agile as it is most commonly implemented:
- True Agile is rarely practiced. Without a doubt, the biggest single problem I have encountered in Agile-practicing shops in the past decade has been that too few people truly understand and practice Agile. In many cases, software developers, development managers and consultants alike mistake Agile for its lowercase sibling, agile, and assume that Agile is all about flexibility and absence of process.This is far from the truth. Agile has formal rules and structure, though they are quite a bit different from those of other development approaches. Agile is iterative, it is adaptive and it is supported by some outstanding tools and techniques, like burn-down charts, product backlogs, user stories and stand-ups. Most important, Agile is not anarchy. It does not mean that everyone does whatever they want and there’s no sense of organization, despite the fact that you may feel this is the case.
- Some appropriate descriptions of Agile can be found at these sites, where you can better understand Agile, but you can also see that the Agile has quite a bit of history, rules and structure.
- A Gentle Introduction to Agile: http://www.agile-process.org/
- Wikipedia’s entry on Agile: http://en.wikipedia.org/wiki/Agile_software_development
- The Twelve Principle of Agile: http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/
- Agile Defined by Scott Ambler: http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
- Heavy customer interaction is essential. Reflected in principles four and five of the Agile Manifesto, heavy customer interaction is one of the biggest benefits of Agile, but it also becomes a weakness in some environments. Consider, for example, situations where the customers or users of the software being developed do not have the time available to meet with members of the software development team on a frequent basis? What if the key customer is the CEO, who often has more important matters to address? What if you’re not permitted to talk with the users?One important thing to know about Agile development teams is that they are high maintenance – they work quickly, but they also require much more time and attention from the business side to be able to work quickly. If that time cannot or will not be spared for their benefit, using an Agile approach will bring little gain over a Waterfall approach.
- Agile thrives with co-located teams. In a typical Agile environment, the Agile development team and the business users are located in the same physical location, such as the same floor and cube space, to increase interaction within the team and with the customer. This technique is highly effective, but it is also not always practical. In many cases, the line-of-business does not have the space to temporarily house the development team members. In other cases, the development team is national or international, so it is simply impossible or cost-prohibitive to have some members of the team on site.
- Agile has difficulty scaling for large projects and large organizations. When run properly, an Agile development team is typically in the three-to-eight person range, being made up of the software product manager, a team leader (often the Scrum Master), one-to-three developers, and in some cases a designer, an business analyst and a tester. In many cases, the designer, analyst and test roles are shared by the leader and the developers, so the team could be as small as three people. With its heavy emphasis on customer interaction, self-organizing teams, verbal-communication over-written-documentation, prototyping and requirements flexibility, it becomes extremely difficult to coordinate work as an Agile team grows. For example, one developer may be working on an order entry screen that relies upon data in a product catalog or inventory management system being created by an entirely different group within the team. These two need to talk to make certain their two parts of the system work well together, or they’ll end up with two incompatible parts, which is not a problem with a small development team sitting side by side. Assume, instead that the two developers share work with thirty other team members and they are thousands of miles apart. How likely are they to discuss the shared work area? How hard will it be to uncover their shared interest via daily standup meetings? The scalability problem with Agile is not minor and it shouldn’t be overlooked. I’ve seen this problem wreak havoc in three businesses and three large-scale projects to-date, so it’s not to be taken lightly.
- Agile is weak on architectural planning. While software architecture is not entirely like building/construction architecture, they do share some qualities, including the need for a well-defined architecture up-front. In construction, a good building architect determines the structure of the building, the materials to use and integrates the architecture into the landscape long before the first nail is hammered. Similarly, a reliable software architecture and the software platform are selected before the heart of the software is developed. Otherwise, there’s a good chance much of the work will need to be thrown away, much like a make-shift shack in a third-world shanty town. The XP approach does have architectural spikes, but on large scale projects it may take many weeks or months to choose and verify that a particular set of technologies is the most appropriate one, something that can hardly be done in a few days within a single iteration. Yet, the decision on which technology platform to use and how to structure the system is so critical, because it not only affects the success of the overall project or program, it binds the business to that architecture for years to come.This weak-architecture problem is only an issue when the architecture and the platform are not known or pre-determined. In many larger businesses, software architecture and platform selection are done separately from software development via enterprise architecture and architectural roadmaps, which often takes the burden away from the Agile software team. However, if the platform is not known prior to the start of the project and the architectural approach is new or unproven, then the Agile software approach will struggle to define and deal with architecture.
- Agile has limited project planning, estimating and tracking. There are tools available in the Agile arsenal for planning estimating and tracking, but as Agile proponents will tell you, there’s very little emphasis on these core aspects of project management. By design, Agile minimizes planning through the use of backlogs – prioritized to-do lists of software product features – and by fixing deadlines instead of scope. In most cases, estimating level-of-effort is done for each iteration (sprint), with only rough estimates for for each release.Efforts to track progress vary – some projects ask the developer to mark a specific task on the backlog as “done”, while others ask team members to report hours while tracking which work items are designed, developed an tested as though they flow through a miniature life-cycle in each iteration.In most cases, this lightweight planning, estimating and tracking process suits small, non-strategic projects well. But often is not acceptable when the customer is a third-party who requires scope and cost defined via contract or a senior manager who wants to know what will be provided, when it will be done and how much it will cost.
- Agile requires re-work. Because of the lack of long-term planning and the lightweight approach to architecture, re-work is often required on Agile projects when the various components of the software are combined and forced to interact. In Agile-speak, this is roughly called “refactoring” and it is both expected and budgeted for in each iteration after the first. Certainly, refactoring has its benefits in that one team member does not have to wait for the other to begin work. However, in a worst-case scenario, major portions of code may need to be re-written when two or more developers are not in sync, resulting in higher and higher re-work costs as the number of iterations increases.
- Challenges making contractual commitments. For many projects, the client and/or senior management want commitments about the triple-constraints – what will be provided (scope), when it will be provided (time), and how much it will cost (cost). For Agile projects, in particular, it is extremely difficult to prepare estimates for fixed-bid contracts and its not uncommon to see senior managers pound their fists on the table when they fail to received detailed estimates.
- Agile increases potential threats to business continuity and knowledge transfer. By nature, Agile projects are extremely light on documentation because the team focuses on verbal communication with the customer rather than on documents or manuals. As a result, a switch of a single team member, much less an entire development team, away from one product and over to another can significantly impact the organization’s ability to maintain and improve that product. Much of the knowledge resides in the team’s head and is gone when they are.
- Agile makes outside integration difficult. Both large software development projects and small projects in large environments require multiple points of integration with other systems in their universe, such as sharing data with a downstream system (from order processing to accounting) or retrieving data from another system (such as inventory quantities to order processing). In most cases, these integration points need to be identified early, then they need to be clearly defined so that both sides can develop the two software components to work well together. The problem is worsened with third-party integration, when another business needs to integrate with you or you need to integrate with them. In these cases, contracts and service level agreements come in to play, requiring lawyers, approvals and frequent meetings before the first line of code is written, pushing the total completion time up by 2 to 10 times.
Because Agile teams do not always invest the time in identifying and designing the integration points with other systems in advance, the need for an integration point can become a last-minute surprise that often requires additional time, removal from scope, or a poor-quality product. For many of us, none of these options are acceptable.
With all the strengths of Agile methodologies, these ten weaknesses can (and should) prevent some businesses from adopting Agile in its most common form. While Agile is very popular with consultants, IT journals and on the Internet, it’s not well suited for every business and every project (see “Agile Home Ground” versus “Plan-driven Home Ground”).
If, with the list of weaknesses in mind, you’re still thinking about making the move to Agile or you’re using Agile already, there are quite a few ways to offset Agile weaknesses and leverage the many benefits Agile brings. In my next article, I’ll describe some key improvements being made to Agile as it matures to handle larger, more complex software development projects and adapts to go head-to-head with the more traditional methodologies.
Donald Patti is a Principal Consultant with Cedar Point Consulting, a business coaching and consulting firm based in the Washington, DC area, where he assists organizations in applying Lean and Agile to develop new products and services as well as improve organizational performance. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.