The problem with Scrum

Posted on June 17th, 2010 in Agile by siddharta || 12 Comments

Scrum (and agile in general) has been responsible for a lot of the current visibility on softer, social aspects of software development – empowered teams, tight collaboration, higher communication and so on. XP’s engineering practices have also been extremely valuable. Those parts work well and we use them along with Kanban.

The problem we found with scrum is that it works well in a certain context: single team, completely dedicated to single project, completely cross functional, no external dependencies, product owner knows exactly what to build, experienced team members with good skills in engineering practices. In such situations it works well. But when you move away from the ideal context then you run into issues. External dependencies? Not fully cross functional? Boom. When I was working in Singapore, we were doing Scrum on embedded systems, and there had to be one set of manual acceptance tests that took a week to complete and couldn’t be automated. Trouble!

There is a joke that goes something like this: A physicist, engineer and psychologist go to a dairy farm to maximize milk production. The engineer derives the optimum packing of cows. The psychologist derives the optimum colour of the barn. The physicist starts “First, assume the cow is a sphere..”

Its the same thing with scrum. If the organization is already at the ideal state (the sphere) then scrum can work really well. If it is not a sphere, then before you can get started, the first step in scrum is to make it a sphere.. and then things get messy.

99% of the time, the organization itself is the “impediment”. It is interesting, because in many cases it is an impediment only from scrum’s point of view. Almost all the “ScrumButs” out there are because of this requirement that everything is an impediment until you get to the sphere… and only then can scrum start working. Every time scrum doesn’t work, invariably it is something to do with the environment not being a sphere – team is not cross functional, PO doesn’t know what to do, developers don’t understand TDD, testers don’t know coding etc.

I really do understand the need for adopting new values and new skills, but they don’t come about overnight. Until that time, you are going to have a hard time with scrum.

The other problem with scrum is that it has an underlying undercurrent of being anti-management. Scrum is essentially a solution to tell management to keep their hands off the team and leave the team alone to figure out how to meet the commitments by themselves. This negative view of management runs through the process – from dividing up people into chickens (management) and pigs (team), preventing all external interruptions and so on. The message is to stop micromanaging and leave the team alone. In many, the scrummaster is equated to a guard dog that protects the sheep (team) from the wolves (management).

Unfortunately once you train ScrumMasters to take a dim view of management, then it gets tough to get management cooperation when you need to interact outside the team.

IMHO, these two places are where Kanban really helps. With Kanban, you no longer have the requirement of making the organization a sphere before even getting started. You can start out with things exactly how they currently are. And Kanban is much better at integrating outside the team. There is still value in doing a lot of things that scrum requires – cross functional teams or engineering practices. You can now do them one by one at a pace at that suits the organization.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

12 Responses to “The problem with Scrum”

  1. Todd Charron Says:

    ” team is not cross functional, PO doesn’t know what to do, developers don’t understand TDD, testers don’t know coding etc.”

    Now imagine your competition has all of these things…

    Just because it’s hard, doesn’t mean you shouldn’t do it.

  2. siddharta Says:

    Sure, but its impossible to do it all instantly – especially in the skills area.

    You cant learn TDD or refactoring overnight. You cant learn automated testing of CI overnight. Its going to take months before you really start doing it right. The process really needs to be able to ramp up slowly over these months.

    With scrum, for all those months where the team is learning TDD, learning to do retrospectives right, learning all these new things that they need, they are going to struggle to deliver working software every sprint.

  3. L Pauls Longhurst Says:

    The following article I’ve written on how to introduce Agile gradually into a project that is struggling adopting it might be useful.

  4. siddharta Says:

    Hi Paul, the link doesn’t seem to work. I’m getting an error page.

  5. Todd Charron Says:

    @siddharta Scrum doesn’t say anything about doing TDD, refactoring, CI, or automated testing. It deliberately refrains from prescribing technical solutions and leaves that to the team to decide.

    Scrum does specify that you need to be able to deliver potentially shippable software at the end of your Sprint. Perhaps you’re trying to deliver too much software each sprint?

    If you can’t deliver much software in that time frame, then perhaps you will need to adopt the techniques you spoke of. There’s no reason you can’t adopt those gradually while still delivering potentially shippable software each sprint. You’ll just start to deliver more working software as you adopt better development practices.

    You also don’t have to do retrospectives “right”. I’m not even sure what that means. Simply having a retrospective at all will do wonders for your team.

    That way the team can figure out why they can’t deliver working software each sprint and can improve iteratively towards that goal. There are many different ways to run retrospectives, Scrum just requires that you do one.

    Scrum is like getting fit. People want to get in shape. They know all they have to do is eat reasonably healthy and get some exercise. And yet people will find a million excuses not to start.

    No one expects a Scrum team to be instantly hyperproductive, but by doing Scrum, you will quickly see the areas your team or organization needs to improve on. By improving in these areas each Sprint your productivity and quality will naturally go up over time.

    Perhaps you should look into Agile/Scrum coaching if you need assistance getting started.

  6. Vaidy Says:

    @Siddharth, thank you for writing this and getting the discussion started.

    @Todd I love your getting-fit analogy. Makes it easier to visualize what we’re trying to achieve.

  7. siddharta Says:


    I broadly agree with what you are saying.

    There are two points here.

    Lets take an example of a team that is new to Scrum. Assume you are on a 2 week sprint. If you want to do that you need to know TDD, automated functional testing. Lets say it takes 4 months to start doing it well.

    Now, add on that the team has to learn self-organization, backlog grooming, refactoring, retrospectives etc etc – a lot of things.

    During all this time, there is a high chance the team will struggle with changes, not deliver shippable products for many sprints, and the process will fail.

    Result? Everyone is unhappy, Scrum is blamed by the org, and purists will blame ScrumBut.

    I love your exercise analogy and in fact I blogged on this issue with the exact same analogy in 2006 :)

    The thing is that there are varying levels of getting fit. Some people want to expend little effort and get small improvement. Maybe going for a walk. Some people want slightly more, and are willing to expend more and so maybe they play a sport or attend yoga. Some people want to become ultra fit, perhaps athletes training for the Olympics.

    You can’t just take a person off the couch and put them though an athlete regimen. It won’t work, there will be a backlash and they will be back to the couch. a) they may not be ready for it and b) they may not even want to go all the way there.

    With scrum its either couch or athlete. You can’t take an existing process and say today we walk – we’ll do only retrospectives. Next month we jog – add in TDD and automated testing. Next month we introduce self-organization, etc.

  8. Todd Charron Says:


    “Lets take an example of a team that is new to Scrum. Assume you are on a 2 week sprint. If you want to do that you need to know TDD, automated functional testing. Lets say it takes 4 months to start doing it well.”

    I think this is where we differ. There is nothing in Scrum that says you have to know or do any of that. Feel free to gradually add those other things as you go, but they aren’t explicitly required to be “doing Scrum”.

    All Scrum requires to get started is

    1) a list of things to do (the backlog, which doesn’t have to be in any particular format). I happen to like User Stories, but any list will do to start.
    2) A sprint length (e.g. 2 weeks)
    3) a time boxed planning meeting at the start, in which the team decides how much it can take on that sprint and estimates items in the backlog.
    4) a daily stand-up (15 mins or less) where each person on the team answers 3 questions, “what did I do yesterday”, “what am I going to do today”, and “what is blocking me from getting things done”
    5) A time boxed demo where the team shows what it accomplished at the end of the sprint.
    6) a time boxed retrospective where the team reflects and discovers how it can improve at the end of each sprint.

    You track progress using a sprint backlog and a burn down chart.

    You have a product owner in charge of the backlog and a scrum master in charge of removing impediments for the team.

    I don’t see anything in there that would take months for a team to implement.

    Once you start doing these things, it will become apparent which agile practices you need to adopt to improve your team.

    I’ve been on Scrum teams that have not done TDD and have not had automated functional testing (they had automated unit tests) and they were fine. They were in the process of gradually adopting both of those things, but it didn’t prevent them from “doing Scrum”.

    Scrum is just a framework, not a list of technical practices. You can debate the merits of the framework, but don’t confuse it with adopting agile technical practices which will take more time to adopt.

  9. Siddharta Says:

    Hi Todd,

    Yes, technically you don’t need the technical practices, but I’ve found them to be pretty much required in most cases. A lot of teams struggle to deliver a potentially shippable product at the end of the sprint without them.

    See for example Ken Schwaber’s response on Flaccid Scrum –

  10. Janice Says:

    I think the point of this article is not what you can do or learn overnight, I think the point is how handle teams that not all members have all skills. I had problems like that and for manage it sometimes, and the solution for that point many time was to isolate, for example, who had only one skill, like a tester that doesn’t know how to code and try to make the team generate codes faster to not let him without do anything. I mean after months ok, you can make all of them works in everything(Almost) but in 2 weeks or a month, no, and in that time and that situation how can we handle it?
    Good article, let’s think more about it..

  11. siddharta Says:

    Hi Janice,

    I agree with you. Most organizations that are transitioning to agile don’t fit the ideal scrum environment, and it is a big challenge to deliver working software every sprint while it is like that.

  12. Marionsn Says:

    power tools by

Leave a Reply