Limitations of Agile Software Development

January 15, 2009 | Author: PM Hut | Filed under: Agile Project Management

Limitations of Agile Software Development
By Bruno Collet

Agile has become so popular among software professionals that we sometime refrain from criticizing it for fear of being tagged as “behind”, “old school” or downright stupid. Fortunately, experienced IT professionals know better and acknowledge that Agile has limitations.

Allow me to play the devil’s advocate.

Agile was created in large part in reaction to the predominant – and now infamous – waterfall model, and to a lesser extent to all “traditional” methodologies. But did we question the assumption that Agile was indeed superior to traditional methodologies? Although many projects using traditional methodologies failed, many others were successful. Do we have reliable evidence to back the assumption that Agile methodologies are more successful than traditional methodologies such as IBM RUP, CMMI, Prince2, or RAD? The truth is we don’t.

Better questions would be:

  • When does Agile make sense compared to traditional methodologies?
  • How can we combine Agile with traditional processes to better address a specific situation?

In order to try answering these questions, we have to look at the limitations of Agile.

1. A team of stars

Agile has been designed by experienced, smart, and high-achieving people. A friend wisely pointed out to me recently that they naturally designed agile for people just like them: stars. Not everybody’s a Martin Fowler, a Ron Jeffries, or a Jeff Sutherland. You could have given them any project, with waterfall method or even no method at all, and they would probably have succeeded. Indeed, not every group can be motivated, experienced, and skilled enough to self-organize into an efficient team, come up with lightweight processes, and collaborate seamlessly to achieve that great agile teamwork.

Take average individuals in you workplace and imagine what would be the outcome if you trusted them to self-organize and to choose the best way (at micro-level) to reach the desired result, without any close supervision. You might be quite disappointed. I’m not saying that individuals are not qualified, I simply emphasize that it takes more than the average Joe to achieve agility.

  • Does your team have the agile potential?
  • Do you have the agile potential?
  • Do you have the raw individuals to form an agile team in your organization?

Be honest.

If you answered “no” to some of these questions, it doesn’t mean that you cannot become agile. It means that there might be some intermediate steps to take before getting there. In my opinion, these steps typically involve adapting the work culture by progressively empowering teams and individuals, training, and hiring the right people.

2. Fit with organizational culture

I have worked with several different organizations. In one of them, directors can be 30 years old with blue hair, job definitions were broad, and processes were defined independently by each team. In another one, respecting the chain of command and job responsibility were keys to survival, and it took me a couple of days to go though the company’s policy manual. This illustrates two diametrically opposed cultures. Which one do you think is more suitable to implement an agile team?

Enabling agile behavior requires a great dose of individual and team freedom. It translates into cross-functional, constantly adapting work, and switching roles as needed. It also entails adjusting processes continuously to reflect the current situation. More than anything, it means that processes are secondary to people.

As you can imagine, companies that traditionally emphasize narrow responsibilities, policies, processes, and one-size-fits-all methodologies, are particularly at odds with agility. These characteristics form the organizational culture, which pervasively influences all work and behavior throughout the organization. Unfortunately many companies still apply these industrial-era principles. To make things worse, changing the culture might be the one most difficult thing to do for an organization (after all, the culture is the people who are part of the organization).

Nonetheless, some rigid organizations can still benefit from agile. They succeed by “spinning off” groups of people who are in theory working within the organization but who can work in relative independence. This is also how large, rigid companies enable innovation. Indeed innovation and agility are deeply intertwined. Successful organizations are ambidextrous.

What can you do if agile doesn’t suit your organization culture? The easiest solution would be to set up a team that can work independently from the rest, and is not subject to the same rules. People in this team should be fresh hires or should not fit well within the traditional organizational culture. But on the long term, changing the culture implies changing leadership. Assuming that people can change only to some extent, you know what it means…

3. Small team

Agile teams are restricted in size for several reasons:

  • The team has to self-organize, implying an efficient order emerging from temporary chaos. Obviously this process would be too long for larger teams.
  • Team members have to be able to communicate spontaneously with each other and with other stakeholders (i.e. without setting up meetings, sending emails, etc.).
  • All team members participate in the day-to-day management (tasks, changes, impediments, etc.).
  • Team members need to understand what others are doing (cross-functional perspective, team ownership), help each other with ease, and collaborate without centralized control.
  • The team has to be co-located (this limitation will be examined later).

