Ten Weaknesses of the Agile Methodology

July 8, 2010 | Author: PM Hut | Filed under: Agile Project Management

Ten Weaknesses of the Agile Methodology
By Donald Patti

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.

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.

I’ve come up with this list of Agile weaknesses, which apply to Agile as it is most commonly implemented:

  1. True Agile is rarely practiced. Long-time practitioners will tell you, “It’s Agile – not agile”. 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.
  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Agile requires more 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.

  8. 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.

  9. 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.

  10. Agile lacks the attention to outside integration. 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 often do not 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 re-work, additional time, removal from scope, or a poor-quality product. For many of us, none of these options are acceptable, which explains the weakness of Agile in this area.

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.

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.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

7 people have left comments

I have to admit that you might be right in many points. But now, when you can clearly see where the problems are, you can do something about it. Check Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

I see Agile as a set of guidelines, we don’t have to use all of them (it’s not always possible, for instance when business have no time to work with development team) to be agile. The one which we use we have have to adopt and tweak to make sure that the team is as efficient as possible.

Marek Blotny wrote on July 11, 2010 - 2:36 am | Visit Link

I actually have a problem with almost every one of these points. While I agree that any organization must consider a change to its processes very carefully, some of these “weaknesses” (#2 in particular) are actually strengths. I’ll be addressing each of these points in turn over the next few weeks on my own blog, if anyone’s interested.

Curtis wrote on August 8, 2010 - 5:07 pm | Visit Link

[...] ever had the feeling someone REALLY didn’t get it?  I had that feeling recently when reading this article about the supposed weaknesses of agile.  Some of the 10 points make a bit of sense, but what seems [...]

Your Agile isn’t my Agile! wrote on August 23, 2010 - 12:25 pm | Visit Link

From the Agile perspective, there are serious issues with this article. Part of the problem is vigorously conflating Agile-done-right with half-assed Agile implementations. Part of it is that a number of these notions might have been reasonable misunderstandings in 2003, but today seem woefully ignorant (e.g., #4, #5, and #9). And part of it seems to be arguments purely from theory, from somebody who doesn’t appear to have much serious Agile experience.

But I think the biggest issue with the article is that it is filled with false comparisons. Suppose you move into a fourth-floor office in a building with no elevator. Compared to people in a building with an elevator, you’ll be out of breath more often. Since we know that being out of breath is a sign of being out of shape, the elevator riders could naively think that they are more fit than you. But really, your stairs are just exposing a problem that remains hidden for the other group.

That’s exactly the sort of false comparison that happens here. For example, all software projects can benefit from interaction with users, and feedback from business stakeholders. Agile projects, though, take better advantage of available contact, and make it obvious where the project could benefit. If you force an Agile team into a vacuum and give them a giant spec, they’ll still deliver, and do it better than the waterfall team. But they’ll be correctly cranky about it.

The same sort of mistake is made with the points on refactoring, estimation, and collocation. Both Agile and Waterfall teams struggle with the right architecture, with good estimates, and with optimal collaboration. But only Agile methods makes those problems obvious early, so they can be fixed quickly.

It’s disappointing to me that an article like this could be written in 2010; apparently Agile knowledge still lags well behind Agile popularity.

William Pietri wrote on August 23, 2010 - 11:53 pm | Visit Link

I think the general point in time and cost, agile does not give you the full picture on these elements which I think the article is hinting at.

e.g. My general point is while Agile is easy to appreciate it is initially difficult to implement in a new teams unlike other methodologies. Agile confuses people at the top and cause those in the middle to struggle to implement.

Howard wrote on August 24, 2010 - 12:55 pm | Visit Link

I have some comments on your 10 points, I’ll address them 1 by 1.

1. Since you are more a waterfall kind of person, I bet you have hard figures: how many projects fail when using agile vs how many projects fail when using waterfall methods?

2. In your ridiculous example my Scrum team is not allowed or not able to talk with the customers. Any idea where the hell your waterfall team is going to get their requirements from? And if you magically find a piece of paper where all the customer requirements are written down, how the hell are you going to make sure that your team making no errors in mis-interpreting all the requirements?

3a. Yes, it is better for a team if they can talk with each other.
3b. If some smart-ass manager came up with the most brilliant idea to out-source parts of the project leading to scattered teams, Agile doesn’t fail harder then waterfall. Conference meetings allow you to keep in touch with each other, and in the end, the scattered Scrum team still communicates better then a scattered waterfall team.

4. Typical Scrum teams exist of 7-9 members. Make more teams, and you don’t have a problem. Make huge Scrum teams, and you run into the same problems as huge waterfall teams, so again, ridiculous statement.

5. Agile is not weak on architectural planning. Waterfall is weak on architectural planning. Write a “waterfall-like” architecture up-front and you’ll get the most useless, over-flexible, unnecessary complex architectures. Do some research about the biggest wastes in software development, and see how much software is written under the flag of “future extensions” and “future requirements”, which will be maintained by your dear developers… for no reason at all. How about referring to that as waste.

6. Clearly you never have been in an Agile or Scrum team. How about we do sprint planning meetings, which is all about descoping. There we decide what we REALLY need to implement, and shift-delete all nice2haves. Further more, of course it’s possible to have a project plan in Agile. And what totally kicks is the following: our plans do make the deadlines.

7. Completely bogus again. Regardless of waterfall or Scrum, there is no such thing as first time right software. The good thing is, that using Scrum you only have to refactor small parts, where typical waterfall projects can start over from scratch.

8. Ok, this was almost getting close. Sure we can’t give an estimation of a complete project being ready. What we can give, is a deadline for the most important features needed first. What a typical waterfall project can do, is give a deadline when the complete project is ready and fail to make the date. Djeeze, I wonder what the “senior-management” prefers.

9. We don’t have a Hero culture, your waterfall teams have that problem. Further more, we don’t waste 70% of our valuable time writing documents nobody will ever read.

10. Nope, we don’t run into that problem. But then, our project only counts 250 men.

I never read so much BS in article. What a shame you never are properly introduced with Scrum.

Bas Prins wrote on October 21, 2010 - 1:23 pm | Visit Link

Dpnald,

I happened on this older post when browsing John Goodpasture’s site. I found your criticisms measured and reasonable. Architecture, scaling, and communication beyond a small team all require additional weight and ceremony. I hope the discussions can be a little more civil than name calling. I haven’t figured out how to get the trackback working yet, but I discuss some of this at the process revolution http://billnichols.wordpress.com/2011/05/12/agile-weaknesses/

Bill Nichols wrote on May 11, 2011 - 9:58 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories