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?
- A business unit saw the value of Agile in late 2009.
- They did not hire any outside coaches or consultants, but instead had internal resources begin the processes of transitioning to Agile.
- The “Agile Owners” decided to choose a tool before solidifying a methodology.
- The business bought a very expensive enterprise Agile tool.
- Developers began putting story cards into the tool on any work they did.
- Stories were poorly written.
- Hard set 2 week sprints were put together without iteration planning in place.
- There were no defined Product Owner roles.
- Projects continued to elongate and scope continued to creep.
- The business still wanted full featured products with heavy requirements documentation up front.
- Design and UX was an afterthought.
- A training memorandum was sent out to Transition From Agile.
- Project analysts would go through training to transition back to a very heavy waterfall-style methodology on 10/22/2010.
- Less than a month later, talks about Agile began to resurface after a business reorganization.
- 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:
- 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.
- 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.
- 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.
- 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:
- Grab a good book on Agile and dive in. Understand what Agile is, and what it is not.
- Take a hard look at your business and identify people who can champion Agile.
- Understand your team dynamics – Does Agile (at this time) make sense?
- Where are small areas of your business that would benefit from some Agile practices (sprints, standups, prioritized backlogs, paired programming, co-located teams, etc)?
- Put together a game plan for achieving small wins within your team and build upon that momentum.
- Just do it. Take a part of Agile and execute. Your team will thank you.
Other suggestions? Let us know in the comments.