Professional Documents
Culture Documents
Limitations of Agile Software Development
Limitations of Agile Software Development
______________________
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:
− 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.
3. Small team
Agile teams are restricted in size for several reasons:
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:
− 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.
− 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.