As you can see, agile is a highly participative style of software development. Therefore, the number of participants significantly affects the efficiency of the process. The daily scrum of the Scrum agile methodology perfectly illustrates this limitation.

The daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum word for team leader) goes around the table and each team member mentions the status of tasks and other issues such as impediments or changes. I managed Scrum teams of sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit. Beyond this size, communication becomes inefficient.

Assuming that large projects tend to require large teams, this restriction naturally extends to project size.

Fortunately, there are solutions to somewhat alleviate this limitation. If a large project can be divided into a number of relatively independent smaller subprojects then each part can be implemented by an agile team. However, this solution is not without its own quirks:

  • There has to be a “higher-level” project management to coordinate the teams. This higher-level can be managed with a more “traditional” methodology. Note that we see here a situation where combining agile and traditional methodologies makes sense.
  • When dividing the project into agile-manageable subprojects, we minimize dependencies through architecture. However, agile measures progress based on working software, i.e. delivering features. Dividing a complex project based on architecture yields a very different result than dividing it according to features. Therefore, the agile definition of “progress” – one of the agile cornerstones – has to be adjusted.

4. Collocated team

Agile emphasizes that face-to-face, spontaneous conversation is the best form of communication. While we can certainly agree on the benefits of this form of communication, it severely limits agile applicability. Moreover, this agile principle extends beyond the development team since other stakeholders such as business analysts are required to be collocated.

What does it mean in practice? Imagine that a team member has a question concerning a use case. She should be able to get up, walk 10 meters, ask the business analyst or key user for clarification, and get back to work. Consequently, office space has to be physically arranged according to agile projects so that all stakeholders involved in daily activities are located at the same place (let’s say within a minute of walking distance).

We can easily think of a number of situations where this limitation prevents using agile:

  • Office space organized by departments: In most organizations, offices are organized by departments such as IT, marketing, accounting, sales, and so on. Moving people around according to agile projects is unrealistic. Even if it was possible, it would negatively affects other parts of the business.
  • Distributed environment: Developers are often distributed throughout the organization, whether in the same branch or in different branches (or working from home). Just like for the previous point, moving these people is unrealistic.
  • Subcontracting: Many organizations partly or completely outsource software development. Assuming that some roles such as business analysts or key users would be located at the company, this situation doesn’t comply with the agile collocation principle. We have to acknowledge that there is no substitute for face-to-face, spontaneous communication. Consequently, the best solution is to restrict the agile team to people working at the same location, knowing that even if it were possible it would constitute a less-than-ideal team.

Alternatively, we can try to make the better of it by managing a “virtual” agile team:

  • Collocate as many team members and stakeholders as possible.
  • Set up an “open phone line / video chat / IM” policy to make sure that spontaneous communication is still possible between distant stakeholders.
  • Leverage collaborative software (although in my opinion it has little effect).
  • Schedule frequent in-person meetings with distant stakeholders.
  • Start the project with everyone at the same location for a few days in order to build team spirit.

5. Where’s my methodology?

Software development methodologies include several processes, such as analysis, architecture, implementation, project management, configuration management, and so on. However, most agile methodologies, such as Scrum for example, do not define processes. In particular, most agile methodologies do not define any project management processes. Whether we’re agile or not, we need to manage changes, risks, budget, and so on. As far as I know, lightweight processes doesn’t mean no processes at all! And not everything can be stuffed in short daily meetings without written records.

As a consequence, most agile software development processes are not methodologies, they are no more (and no less) than sound principles and practices to manage the day-to-day operations of small projects (I would call that “team management”). This is great, but hardly enough to manage projects. Similarly, the person managing agile teams is more a team leader than a project manager, the main differences being that a team leader doesn’t manage budget, scope, planning, and reporting for example.

Fortunately, complete agile methodologies are emerging. I personally like OpenUP, because it is minimal, complete, and configurable through the Eclipse Process Framework. It is to my knowledge the only agile software development process that is a methodology (call me picky).

Unless you choose an agile methodology that encompasses all needed processes, you should combine it with a methodology that define these processes and rely on agile for day-to-day team management. Moreover, keep in mind that you need to remain credible with upper management and other stakeholders, who are likely to judge your competence based on processes such as scope, risk management, planning and reporting.

6. Team ownership vs. individual accountability

