The world is moving faster and faster and to keep up as a company with your competition, you need to be able to deliver valuable solutions to customers faster and more often. The popular way to facilitate this, is by having an Agile way of working and adopt an Agile framework like Scrum. But when Scrum is adopted at a company, people are often disappointed by the lack of increase in speed and the inability to meet deadlines. They’ve heard stories about how Scrum lets you accelerate and deliver more value and faster in comparison with a waterfall way of working, but don’t see so much result of it.

Improving output

Often a lot of attention goes to the velocity or the output of a team. And since we want to accelerate, the best way to do that is by increasing the velocity of the team, right? That means making the team work more efficient, eliminate waste and removing impediments. This will probably give you an initial boost in velocity but will stabilize after a while once the team members are used to working together.

Only putting effort in increasing your velocity for making important deadlines is not going to cut it. Yet I’ve seen time and time again that a lot of attention is given to this, not only by management but also by Scrum Masters and other people. And it is not that strange since velocity is one of the things most often measured, but it’s not that effective.

Scrum is not a way to magically work harder or faster. It focuses on outcome instead of output: maximizing the value that the development team produces. Therefore, the most effective way to deliver more value is by focusing on what the development team is working on.

Cutting features and MVP’s

One mayor principle of Product Ownership is that it is important to work on the most valuable things first and get rid unnecessary features. But when it becomes apparent that developing all wanted features takes way too much time, you must do something. And that’s when we often look at the Product Owner to make a tough decision.

To “help” the PO, the concept of MVP or Minimum Viable Product comes into play. Scrum Masters for example facilitate Story Map sessions to create the thinnest slice possible of the product and call that a MVP. In my opinion, MVP is the most overrated and misused term in the Agile world. Instead of using it for what it’s meant to be (discovering if your assumptions about your product and customers are correct), it’s used as a mean to cut down in features just to makes thing fit. You end up with a crippled product that is anything but viable and you still need to do additional work before it can be used by customers.

What MVPs often look like: a tiny bit of everything that doesn’t satisfy your needs.

What does help?

Improving the efficiency of teams or keep cutting features is not going to make a big difference in delivering the most value possible. The biggest difference comes from unleashing the brain power from the development team to come up with fit solutions that give you the functionality you want given the constraints you have (of which time is one of them). If a development team uses its creativity to come up with better solutions, it allows for an order of magnitude in difference in value delivered and transforms them from a good production team to a great innovative team.

Unfortunately, my experience is that teams are not there yet and don’t know how to get there. In my next blogs, I’m going to elaborate on a couple of practices you can use. These are:

  • Come up with alternative solutions instead of slimming down functionality
  • Use estimations and deadlines as signals to think about different solutions
  • Create scarce in time and people
  • Learn and apply those learnings to change your solution if needed

To be continued!


This blog was written by Harm Pauw.


Please enter your comment!
Please enter your name here