As discussed in an earlier
article, Agile methods have a number of advantages but it isn’t always the
right approach for every project and is heavily reliant upon the team you use. As
much as Agile is a process it is also a mindset- deployed as a way of managing
the relationship between developers and you the client.
While the general acceptance is
that Agile is faster, more effective and cheaper, like any project results can vary
greatly. I’ve seen countless examples of business coming to us having been let
down by other developers who failed to correctly deploy Agile. In order to get
to the bottom of why Agile projects fail, you need to understand when Agile is
not suitable for you, because for many clients (and all too many developers),
they simply do not understand Agile and the consequences of adopting it.
At Synetec our management team have
over a decade’s experience of managing successful, complex Agile projects and
delivering value. Having also seen the results of where other developers have
failed, we have come up with three simple tips for understanding when Agile is
not the correct approach for your project:
When the client doesn’t have the time to take ownership
For some financial service
clients, in particular their fund manager’s time is like ‘gold dust’. This
means getting client and user ownership of the project can be incredibly
difficult, particularly when feedback is required during the ‘sprint’ sessions
on Agile.
With the success of Agile
depending on an effective partnership between Synetec as the development team,
you the client and your end users- communication is key. Whilst day-to-day
interaction isn’t necessary, regular two-way communication is for some clients
just too disruptive and inconvenient. If this partnership approach won’t work
for you, then an Agile project will prove complicated and will come with higher
risks.
When your developer has a smaller team
While an Agile project requires highly
skilled individuals; it more commonly requires skilled teams. These teams will
usually include business analysts, developers and project managers, with
knowledge of model-driven development and all with excellent communication
skills.
Because of the structure of
Agile, it may simply not be as effective or suitable for smaller 2 to 3 man
development teams. With teams this size it is usually easier and more effective
to split the team and workload to manage the sprint backlog collaboratively.
What we find with larger development
teams of 10 plus for instance, are that they are better utilising individual complimentary
development skills; meaning the project is spread more widely between the team,
and Agile is thus more effective in ensuring collaboration and communication.
When speed is what really matters
When developers are up against
tight time constraints (usually less than 3 months), our experience has taught
us that it is usually faster to develop in Waterfall where you can sacrifice
flexibility for speed.
As Agile projects involve increasing degrees of business functionality through regular iterations, speed can at times be an obstacle. When you’re looking for developers, remember to consider the size of their retained team; if they don’t have the resources to meet your desired changes this can lead to unacceptable delays. If you have a fixed deadline, and time to market is what really matters, then most developers would advise that the waterfall methodology is a more effective option.
Conclusion
The table below gives a brief insight into the role of the client in the Agile v Waterfall process:
The table below gives a brief insight into the role of the client in the Agile v Waterfall process:
Agile
|
Waterfall
|
No comments:
Post a Comment