The Danger of Agile Theatre

There are so many people and businesses that are adopting “Agile” as an approach to Product Development. I have these discussions with Product Managers who are often struggling to get their products or product enhancements to market because they are being told how to interact with a development team and are not getting the results that they need for market and business success.

The principles that Agile Software Development are framed around are fantastic and have the potential to achieve “Product/Market fit” in less time and will allow a high performing team to maximise their productivity. I am a fan.

Unfortunately the label Agile is being misused. Instead “Agile Theatre” is everywhere. You can observe “Agile Theatre” where the participants are pretending to be “Agile” because they are using User Stories, Stand-ups and a Planning Wall of index cards. However, the promised benefits of REAL customer and business value faster are not being realised.

Instead the high level intentions of Agile thinking and it’s benefits are so often corrupted or ignored as they are replaced by methodology dogma at the tactical implementation level of an overall Product delivery process. For example,

  • The software team is the only Agile part of the overall Product Delivery Team.
  • Product releases are never worked on a second time to improve them following market feedback
  • Product backlogs are prioritised for the ease of development and not for Business/Market Value
  • Businesses rush to build solutions first before validating a true market value hypothesis

These are just a few real world examples that I have seen recently that drive me crazy. These kinds of behaviours have the exact opposite effect to the success of a business, causing confusion, internal friction between Agile and non Agile teams, launch delays and an increase in organisational overhead without any pay off. This is further exacerbated by the misuse of the very good ideas presented in The Lean Startup (by Eric Ries) book, that is distilled down to the oversimplified language of BUILD/MEASURE/LEARN, MVP and “Fail Fast” by people who are too lazy to actually read and think about how to properly implement the ideas in the book.

These faked Agile and Lean approaches tend to ignore:

  • The very real, hard work that is required to test an assumption with the market place before any development commences.
  • The additional cost of acting on market feedback and working on the same user story multiple times to get iteratively closer to a better solution for the market.
  • The extra effort required to stitch together the parts of a product that were developed separately, one user story at a time.
  • That real testing is done with the customer and passing acceptance criteria is only the first step.

This continued misuse of the terms Agile and Lean to justify lazy and hard to track work practices. Instead Agile thinking needs to be applied in terms of the outcomes it is trying to achieve.

I would love to hear your thoughts in the comments below.