The Insufficiency of Scrum is a fallacy

By | 2013-05-21T04:00:50+00:00 May 21st, 2013|Process, Scrum|4 Comments

The insufficiency of Scrum is a fallacy perpetrated by teams that don’t step up their practices in concert with their planning and don’t really want to make it work anyway. You can fail doing Kanban, XP, Merise, and SSADM just as easily, unless you have good engineering practices as well.

The goal of Agile is to have you fail sooner and for it to cost less. So what happens when you try to make your management practices more agile but forget about your engineers’ practices?

Well José Manuel Nieto contacted me on twitter after joining a team that was suffering from what he called The Insufficiency of Scrum and asked for thoughts and after a conversation some advice.

@mrhinsh Hi What do you think about the thoughts I published? “The Insufficiency of SCRUM”

— José Manuel Nieto (@SuperJMN) March 23, 2013

When we fail at something it is only human to look for something to blame other than ourselves as the implementers and the things that we did not take care of.

We have to accept the fact that no process is perfect and that we will need to work hard at anything to make it work. However for over 40 years, traditional software development has proven it not to work. But that is not really true…. it works in the small scale or if we are building something simple. I can’t think of any modern software that is either of those things. However Agile is not a silver bullet. I will say that again… Agile is not a silver bullet and you should read Scrum is hard to adopt and disruptive to your organisation.

@mrhinsh It WAS agile until bugs started to riddle the app. SCRUM only has short-term planning.

— José Manuel Nieto (@SuperJMN) March 23, 2013

Most of the Agile Frameworks only caters to planning the ‘what’ and tells you to let the team decide on ‘how’ to build the software. Scrum, Kanban & Scaled Agile all focus on the Management process not the engineering practices. This does not mean that you don’t also need good engineering practices, and in fact the Scrum Guide explicitly tells you that your team needs “good engineering practices” in order to succeed.

Figure: Testing is core to inspecting and adapting your engineering practices

If you don’t have good engineering practices then you will spend more time sprint after sprint struggling with the technical debt that is built up and you will end up down an engineering blind ally.

@mrhinsh Right. It lacks all of those -able adjectives. But, how to recover from the mess. How to refactor?

— José Manuel Nieto (@SuperJMN) March 23, 2013

But now I am hosed, how to I get out of this?

Step 1: Hold effective retrospectives to prevent the insufficiency of scrum

One of the reasons our team gets into this position is that they did not know that they were in a broken state until it is too late. If our organisation fails to understand the purpose of the retrospective as an inspect and adaptable moment for ‘how’ we worked during our Sprint then one will fail to improve.

@mrhinsh it was as soon as I entered the team. 6th sprint.

— José Manuel Nieto (@SuperJMN) March 23, 2013

The accountable and responsible party here is the Scrum Master. Without an effective Scrum Master to guide the team you WILL fail. If you do not have an effective Scrum Master then you or they don’t fully understand the 42 Tasks for a Scrum Master’s Job.

According to the Scrum Guide the Development Team can ‘choose’ their Scrum Master to make sure that they get some one as effective as possible.

Yes, this also means that they can ‘un-choose’ their current one.

Step 2: Stop creating technical debt to prevent the insufficiency of scrum

You need to first stop creating technical debt. To do this you only need to focus on one thing; working software at lease every 30 days. If you are not able to create working software every sprint then you need to stop and look at why that is.

Note I prefer ‘working software on every checkin’ and ‘continuous delivery’. That way I can ship working software at any time.

Now I am not talking about that flaccid rendition of working software that lead you to this place of horror and despair. But instead take ‘working software’ at face value and have it mean ‘everything that I have delivered works with no further work required’. Does that mean that it meets the customers expectations? No it does not; unless their only expectation is for what you show them to work with no errors and that if they say ‘ship-it’ you can deploy what you have. If you have to reply with… “Well, maybe next sprint as we still have some bugs.” then you have failed as a professional and as a team to deliver the minimum bar.

@mrhinsh The core is basically wrong. Now, nobody can fix that. No time for redesigns in a sprint.