Agile development stresses the importance of team ownership in order to improve teamwork and therefore overall results. Team ownership is a very appealing concept, but how can we implement it since an organization’s performance-reward system assesses individual performance and rewards individuals, not teams?

If we rely exclusively on individual accountability, we tend to generate selfish behavior that can affect teamwork. If we rely exclusively on team assessment, we overlook that individuals perform differently in a given team, creating opportunities for underperforming team members to get away with it and lessening incentives to perform in a superior way. Obviously we have to find a way to take both these perspectives into account.

Actually this problem can be solved elegantly by defining two levels of performance-reward:

  • Team level: The team is perceived as a single entity from management’s point of view. Management assesses teams’ performance and allocates rewards to teams in the form of points.
  • Individual level: Team leaders (or whatever the title is) evaluate teams members rewarding them with points.

In order to have a short feedback loop, assessment should be done frequently (every month for example) using a lightweight system incurring very little administrative overhead.

The final performance of an individual is calculated using both team and individual scores. For example, team A has been given a score of 7 out of 10 by management. John, who is a member of team A, has received an evaluation of 8 out of 10 from his team leader. John’s final score might be an addition (15 out of 20) or a multiplication (56%) of these two scores, for example. In the end, the manager is responsible to reward John based on his final score.

Thanks to this kind of system, we encourage teamwork but we still take individual contribution into account, effectively reaching a balance between team ownership and individual accountability.

Bruno Collet combines business acumen with technology know-how. His successful track record comprises Daimler-Chrysler, Siemens, and Loto-Quebec, with roles such as management consultant, project manager, SAP consultant, and software architect. Bruno Collet’s skills are firmly grounded in academic excellence by achieving an MBA at John Molson School of Business and a Master of Computer Science. He maintains a professional website:

Related Articles

13 people have left comments

Bruno’s comments mostly align with the content of a book by Barry Noehm and Richard Turner called “Balancing Agilit and Discipline” – a very worthwhile read if this issue has you confused.

Craig Brown wrote on January 15, 2009 - 6:20 pm | Visit Link

Interesting article, and I agree with most of it. However the article isn’t really about “limitations of agile development” at all – it’s more about the prerequisites that need to be in place for agile to reach its potential. This is still an important topic to discuss and understand, but I expected to see some more analysis on how agile *done well* compares with other approaches (also done well). While it’s true that many organisations don’t have the important prerequisites in place for successful agile projects, I also believe most of these can be overcome if the organisation could be made to understand the impact that they may have on their software projects (do they really need large or geographically distributed teams? Is it really critical that every team follow a set of procedures precisely? Do they really need to hire the cheapest developers and testers available?).

Tom Hollander wrote on January 16, 2009 - 9:02 pm | Visit Link

Interesting article, we’re just moving towards scrum, I have little experience of it so far. But I feel I agree with what Tom says above.

This isn’t really about Agile’s limitations more the prerequisites that make it hard to achieve.

Having just done the Scrum Master training, when questions were raised, the trainer retorted that getting Scrum (I assume similar for other Agile approaches) to work is actually really hard. You need buy in from that management team, it’s a culture thing as much as anything else.

Where I am everyone seems to have taken it to heart and it seems that more departments outside of dev are changing to accommodate (which is cool). We’ve now got small teams of people with different job titles working together. We have a smaller geographical problem (different buildings same city), we’ll see how that pans out.

For us I feel that the culture is changing and becoming more vibrant and enthusiastic. It’s really to early to tell, we’re still all buzzed up.

Rock stars we’re not (well maybe on Guitar hero), maybe we have a few. Couldn’t I argue that Waterfall needs Rock stars to make it work also?

Team responsibility I think is important, it stops us from chucking stuff over the fence, especially if you’re now working with the people who used to be in the next silo. Individual accountability, where I’m judged by the team lead, that’s akin to saying “all are equal just some more than others”, I don’t think it fits with scrum, 360’s might work but I haven’t tried either I couldn’t say.

Dan wrote on January 19, 2009 - 7:55 am | Visit Link

Thanks for your comments.

Tom, indeed the title of the article could have been “agile prerequisites”. Limitations and prerequisites are but two sides of the same coin. Just mentioning limitations would not be very constructive. Therefore I proposed solutions to these limitations.

