How Agile is hurting your product

I am a fan of agile principles, and of Scrum specifically. However, the idea that you just need to follow some agile buzzwords and better software will start dropping from your conveyor belt, is misleading at best.

Don’t get me wrong, agile methods are great. In many, many projects, Scrum has helped me to:

  • Increase production speed and focus in my teams
  • Handle management of stakeholder expectations
  • Evaluate and decide on product improvement

Where Agile is not enough

If you believe that turning to an „agile culture“ is enough to make your company compete in a digital marketplace, think again. Agile methods do describe how to get your development teams focused and up to speed. They show the developers how to communicate better and understand stakeholder requirements better. But they do not describe how to create a good product.

Nowhere in Scrum will you find rules on how to make the stakeholders and the product owner (PO) focus on the right ideas and products in order to grow the business. The topics of product discovery and business focus are mainly left in the dark in Agile.

Moreover, since burndown rate, average ticket size, sprint capacity and spillover are indicators that can and will usually be measured in an agile environment, they will also become the main objectives of your team. Humans tend to focus on what they measure.

84% not focused on product

Yes, Scrum does claim that a PO should be a proxy for the customer. But it leaves totally unclear how to do that. In an ideal world, he or she would be investing 80% of their time into product discovery and be helped by the entire team in that. But the reality, as a recent study by the customer feedback experts at Alpha HQ shows, is the opposite: a whopping 84% of all Product Managers say that they have „no time“ or „too little time“ to run product experiments.

Is your company feeling all agile?

Why is that? Scrum demands that the PO be responsible for creating an organised backlog, writing clear user stories, taking part in sprint planing and regular meetings. Thus, the PO rarely has enough time to do all the discovery work by himself and keep the team guided at the same time. Moreover, some stakeholders might even be interested in keeping the PO at bay in order to protect their valuable ideas that they want to see implemented.

Since many processes inside companies are aiming to raise efficiency in code creation instead of user effectiveness, it may well be that the company is absolutely happy with this and is feeling all „agile“ and „customer centric“, while at the same time creating little value for the customer.

The keys to real change

So, what is the solution? If real change is the aim, then you should absolutely keep your Agile environment! However, introduce the core features of product discovery, specifically:

  • Focussing on business metrics (instead of efficiency metrics)
  • Defining success by outcomes (instead of features)
  • Implementing Continuous Integration (CI) instead of release planning
  • Driving structural change towards customer-centric development (instead of line responsibility)
  • Empowering teams to reach their goals by any means (instead of „Not how we do it here“)