Agile Zone is brought to you in partnership with:

Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on, and speaks often on Scrum, good practices and Visual Studio ALM. You can get in touch with Martin through naked ALM. Martin is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

The Insufficiency of Scrum is a Fallacy

  • submit to reddit
Agile frameworks like Scrum only really talk bout the rules to play, not the strategies to win.

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 it 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.

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. Unfortunately we worked at traditional software development for over 40 years to prove that it did not 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.

Most of the Agile Frameworks only cater for 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 those good engineering practices then you will spend more time sprint on sprint struggling with the technical debt that is built up and you will end up down an engineering blind ally.

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

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

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

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.

But if we do get into that state then you are in the very same ‘brownfield’ situation as software that have 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, using those engineering practices that will prevent future build up, we will be delivering less value to the customer.


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 organisations financial statements .Cutting quality in your software without first gaining the approval to do so from your financial executives is unprofessional at best and fraud at worst and always incompetence.

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

Be a professional…

Published at DZone with permission of Martin Hinshelwood, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jilles Van Gurp replied on Wed, 2013/03/27 - 4:15am

You can't fix a disfunctional organization merely by introducing scrum. Yet that is the primary reason that most organizations go to through the moves of adopting scrum. That, and an irrational desire to imitate others. It's also the reason why it's not helping.

The fallacy here is believing it that "doing it right", getting more formal about doing it right, and getting ultra pedantic about what right is, is in any way helpful. Proving that is actually very hard and consequently no such proof actually exists. At least not the variety that lives up to any academic standards. 

Usually the substitute for evidence involves vague references to a bunch of guys that supposedly did a project once or twice that wasn't so bad and maybe imitating very dogmatically what they supposedly did might actually be helpful.  There are a lot of failing software projects out there. Just like there were before scrum was introduced to our industry. I would even go as far as saying that the introduction of scrum didn't change much, if anything at all, in the number of failing software projects.

 Likewise there are a lot of projects out there that do succeed. Just like there used to be such projects before the introduction of scrum. The only correlation I see to success is having a good team with great individuals. Make the team small enough and you won't need much process. 

Martin Hinshelwood replied on Wed, 2013/03/27 - 6:47am in response to: Jilles Van Gurp

"The fallacy here is believing it that "doing it right", getting more formal about doing it right, and getting ultra pedantic about what right is, is in any way helpful. "

I do not believe I say anything of the sort :) 

Of course you can't "fix a dysfunctional organization merely by introducing scrum" it take courageg and commitment to change as well as dedicated people to make that work.

This post was intended to say that it is not something that stands alone and that you need People, Process and Practices to make your process work. Indeed, neither Scrum nor Kanban nor any of what people general call Agile methodologies are actually anything of the sort. They are frameworks, guiding rails to keep us on the tracks and guide us towards our OWN custom Agile process that meets our needs. 

In addition to that framework you need the will and courage to change an organisation for the better

But the evidence is there if you are willing to look for it.

You can check out the Chaos Manifesto , but all it really tells us is that teams doing Agile are more successfully more often than traditional methods. You can buy the Forrester reports  that go into enormous detail but they are expensive.

You can look for an find case studies on the FBI Sential project, the Boeing Bedol (2003) and many more  that show Scrum actually working and providing benefit and success to teams and organisations delivering large software projects. This is the empirical evidence upon which much of agility is based.

And if you are looking for more of the math behind it then:

Lund Wolfe replied on Sat, 2013/03/30 - 5:53pm

I have to agree with Jilles.  The fallacy/assumption here was that methodology/process will compensate for people.  The failure here appears to be both a weak team and a weak tech lead.  Nothing else will matter at that point.

People with technical ability is necessary and sufficient.

Martin Hinshelwood replied on Sat, 2013/03/30 - 7:17pm in response to: Lund Wolfe

Lund, I believe that I stated emphatically in my post that without good engineering practices you will fail, whatever your process.

People with technical ability is necessary and sufficient.

Uncomfortably incorrect. You can have the best engineers in the world that build the most functional and bug free software possible that can still fail to meet both the expectations and the needs of the customer.

People with technical ability are necessary but are not sufficient without a process that guides them to delivering what the customer needs.

In short: You can not succeed with out both people and process

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.