Note that ultimately any methodology could be used for any projects, provided you work hard enough to satisfy the “prerequisites”. Consequently, the question becomes: is it worthwhile, in your case, to enable agile in your organization? Let’s keep in mind that it doesn’t matter that you can race fast if it takes you years to drag the team to the start line.

If you can’t comply with the limitations of agile but still decide to use an agile method, you should definitely factor that into project costs and risks.

Dan comment’s highlights that the main barrier for agile is also the fuzziest one and probably the one that is the least discussed: culture. Indeed agile is first and foremost a mindset. And buy-in from management is a challenge because agile is still often perceived as little more than cowboy programming.


Bruno Collet wrote on January 19, 2009 - 4:35 pm | Visit Link

As a Agile Practitioner with years of experience in large and small projects ranging from 300+ people and entire IT organizations, down to small teams of micro brewers rocking the free world with IPA.

I am so glad you didnt write this years ago otherwise I would have been deprived of some of the most fulfilling and successful work I have ever been engaged in.
Not only do you misunderstand what this is about, you have a complete lack if knowledge as to the simplest and most powerful aspects of the approach.
To anyone reading this understand it is this mindset that limits what can be done.
Yes to the respondent, this is cultural in nature, but organizational in form,
No this is not a methodology. it is a way of getting things done. Not trying as the performance hooey spewed above is attempting to reward. DONE. teams get rewarded because they keep commitments on what they say they can do and what they do. That means, as I tell my clients, that you dont do what you say you cant do even when large shiny objects are dangled in front of you.
Agile is all about self respect coupled with self discipline and it is not about stars or prima donas or gurus. it is about a team of average people who join together to do extraordinary things exceptionally well over long periods of time.

Mike Dwyer wrote on January 26, 2009 - 5:30 pm | Visit Link


Thanks for pointing me to your article after reading the one on my journal. It’s clear that you have thought through the issues and limitations far beyond what I have and I commend you for that.

In my experience, adopting Agile has been an excuse to perpetuate a lack of process and accountability. The unspoken implication is “well, we don’t have any process right now, so why not do Agile, since it seems to dispense with process?” Wrong answer, of course.

To Mike Dwyer: I really think you have missed the point of this article. An Agile methodology does not in itself drive project success, just because it has some excellent techniques as you say. There are certain pre-requisites both organizationally and skill-set wise that are needed before Agile will be successful in a given company or team.

Too often Agile is sold as a panacea by starry-eyed practitioners; it’s like prescribing Aspirin for anything from a headache to a heart attack.

Julian Dunn wrote on February 11, 2009 - 11:02 pm | Visit Link

Thanks for your ideas, I recognized it’s not an easy thing to do, when writing about limitations of Agile Software Development.

To me, Scrum has been chosen as a method which fits well with the Agile way of thinking. It’s obvious that Scrum cannot fit with all type of organizations, but it’s important to understand that each of them can find its part in this method.

When I read the Agile Manifesto, I find it’s all about:
– Reducing Waste
– Increasing Feedback
– Perceiving Integrity
– Increasing Knowledge
– Respect (people are in the center of the process)

I feel this is strongly aligned with the Lean way of thinking.

Agile Software Development is promoted by stars. They are hard worker and brilliant persons bringing the messages of a larger communities of software developers who want to set the standard for the Agile and Professional software developer. This standard requires a lot of works and disciplines from each individual developer, but when this level of skills is reached, the need for a strong methodology is less obvious.

If you want to win a football competition, will you choose in your team, anyone who is able to play with a ball, and then apply a method for winning? (I believed you’ll search for the artists)

Agile Software Development is limited, but in a way that it requires real competence for writing software, not only methodology on processes.

tlp wrote on May 24, 2009 - 10:45 am | Visit Link

I agree with posts above that this is falls in the pre-requisite category. Very good read. I wanted to comment on one reference in the article to what the Scrum Master is. It was a defined role as team leader. That is incorrect.

The Scrum Master is not even in ‘The Team’. In an Agile – Scrum environment there are three roles, The Team, Scrum Master, Product Owner. The Team consists of individuals all equal (albeit they may bring different skillsets developer, analysts etc.) to get the job done. The Scrum Master is someone who facilitates the process and insures that the team is really being ‘Agile’. They are also someone that is a team builder, but they are NOT the leader of the team. As apart of ‘The Team’ one person could be and probably should be elected as the lead to help deal with conflict etc. These are two different roles.

