In our last episode we heard our dear Gurufix and Bigboss discuss KANBAN and SCRUM. SCRUM being all over the place Bigboss would love to use it to show off. Gurufix was less convinced that this is a good idea and here are 10 good reasons why it also may fail for you.

Based on my experience I have drawn a list of issues that will make SCRUM fail in your company. If only one of those is valid for your company, you’d either get it fixed or chose another Agile approach e.g. KANBAN.

BTW, if I speak of customers, that means external as well as internal customers.

Now, let’s get started.

For those who have missed the episode where Gurufix explained the 2 AGILE methods you must know …
Don’t worry, grab the

previous episode here!

Reason 1: You have no multifunctional team members available

One of the bases of SCRUM is that team members balance tasks between them to make sure the overall objectives of each SPRINT are met. Therefore, a team of programmers with some overlapping and some specialist knowledge usually works well.

Why? Because the load balancing effect will level out unforeseen difficulties on one task, taking advantage of other tasks being easier than expected. And with team members being able to take over different types of tasks you fully benefit from load balancing.

On the other hand, having a team organised by distinct functions like development, purchasing, quality control, etc. will not do it.

Why? Because team member A will have to do what is planned for him and there is no possibility to shift tasks to member B or C if things take more time than expected. Ergo the load balancing does not work.

Reason 2: You love to shift priorities

If you love to change priorities for your team members, SCRUM is not for you.

SCRUM is organised in SPRINTS, which are periods of 2 to 4 weeks where the team works on tasks it has defined itself and the members have committed to finish by the end of the SPRINT. And that’s what makes it work.

Therefore, management must not interfere with the tasks the team is working on during this period. Order to do something unplanned then over time the team will become frustrated and will lose commitment. Whatever they planned, they will not be able to finish because of changing priorities from outside, so why commit to anything at all?

Are you ready to let the team do its work for 4 weeks in a row, without changing their priorities? If not, then don’t go for SCRUM.

Reason 3: You need a GANTT chart from beginning to end

In SCRUM you have a product backlog, but this won’t tell you when the product will be finished. You even do not know what product you will get at the end, because your customer will define this for you.

But seriously, SCRUM brings a high level of open uncertainty. So, the question to ask yourself is whether you, your bank, your customer and all the other stakeholders can cope with that.

Some people just need to see a GANTT chart and believe in it to feel OK. Even if, you know as well as I do, that this just hides the uncertainty and reveals it in digestible bites.

Reason 4: The team is not ready for self-organisation and responsibility

Taking responsibility is not for everyone and believe it or not there are people who at work prefer to receive orders and execute them to their best abilities. They do not want to be responsible and it seriously bedevils them if you ask them to organise themselves and take responsibility for their decisions.

In SCRUM the team choses the tasks to work on in the next sprint and declares itself responsible to achieve what they told they will. People inside the team who decline responsibility but prefer to hold the other people, the environment, the boss, etc. responsible for failure will seriously harm the team performance.

Reason 5: You are not ready to give responsibility to the team

That is the other side of the coin. Are you ready to give responsibility to the team? You are the boss, right? So, you decide, and you are responsible. You are in fact the only one who can do things on a level that is acceptable. So, for most part you rather do it yourself and work 90 hours instead of delegating responsibility. If that is your approach SCRUM will invariably fail!

For SCRUM to work you need to give responsibility to the team and let go.

Reason 6: You are afraid to involve your customer deeply

SCRUM is all about implying the customer at each and every step of the process to gain his feedback and adjust your approach. The customer’s business needs are the focal point of the project. If done right this will lead to a much more satisfied customer. And that’s what you strive for, don’t you?

But the flip side of the coin is that you lose a good part of control over the project and the outcome. Also, the negotiation of additional cost can be daunting, because there is no document which exactly says how the final product will look like, which leads us to reason 7.

Reason 7: Your customer requires a contract with a precise description of the end-product/ -service/ -state

SCRUM is based on user stories and requirements in the form of a product backlog. This basically says how the end-result is supposed to “behave” from a user’s point of view. This is not a product description. To illustrate this point, let’s say you describe a door opening mechanism. In classical project management you might say “an alloy handle that when pushed down by 45° will action a four-bolt locking mechanism, through a stainless-steel pin…”. I think you get the point. In a product backlog SCRUM type this might read “an access in the wall that can be closed and reopened, locked and unlocked by the user using one hand…”. That is very different!

In SCRUM the final product unfolds during the Sprints and the back and forth between product increments given to the customer and his feedback.

So, if your customer insists on a negotiated and fully described outcome as part of the contract, SCRUM will be ineffective, and you lose time and money. You can maintain some agility to be able to react to customer change requests with ease, but then KANBAN or something similar will be much more adequate.

Reason 8: You cannot give incremental product updates to the customer after each SPRINT

The main benefit of SCRUM comes from giving incremental product updates to the customer after each SPRINT to get immediate feedback and avoid running in the false direction for extended lengths of time. Now this being a great idea it is clearly not feasible for all kind of products all the time.

This concerns products requiring investment and an extended building phase e.g. houses, cars, machinery, etc. In all these cases a definition phase, where you can be very Agile and you could use SCRUM, is followed by a building phase, where changes will be more and more costly and difficult to do, and SCRUM would be a waste of time.

Reason 9: Your customer has no resources to give you quick efficient and regular feedback

As said in reason 6, the main benefit of SCRUM lies in giving incremental product updates to the customer after each SPRINT to gain his feedback and adjust your approach.

Therefore, your customer must provide competent people to evaluate the product increment and give timely feedback. There is no use in handing over a product increment every 3 weeks and then wait for 6 months for feedback. This won’t work.

So, make sure that your customer understands his implication in the process and commits to their part.

Reason 10: You also need a part of waterfall type project plan

I already said that SCRUM and GANTT charts do not live on the same planet. I urge you to refrain from using SCRUM if a part of the project is in waterfall style and both parts depend on each other. In contrast to techniques like KANBAN who can easily be combined with waterfall approaches SCRUM is a stand-alone method.

The strength of a waterfall planning (aka GANTT chart) is that it easily allows to orchestrate different tasks which depend on each other.

With SCRUM you do not know which output you will get and when you will get it. It’s like directing an orchestra where some of the musicians do a jam-session and some play a traditional piece of music. Will not sound nice!

Now it’s your turn!

Did you recognise one or more of the points I mentioned? Do you think, based on the insight you gained SCRUM will be right for you? I am curious to know which of the points touched a string. Thank you to put this in the comments.

And by the way, if you have a question, then you can simply ask me, for free. Try it now.

You missed the last episode? It’s here!

!!! FREE DOWNLOAD !!!

The 6 Questions To Ask BEFORE Taking Any New Project On
This guide will walk you through a waterproof onboarding process for new projects. It will not only show you the questions you need to ask yourself, but also what to do depending on your answer to each of these questions.

Get This FIRST AID kit now!!!