• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
 
 Limitations of Agile Software DevelopmentBruno Collet, MBA, Independent Project Manager & Auditor 1www.brunocollet.com
Limitations of Agile Software Development
January 14, 2009
Bruno Collet, MBA
Independent Project Manager & Auditor 
bruno@brunocollet.comwww.brunocollet.com
Owner, Synapsys Canada 
www.synapsys.ca
Check the free Agile audit tool
Agile Benchmark
at www.agilebenchmark.com ______________________ 
This document is a compilation of posts from my blog Execution in the Information Age (www.brunocollet.com/blog).
Agile has become so popular among software professionals that we sometime refrainfrom criticizing it for fear of being tagged as "behind", "old school" or downright stupid.Fortunately, experienced IT professionals know better and acknowledge that Agile haslimitations.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 wequestion the assumption that Agile was indeed superior to traditional methodologies?Although many projects using traditional methodologies failed, many others weresuccessful. Do we have reliable evidence to back the assumption that Agilemethodologies 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 specificsituation?In order to try answering these questions, we have to look at the limitations of Agile.
 
 Limitations of Agile Software DevelopmentBruno Collet, MBA, Independent Project Manager & Auditor 2www.brunocollet.com
1. A team of stars
Agile has been designed by experienced, smart, and high-achieving people. A friendwisely pointed out to me recently that they naturally designed agile for people just likethem: stars. Not everybody's a Martin Fowler, a Ron Jeffries, or a Jeff Sutherland. Youcould have given them any project, with waterfall method or even no method at all, andthey would probably have succeeded. Indeed, not every group can be motivated,experienced, and skilled enough to self-organize into an efficient team, come up withlightweight processes, and collaborate seamlessly to achieve that great agile teamwork.Take average individuals in you workplace and imagine what would be the outcome ifyou trusted them to self-organize and to choose the best way (at micro-level) to reachthe desired result, without any close supervision. You might be quite disappointed. I'mnot saying that individuals are not qualified, I simply emphasize that it takes more thanthe 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 cannotbecome agile. It means that there might be some intermediate steps to take beforegetting there. In my opinion, these steps typically involve adapting the work culture byprogressively 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 30years old with blue hair, job definitions were broad, and processes were definedindependently by each team. In another one, respecting the chain of command and jobresponsibility were keys to survival, and it took me a couple of days to go though thecompany's policy manual. This illustrates two diametrically opposed cultures. Which onedo you think is more suitable to implement an agile team?Enabling agile behavior requires a great dose of individual and team freedom. Ittranslates into cross-functional, constantly adapting work, and switching roles asneeded. 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 withagility. These characteristics form the organizational culture, which pervasivelyinfluences all work and behavior throughout the organization. Unfortunately manycompanies still apply these industrial-era principles. To make things worse, changing theculture 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).
 
 Limitations of Agile Software DevelopmentBruno Collet, MBA, Independent Project Manager & Auditor 3www.brunocollet.com
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 whocan work in relative independence. This is also how large, rigid companies enableinnovation. Indeed innovation and agility are deeply intertwined. Successfulorganizations are
ambidextrous 
.What can you do if agile doesn't suit your organization culture? The easiest solutionwould be to set up a team that can work independently from the rest, and is not subjectto the same rules. People in this team should be fresh hires or should not fit well withinthe traditional organizational culture. But on the long term, changing the culture implieschanging leadership. Assuming that people can change only to some extent, you knowwhat 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 fromtemporary chaos. Obviously this process would be too long for larger teams.
−
Team members have to be able to communicate spontaneously with each otherand 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-functionalperspective, team ownership), help each other with ease, and collaborate withoutcentralized 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. Thedaily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrumword for team leader) goes around the table and each team member mentions the statusof tasks and other issues such as impediments or changes. I managed Scrum teams ofsizes 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 naturallyextends to project size.Fortunately, there are solutions to somewhat alleviate this limitation. If a large projectcan be divided into a number of relatively independent smaller subprojects then eachpart can be implemented by an agile team. However, this solution is not without its ownquirks:
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...