Don’t do Scrum projects

Why scrum might not be the best tool for your company.

The difference between project and product management can sound like contrived management “bullshit bingo”, but it’s key to understanding why most IT projects fail.


  • Have a limited timespan, preferably in the order of weeks/months.
  • Have a clear end-result that is known upfront.
  • Have a small team dedicated to delivering.
  • Are relatively simple.

Examples : upgrading your servers to a new version of the OS, making your website accessible to the visually impaired, automating end-of-month reporting, migrating to a new back-end system…


  • Are intended to be long lived, often years.
  • Have a clear goal, but the end result is unknown upfront. It’s a matter of learning, experimenting and growing.
  • Have a slightly larger cross-functional team that investigates, builds, runs and owns the product.
  • Are relatively complex.

Examples: Increasing online sales through improved user tracking, building an assistance tool for your helpdesk employees, building a better knowledge sharing tool for your organisation, …

Scrum is cut out to tackle Products. The entire framework is set up to encourage iterative feedback and learning. Each sprint builds on the new understandings of the problem and moves in the direction of solving it better. Since we are discovering a better solution, we take our time and don’t expect immediate results. Products grow in the course of their life.

On the other hand, Scrum is awful for Projects. Since you already know what you’re going to build, there is not much need for iterations and learning. Sprint planning, retro’s and demo’s quickly become mere overhead. New discoveries are either ignored or lead to halting the project. Change is not welcomed. That’s why projects move fast.

There is an unfortunate scenario that we encounter way too often in the industry. It’s that middle ground that combines the worst of both worlds : the Death March Scrum Project.

  • They are long lived, often multiple years
  • They have a fixed scope that is stuffed in an overfull backlog from the start. The people initiating this project think they know what they want upfront and don’t care about learning.
  • The team is put together to build the thing and consists of specialists in their respective silo’s. It’s oversized by definition. At the end of these years, they will hand it over to a support/operations team and this will magically not be problematic.
  • The scope is a highly convoluted enterprise Big Ball Of Mud that nobody really cares about.

It’s not a discussion about Waterfall vs Agile. It’s about picking the right tool for the job. If you are currently struggling with Scrum, maybe you’re working on a Project instead of a Product?

If you are working on a Scrum Project, it’s time to stop and revise your organisation.

Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.