— José Manuel Nieto (@SuperJMN) March 23, 2013

But if we do get into that state then you are in the very same ‘brownfield’ situation as software that has been built over years with no unit tests. So if the primary goal now is working software that meets our customers expectations and we augment our Definition of Done to reflect that then we will be delivering less features of higher quality.

Figure: There is 1000% return of investment for every test written in TDD

While we are still paying back our excessive build up of technical debt, we will be delivering less value to the customer however using these engineering practices will prevent future build up.


Remember that the software that you are building is an organisational asset and decisions to cut quality affect the value of that asset and thus must be reflected in your organisation’s financial statements. Cutting quality in your software without first gaining the approval to do so from your financial executives is unprofessional at best, fraud at worst, and always incompetence.

Don’t be incompetent. Don’t commit fraud.

Be a professional…

Published at Where Technology Meets Teamwork with permission of Martin Hinshelwood, Senior ALM Consultant. (source)

About the Author:


  1. Steven Borg May 23, 2013 at 9:50 am

    I’d argue that Scrum IS insufficient. In one particular, and good, way. Scrum is a management practice that has been proven to work time and again with many teams. Teams implementing will fail, potentially due to a variety of factors some of which may even be some of the tenets of Scrum (but more likely through poor engineering practices, clash with existing culture, and the like).

    However, Scrum being a management practice isn’t a weakness, it’s a strength. It does one thing. And it does that one thing well. It doesn’t specify engineering practices. Those are outside of Scrum. And that’s not a problem with Scrum, as you’ve noted above. But it does mean that Scrum doesn’t provide guidance across all possible areas of software development. Engineering practices are left to the team. If the team has poor engineering practices, and they can’t deliver successfully, it makes no sense to blame it on Scrum. But in the same vein, it makes no sense to claim that Scrum is sufficient, either.

    Sufficient is defined at as “adequate for the purpose; enough”. Meaning you don’t need anything else. Scrum isn’t all a team needs. They need good engineering practices as well. Thus, if you assert Scrum doesn’t provide direct guidance for correct engineering practices, Scrum is, by definition, insufficient. No knock against Scrum, just that it doesn’t claim to solve all development problems, but is focused on solving one particularly vexing issue – management.

    I think a more appropriate claim for Scrum advocates would be that “Scrum is necessary, but not sufficient.” This would imply that you need Scrum to be successful, but you also need more – engineering practices, perhaps. I personally don’t agree with that assertion, but I believe it’s a far more powerful argument than to claim Scrum is sufficient.

  2. Martin Hinshelwood May 24, 2013 at 6:54 am

    I would counter that Scrum specifies that those engineering practices require to exist. They are part of that path to agility that Scrum offers but that it does not presume to tell a team which engineering practices are best for them. We have the Scrum Master who is charged with making sure that the Development Team have the knowledge and tools necessary to do their job, which may include TDD or pairing or plain communication skills.

    Just because one is unable to follow the recipe, and as a result ones bread does not rise, does not prove the insufficiency of the recipe. Instead it just shows that the chef has a lot to learn.

  3. Steven Borg June 11, 2013 at 1:22 pm

    But interestingly, you’re claiming that Scrum is no longer a recipe. That it “does not presume to tell a team which engineering practices are best for them”. Then, by definition, Scrum must not be ‘sufficient’. 🙂 Just a terminology thing, not a methodology thing. Interestingly, though, to continue your recipe/bread metaphor, it would be like the recipe saying “add an appropriate amount of the leavening agent of your choice”. Although the recipe is telling you to do something, you have to be quite the chef indeed to select an appropriate leavening agent in the right amounts, especially if you’re making sourdough!

  4. Martin Hinshelwood June 15, 2013 at 4:30 pm

    You should read Jamie Olivers recipe books. That’s exactly how they read. Some of this and a pich of that, and if you don’t have [something] then pick something similar. It gives you the flexability to decide on your tasts, situation and availability what is right for you and yours…

    Not perscruptive, but sufficient.

Leave A Comment