Geeks With Blogs


Dylan Smith ALM / Architecture / TFS

I’ve worked with a lot of teams who have tried to adopt Agile and failed.  There are many reasons why this happens, but I tend to see a few very common reasons crop up over and over.  In particular there are 3 that I see clients struggle with all the time:

  1. Lack of focus on technical practices
  2. No agile experience on the team
  3. Missing buy-in from upper management

I’m going to try and tackle this in a 3-part blog series.


Lack of Focus on Technical Practices

When I talk about clients trying Agile, what I really mean is companies trying Scrum.  The *vast* majority of companies I work with that try to go agile, are really trying to adopt Scrum.  For most companies Agile == Scrum. As I’m sure you all know, Scrum says absolutely nothing about technical practices.

The Waterfall Approach

Let’s step back a moment and look at what happens on countless waterfall projects.  The team goes through an extensive requirements gathering phase, trying to capture everything possible to avoid rework later.  Then there is a lengthy design phase, where software architects come in and try to design an elegant software architecture that can handle the very detailed requirements.  And to be fair, a lot of them do an excellent job at this task.  I have no beefs with the ability of these architects, or the quality of the designs they produce.  They often come up with very effective software architecture/design to satisfy the requirements.

Then the problems start.  As development gets under way, edge cases that were never considered are discovered.  Requirements that don’t make sense are found.  Additional capabilities need to be developed.  None of these things were accounted for in the original design phase.  Rather than re-visiting the architecture, it is contorted into doing things that weren’t originally envisioned, features are tacked on, and technical debt grows.  Despite this, the development team usually manages to make things work and eventually gets to feature-complete.

Then the users get their hands on the software, and all hell breaks loose.  The software doesn’t meet the business needs, requirements were misunderstood, the design doesn’t satisfy the business needs, and lots of rework is required.  Again, none of this rework was taken into account in the original architecture, so it is bastardized some more to make things work.  The dev team that implemented it is probably still all around, and they are pretty familiar with the code base since they just wrote it, so they are able to hack away and make the necessary changes.  Again racking up massive amounts of technical debt.

Then the software goes into maintenance mode.  Over several years more changes are needed, the design is hacked away at.  The original developers move on to greener pastures, and the new developers don’t understand the original design, and hack away some more.  Eventually things get really bad, progress on new features slows to a crawl, the software becomes fragile, people are afraid to touch large areas of the code-base.  And after maybe 5 years (if they’re lucky) the team starts considering a total re-write.  This time we’ll get things right they say.  Inevitably, the same story repeats, and the endless cycle of 5-year rewrites continues.

The “Agile” Approach

What do you think happens when these same teams attempt to adopt Agile/Scrum?  Rather than spending a lot of time gathering extensive requirements up-front, just enough are gathered to get started.  Just enough architecture activities are done, and development proceeds.  Now, rather than developing in isolation for a year, and discovering a few missing requirements, followed by deployment and a bunch more rework; requirements never considered in the original (brief) architecture efforts are introduced every 3-week sprint.  Hacks are made, and technical debt accumulates MUCH more quickly due to the rapidly changing nature of requirements on an agile project.

Instead of the 5-year rewrite cycle on Waterfall projects, the agile code-base can often deteriorate within a year.  Sometimes before the 1st major release is even made, the code-base gets to the point where teams have to throw it away and start over.  This process of code-rot and technical debt accumulation is only accelerated on agile projects if nothing is done to aggressively address it.


The Solution

The solution is that in order for teams to be successful adopting Agile, they must adopt more mature technical practices in tandem with the Agile work management practices.  In particular, teams must be laser focused on keeping technical debt under control through aggressive refactoring, and automated testing to enable refactoring with confidence.

The team must be continually refactoring and improving the design, as they adapt to changing requirements and demands on the software.  I won’t go over specific practices in detail here, but the common failure of teams is to think that they can adopt the Agile work management practices, without also focusing on adopting (much) more mature technical practices.

Posted on Tuesday, December 3, 2013 4:44 PM | Back to top

Comments on this post: Why Does Agile Fail?

# re: Why Does Agile Fail?
Requesting Gravatar...
About waterfall:
Requirements are NOT simply gathered. Analysts study the problem and the problema area. This insight and clarity is crucial to come to more stable requirements. There is no reason why the design phase should be 'lengthy'. Why is this proper to waterfall?
If the analysis has been done correctly, no fundamental changes are to be expected. Independently of the impact of required changes, the project manager and his team needs to deal appropriately with it. The way you depict is is an inappropriate way. Again, this has nothing to do with the waterfall.
Business people, including end-users can be involved from the very beginning. Waterfall doesn't prevent this. There should be 'testing' during all the way. This starts with the analyst checking with the business whether he understands the problem correctly, wether the requirements are well-understood (on both sides), and so on.
Changes made by the team should be done appropriately. Again, this has nothing to do with waterfall but with the people.
I can go on and on. All these 'arguments' have NOTHING to do with waterfall at all. What does Agile trying to solve? What does Agile do with the REAL learned lessons of decades of waterfall? That's why Agile is doomed to fail.
Left by Axel on Jun 19, 2014 5:36 AM

Your comment:
 (will show your gravatar)

Copyright © Dylan Smith | Powered by: