The Insufficiency of Scrum is a fallacy



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…

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Professional Scrum Product Owner online 8th May 2023
8-11 May, 2023
12:00-16:00 EDT
4 half-days
Live Virtual Applying Professional Scrum in Minecraft on 15th May 2023
15-18 May, 2023
09:30-13:30 BST
4 half-days
Live Virtual Advanced Professional Scrum Master Online on 15th May 2023
15-18 May, 2023
12:00-16:00 BST
4 half-days
Live Virtual Advanced Professional Scrum Product Owner Online on 22nd May 2022
22-25 May, 2023
09:00-13:00 BST
4 half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood (He/Him) Why do you think the PSU course has become so popular for product development? Because there is a gap. A massive gap. In the product development world, we talk a lot about scrum. Scrum is not the only agile framework out there, but it is by far the most …
Martin Hinshelwood (He/Him) How important is DevOps in continuous delivery of value to customers? DevOps is imperative. It is exactly the same thing as agile, but from a different perspective. Agile The agile element of how we work together to achieve a shared purpose, common goal, and specific strategic objectives has a …
Martin Hinshelwood (He/Him) What is a common mistake made by rookie agile consultants? I think the most common mistake made by a rookie agile consultant is the belief that simply by following the rules or processes of whatever agile framework they recommend; positive results and outcomes will be achieved. A belief that …
Martin Hinshelwood (He/Him) What would you advise a scrum team to do in their first 4 weeks? That’s an interesting question because it depends on the intention of the team. In my opinion, if their intention is to try scrum, then that is what they should focus on in the first 4 …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.