In the last blog post, we identified the strengths of Agile: speed-to-market; higher quality development; transparency; etc. So this week I’ll address the underlying weaknesses of Agile, all based on experience, keeping in mind Agile is a framework designed to be adapted to the conditions of its environment
1. Agile, with its backlog of stories and the incorporation of product owners, somewhat implies someone has figured out what the end result should be. In our seven years of Agile experience, the user knows no more than 80% of the necessary go-live requirements for an implementation and 60% of the necessary go-live requirements for new application development. In most situations the users and product owners don’t know what they don’t or should know.
Implication: No different than waterfall, one can and should expect the backend of an Agile project to have the same historic issues raised by the business and the users – the unavoidable “I gotta haves” or “we need this included before we can go live” feature/functionality
2. Agile has a tendency to marginalize the complexity of an enterprise project. As a result of this, the testing process is de-emphasized, especially system test, integration test and UAT. Experience has taught me if the user doesn’t know what it doesn’t know (my first point in this blog) then the backend of the project is going to have its issues, and these issues will surface during the testing phase. Furthermore, more issues at the backend means more defects in a condensed timeframe. Agile doesn’t handle these types of project outbursts very well.
Implication: It’s our recommendation an independent team of developers and testers, separate from the core agile team, are used for comprehensive testing and defect resolution. This team generally operates with a Waterfall or Hybrid-Agile methodology.
3. Agile is an effective and aggressive methodology for Phase 2 and beyond projects. (It can be this way because Phase 1 has set-up Phase 2.) The problem with Phase 1 Agile projects is the lack of readiness with the business and IT. Backlogs aren’t built. The minimum viable product is not established. Product Owner’s aren’t versed on the product. Consequently an Agile project can easily and often gets behind early in the plan. The typical response is to ratchet-up velocity. When velocity needs to accelerate to solve a readiness problem, it almost always crashes onto the development team.
Implication:The backend of an Agile project, especially Phase 1 Agile projects, typically gets very intense for development. More intense than a similar sized Waterfall project. To prevent this it’s best to do a readiness assessment prior to starting development. Check the quality of the backlog, the knowledge of product owners, level set on velocity expectations and time commitment of the business to the project.
The above points are examples that Agile experience and know-how hasn’t yet caught up to Agile theory. Agile is good. It’s good for IT and it’s good for the business. It solves a speed-to-market issue while pushing everyone to a common goal – the success of the next sprint. The problem with Agile for the less than experienced team is it’s unforgiving. It’s relentless. It’s in front of you every minute of every day. It becomes and is your only #1 priority.
In our next blog post, “Enterprise Agile Conclusions,” we will discuss if agile practice will ever meet agile theory. Stay tuned!