A Failed Agile Program – A Story

The Training Schedule you see above is not only true, but a great example of when a business unit fails to support an Agile initiative.

So what happened?

  1. A business unit saw the value of Agile in late 2009.
  2. They did not hire any outside coaches or consultants, but instead had internal resources begin the processes of transitioning to Agile.
  3. The “Agile Owners” decided to choose a tool before solidifying a methodology.
  4. The business bought a very expensive enterprise Agile tool.
  5. Developers began putting story cards into the tool on any work they did.
  6. Stories were poorly written.
  7. Hard set 2 week sprints were put together without iteration planning in place.
  8. There were no defined Product Owner roles.
  9. Projects continued to elongate and scope continued to creep.
  10. The business still wanted full featured products with heavy requirements documentation up front.
  11. Design and UX was an afterthought.
  12. A training memorandum was sent out to Transition From Agile.
  13. Project analysts would go through training to transition back to a very heavy waterfall-style methodology on 10/22/2010.
  14. Less than a month later, talks about Agile began to resurface after a business reorganization.
  15. An Agile coach was brought in to consult.

What could have happened differently?

After some research, what was uncovered as the reasons behind the fall of Agile were as follows:

  1. Disinterested and disengaged business ownership – Dictating a project or department go Agile but not provide the needed feedback and support from the business to support the initiative.
  2. Ill-informed and poorly trained “Agile Owners” – The handful of Agile Owners learned about Agile (Scrum) on the fly and instituted ideas to the teams that weren’t fully understood or implemented correctly.
  3. Lack of Product Ownership or voice of the customer – Product Owners or business SME’s were not available for constant engagement with the team to build the backlog, course-correct, or provide guidance and vision to the project.
  4. Poor communication enterprise-wide about the initiative – The development team knew they were to go Agile, but corresponding and linking business units did not know what was happening or changing.

Are there many other reasons this business unit failed at achieving agility in an “Agile project?” Absolutely, but during the analysis and post-mortem of the project, the four main reasons above seemed to be the buckets in which the failure was most attributed to.

Some may ask: “Is hiring an Agile coach the answer, then?” Possibly, but it may not be the long term answer. Scaling the enterprise is a very tough road. There are books inches thick about this subject and we recommend taking a good look at some of them (i.e. Scaling Software Agility: Best Practices for Large Enterprises).

We would recommend a couple things when considering going Agile:

  1. Grab a good book on Agile and dive in. Understand what Agile is, and what it is not.
  2. Take a hard look at your business and identify people who can champion Agile.
  3. Understand your team dynamics – Does Agile (at this time) make sense?
  4. Where are small areas of your business that would benefit from some Agile practices (sprints, standups, prioritized backlogs, paired programming, co-located teams, etc)?
  5. Put together a game plan for achieving small wins within your team and build upon that momentum.
  6. Just do it. Take a part of Agile and execute. Your team will thank you.

Other suggestions? Let us know in the comments.

10 Replies to “A Failed Agile Program – A Story”

  1. I would recommend hiring (or contracting with) both engineering and business team members who have experience working with agile. This might sound self serving as a consultant myself, but it makes common sense.

    I think people assume that process changes are easier than technology changes. In reality, process changes can be just as disruptive, both positively and negatively. When a company with Java programming expertise decides to, for example, start a Ruby project, the first thing they do is look for Ruby talent — having folks on hand who’ve done it before is a good idea. This same logic applies when switching from non-agile processes to agile processes. As with technology having some good books help, but books are no replacement for experience.

    1. Totally agree with you here. There are way too many reasons to count and even much more good advice that could have been used to lessen the failure of this particular project. Sometimes augmenting a team with experience does make sense, and PAIRING them with on-site developers who know the ropes. Makes complete sense!

  2. Would be interested to see what P, Q, R, S,T, etc. read like! I am usually brought in to an organization well after they have gotten into “doing” Agile. Wonder if it is anything like:

    P. Coach goes around and talks to key people involved in the exisiting Agile effort.
    Q. Coach comes up with a set of recommendations for improving the experience folks have had and/or are having.
    R. Organization proceeds to tell the coach how they have “tried that before” or why they’d “like to do that” but “can’t at this time.”
    S. Organization has a meeting to discuss how to “adapt” (some of) the recommendations.
    T. Coach is asked to “train” all the people, especially contractors, who have not attended (even weren’t allowed to) the official organizational Agile training.
    U. Coach is asked to work closely with a subset of teams (~ 30 people each distributed over 6-7 locations in and outside of the country).
    V. Organizations thinks some more about the recommendations while they set the deadline and fix the functionality for the next release.

  3. It’d be interesting to get a bit of back story about why Agile was chosen. Sometimes it’s because some C-level magazine had a piece about it which glosses over the actuals and just does a fluffy description of it. The C-level person comes in a drives the project, until the next interesting thing comes along to pique their interest.

    Without good support from Management down something like this won’t work. Unless it’s surreptitiously put in place by a Project Manager level person and just hidden from external forces.

    I think Agile practices work better from bottom to top. If the team wants to go with Agile methods, then great, otherwise most top down approaches tend to just fall flat except in the best organisations.

    1. I agree with you here Jim. Most teams are 110% on board with Agile. It just makes sense. Who, as a developer, doesn’t want to push value faster?

      It would make sense that the development team could show the value to the upper management in due time after practicing some Agile within their team.

      Agile, for some top management, see it as something they can do for their teams, but rarely want to be the “owner” of that initiative all the way down, with it’s bumps and problems that will happen over time. Doing enterprise Agile is a long-term investment!

  4. Pingback: Project Management At Work » Blog Archive » Weekly management news roundup: Common mistakes in Agile adoption; Creating and sustaining Agile culture; Key barriers to Agile transformation, and other interesting posts

Leave a Reply