Limitations of Agile Software Development

January 14, 2009 Bruno Collet, MBA

Independent Project Manager & Auditor
bruno@brunocollet.com
www.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 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.

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 1

www.brunocollet.com
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).

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 2

www.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 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:

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 3

www.brunocollet.com
 − 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.

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 4

www.brunocollet.com
 − 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?

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 5

www.brunocollet.com
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.

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 6

www.brunocollet.com