Kirk wrote on March 20, 2011 - 10:30 pm | Visit Link

Thank you for your views, you list exactly the points I hit when implementing such methodologies in my former company.

I have now working on the implementation of agile methodologies and its impacts on business. My belief (which I intend to validate or not) is that most of the time, agile methodology implementation is “engineering” driven, not a strategic move decided at the top of the company. I have the feeling that agile methodologies solve some issues and create new ones. In most of the cases, I am not sure such methodologies lead to a competitive advantage because other functions will resist and, in the end, prevent the company to move toward a “more” agile organization.

Do you have any case I could study where the implementation of such methodologies went as far as leading to a complete reorganization of companies, redefinition of HR strategies and collaboration with other departments?

thank you

Fabien wrote on September 22, 2011 - 5:03 am | Visit Link

Very nice argumentation, but how do I have to agree with your thoughts you made in the last sentence. Could you please explain it again? Best regards Frank

Frank Lange, Entwickler wrote on September 24, 2011 - 4:56 pm | Visit Link

These “limitations” of Agile mentioned here are not limitations of Agile, but of organizations who fail or refuse to change themselves from many of their traditional self-made impediments. There is no use blaming them – those limitations “made sense” (or were recommended practices – like individual rewards as a means to motivate people) in the traditional approach, but there is so much scientific research to prove most of the practices hurtful to true effectiveness of people (e.g. on real motivational things for people in complex environments).

I fully agree on the observation that Agile are not methodologies – they are frameworks of various kinds. Those frameworks provide the structure for the process, but the using organization needs to fill in the gaps (like the things mentioned in this article – risk management, budget etc. – but also with things like engineering practices that make sense in their domain). Some interpret this as lack of process, but it’s just lack of pre-defined choice. Agility requires a lot of discipline, more than the traditional approach, to be frank.

I don’t recognize the Agile spoken here in many regards with the way I understand Agile to be. For example, “the ScrumMaster (Scrum word for team leader) goes around the table and each team member mentions the status of tasks and other issues such as impediments or changes” is contrary to what I teach. SM _does_not_ go around the table. The SM is not responsible for the tasks of the individuals in any way – the team members themselves are. Therefore, in the Daily Scrum, the people themselves go through themselves (in a way they choose) and go through the three questions to share what’s important with the other team members. It’s not a meeting for the SM. If everything goes smoothly, the SM doesn’t have to do anything, and that’s a sign that the SM has done his/her job properly. And if something starts going wrong (or becoming less useful), for whatever reason, then the SM should help the team to fix it and get it working again.

I wouldn’t personally take this blog post as a guide to Agile transitions. It’s more like how to avoid the painful changes organizations would have to face and change if they were to really adopt Agile. And as such this is a great find – it lists many of the central pain points to tackle (in the long run, at least, if not immediately). And many of the suggestions are exactly what a traditionally minded person would suggest as ways to “fix Agile” in their environment. And which very likely lead to failed Agile transformation in the long run, as they’re not aligned with the key principles of Agile. Agile is definitely not easy, and this article underscores that point.

Yours Sincerely, Petri

Petri Heiramo wrote on October 1, 2011 - 12:46 pm | Visit Link

I have been in an XP team for 1.5 yrs and I agree with most of your points. In a sense, this is the level of understanding that anyone practicing Agile needs to have. You may call it pre-requisites/ expectations / limitations but the necessity is to understand them well.

I feel point #1 (on the kind of people) is very important. That is why you always need a mix of methodologies/practices to manage Agile teams that are composed of differently ‘abled’ individuals. In point #6 (on ownership/accountability) I am not sure if you really need to distinguish/evaluate individual performance during reviews. Will your ‘true’ stars under perform if they aren’t distinguished ? Debatable.

Nice post.

Sivasubramanian wrote on January 25, 2012 - 11:57 pm | Visit Link

Urk! Wrong turn.
“When dividing the project into agile-manageable subprojects, we minimize dependencies through architecture.”…”Therefore, the agile definition of “progress” … has to be adjusted”.
Sorry but no. This flies squarely in the face of slicing stories vertically (see and it fails to deliver business value.

If you want an example of how mini-teams can be used effectively, see Michael Dubakov’s excellent report on their team’s evolution

Bob Allen (@CuriousAgilist) wrote on May 13, 2012 - 8:52 am | 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=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories