Main problems with Scrum

This Is A Thread I Like In Scrum Practitioners, With A Lot Great Comments. Analyst at Spring Wireless Top Contributor



We have here many people that are part of Scrum teams and all of us are at different stages of implementing Scrum. Some of us have many years working with Scrum, there are some that are Scrum instructors, and we have many people that are working with Scrum for less time.


I'd like you to share the problems you see with Scrum. Maybe you have some questions that are not answered by Scrum and you are trying one and another thing to see what best fits in your case, but have not come to a conclusion. Or maybe you have faced some problems in the past and found a way to solve them, maybe using part of other methodologies along with Scrum.

I am doing this research as part of an academic work, so I'd be very grateful if you can share your experience.

Thanks in advanceBrett



Principal Consultant at Readify, Professional Scrum Trainer



Top Contributor



There are no problems with Scrum. The problems actually are with the people that implement it. To err is human.

I always say "scrum cannot fail, only people do"Curtis



Freelance Perl expert seeking contract. I offer training and consulting in agile development, software testing and Perl.



I'm a huge fan of Scrum. I think it's great, but when I point out the fact that there are some issues, I get accused of being anti-Scrum, which is not true. Keeping that in mind, I think it's fair to say that there are several issues around Scrum which should be addressed. I like Steve's comments, but I want to be more Scrum-specific.

To set the background of my comments, one concept I teach is "Abusive Processes". These are processes that people routinely resist, ignore, or complain about. Whenever you see these, you need to understand the goal of the process, decide if the goal is both worthwhile and realistic, and then ask yourself what happens if you abandon the process. At that point, you can understand the risk/reward proposition and try to determine how to minimize the risk and maximize the reward by fixing your process.

When I see abusive processes in a non-Agile company, it's often trivial to analyze them and proffer an Agile alternative (assuming the company is transitioning to Agile). When I see abusive processes in Agile companies, it starts to get tricky because many people have the Shining Light of the Saved in their eyes and you can't question the Agile process they've adopted.

For example. one question I often ask when I lead an Agile class is about their Sprint planning, a meeting time-boxed at 8 hours. I ask "when you do sprint planning, do you ever find people who fall asleep or start checking their Facebook during the meeting?" The answer has always been "yes". These are often people who care deeply about the quality of what they produce, but Sprint planning is often a tedious chore for them. That's a symptom of an abusive process and I've definitely met teams that break from this process and do something different. For example, one team cheerfully sends their team lead (yeah, I know Scrum discourages this) and a senior dev to work with the PO and Scrum Master to set the Sprint goal and pick related stories and maybe make technical notes on stories. At that point, the Sprint planning is now only about choosing the stories, refining technical considerations, and estimating them.

Another example is the retrospective. You can search Youtube and find all sorts of cute videos about retrospectives, a meeting typically time-boxed at three hours. These videos are designed to offer clever ideas to keep a team motivated about a retrospective, a meeting they often consider to be a chore. If a team is happy and productive, do we really *need* a mandatory retrospective every sprint? Many successful teams skip the retrospective (a practice I discourage). Instead, I offer a compromise: what about periodic retrospectives that a self-organizing team can decide to do when they decide they need it, rather than forcing it on them every sprint?

As a final example, I point to sprint length. In XP, you'll find many teams have a one-week iteration. This rarely happens in Scrum, where sprint length is typically two weeks or more. If we accept that rapid delivery is a key to getting feedback from our customers, it should be a given that we want rapid delivery. However, many Scrum teams tie delivery to sprints. As a result, when you have an 8 hour planning meeting, daily 15 minute stand ups, a 4 hour sprint review and a 3 hour retrospective, that could easily take up two days out of a five-day sprint! (Yes, I know that for a short sprint you don't need all that time for the meetings, but given that few Scrum teams have a one-week Sprint, the proof is in the pudding). Because of this, I often encourage teams to decouple releases from Sprints.

So yes, it's true that Scrum is not perfect. There is an interesting issue where I routinely hear management complain that multiple teams are failing to deliver and blaming the people rather than the process. For Scrum, it's good, but it's OK to question the processes and fine-tune it for your needs.Senior Software Engineer at GlobalX



Similar question was asked a few months ago in this group, which is like "Main problems with a sharp knife". My answer was cut your finger easily.

I heard of a lot good things about Scrum since I practiced some parts of XP since 2000, and I highly regard Scrum. However, so far I had seen Scrum was used in some shops by some in the management position as a new way to realize command and control. As always, mindset change is the most important, and it needs great self confidence and courage not to command and control.

Curtis Poe mentioned the length of sprint is typically a fortnight because of efficiency of time management. I myself basically have a 2-week memory window, and I barely remember what I had done over 2 weeks ago, and I am not alone. I have a feeling that the typical sprint length is taking care of the weakness of human brain.

Scrum was designed for better catering humanity during software development using wetware, however, the execution of Scrum could also be exploited and corrupted against humanity eventually to harm the productivity of development.Senior Software Engineer at GlobalX



Many team leaders and managers are lack of understanding and skills in software engineering, and considering Scrum is an easy and lightweight framework to take care of every aspects/attributes of software engineering and development so they could have "everything under control". I would say, the marketing efforts of some Scrum "promoters" is partly to blame, say 10 %.Senior Software Engineer at GlobalX



I just read this link



well answering the question "Main problem with Scrum".Senior Software Engineer at GlobalX



The end of this post by Glenn: Scrum is a completely new way of thinking and mind-set shifting. It is not just a list of practices: if you "stand-up" it doesn't mean you do Scrum

If someone really wants a direct answer to "main problems with Scrum" or "main problems of Scrum", I would say the problem is that, the success of Scrum practices need a great deal of "new way of thinking and mindset shifting", however, Scrum does not seem to directly address mindset shifting which is really challenging task in most organizations.

And this difficult task seem to be the burden on the shoulder of Scrum coaches who have better to be architect, senior developer, psychologist and negotiator etc. -- I don't mean the coach had to be ever an architect or senior developer, but at least they have some degree of understanding to assist mind-set shifting. Have a SM certificate and being politicized are far from enough.Senior Software Engineer at GlobalX



The end of this post by Glenn: Scrum is a completely new way of thinking and mind-set shifting. It is not just a list of practices: if you "stand-up" it doesn't mean you do Scrum

If someone really wants a direct answer to "main problems with Scrum" or "main problems of Scrum", I would say the problem is that, the success of Scrum practices need a great deal of "new way of thinking and mindset shifting", however, Scrum does not seem to directly address mindset shifting which is really challenging task in most organizations.

And this difficult task seem to be the burden on the shoulder of Scrum coaches who have better to be architect, senior developer, psychologist and negotiator etc. -- I don't mean the coach had to be ever an architect or senior developer, but at least they have some degree of understanding to assist mind-set shifting. Have a SM certificate and being politicized are far from enough.Scott



Executive Subject Matter Expert at Intergraph



Agile methods, in general, and perhaps Scrum, in particular, share the "problems" that, compared to many other approaches, they (a) require a greater degree of individual discipline, (b) leave a lot to the teams (and organizations) to work out, requiring more trust and patience, (c) expect more effective communication and greater ability to absorb change (across the organization), and (d) presume a level of continuous improvement often viewed as a "high maturity" organizational characteristic. Implementations "ail" in my view, because organizations do not take the time initially to consider the implications of these "problems" and what the Agile Manifesto/Principles will mean to them.Maurizio



Senior Agile .NET Developer at Ogone



Hope I misunderstood some comments, but I find the idea of asserting that Scrum has no problems to be a bit superstitious, to say nothing of the fact that the next logical step of this assumption is - of course - to cast the fault on the people who implement it (and as Scrum was indeed defined by other "people" we should then speculate on the reasons behind the infallibility of Scrum). A bit like the "No True Scotsman" argument.

Based on my personal experience, I find that some issues pop up frequently when using Scrum:

- Budgeting and contracting have sometimes to be "reinvented" and Scrum doesn't tell you how to do that.

- Scaling (whatever the dimension) is difficult

- Scrum is more difficult to implement with distributed teams

Last but not least (and to be honest I don't think is a problem :) )... Scrum is demanding, in a way that is often underestimated, even by people who are very into it.Scott



Executive Subject Matter Expert at Intergraph



Maurizio...

I'm certainly not interested in casting "fault," but (and it's the first Manifesto value) people and their interactions are the fundamental element of any success regardless of the approach used. Some approaches view this is risk and try to mitigate that by being as prescriptive as (they feel) necessary to reduce the decisions and interactions. This often results in an approach that ultimately caters to the lowest common denominator of skill/capability. (Indeed, in a Master's Degree lecture I gave many years ago, I was even asked how poorly trained people on a project could be if the methods were rigorous enough.)

I do agree that the budgeting and contracting issues are not at all covered. On the other hand, I dislike it when people who train/coach take the position that there is nothing to be said about anything not part of "official" Scrum. (And, yes, I know that this is often done to "make a point" about teams, SMs and POs not being led by others decisions. But offering some knowledge/experience where it exists can be done with making it seem like some authoritative answer.)

I'm not sure scaling is really harder with Scrum than with any other approach. Phased methods often rely on hierarchical authority to manage this even as this is often the approach at the individual team level when the team's manager makes all final decisions.

As to distributed teams, if they really operate as a team and not as a unit of more or less independent individuals, then Scrum or not, being distributed is more difficult than being co-located. Where I think Agile methods, in general, can actually help in distributed environments is through their emphasis on collaboration and communication as opposed to dividing up work to minimize communication.Mark



Founder and Consultant at Agile Pain Relief Consulting - Agile/Lean Transition Coach



Two simple things - Flat (i.e. Single Column) Product Backlogs are limiting - many Scrum teams discover there is value in maintaining a Story Map and not a simple Product Backlog.

Most elements of Scrum are named so as to obscure their true value - think Sprint; Backlog; or two uses of Team. One day when I have a few hours I will show just how much got misnamed :-)Aleksandr



Software Architect at NetIQ



Agreed that SCRUM itself doesn't have problems, however I am seeing a lot of issues when people are trying to use SCRUM in the areas where it doesn't work. In my experience it doesn't work in software development projects with a lot of research activities involved. Essentially, I WOULD ARGUE THAT RESEARCH ACTIVITIES ARE HARD TO ESTIMATE. TRYING TO APPLY SCRUM IN THIS AREA LEADS TO UNNECESSARY OVERHEAD, WHEN PEOPLE ARE DOING PLANNING WHICH GETS THROWN OUT OF THE WINDOW IF AN ASSUMPTION TURNED OUT TO BE WRONG. SPLITTING RESEARCH AND DEVELOPMENT STORIES INTO TWO DIFFERENT BACKLOG ITEMS LEADS TO A TIME GAP WHERE AFTER RESEARCH IS DONE PEOPLE WOULD START TO DO DEVELOPMENT IN ANOTHER SPRINT OR EVEN A SPRINT AFTER THAT AS OPPOSED TO DOING THE WORK RIGHT AWAY WHILE YOUR MEMORY IS STILL FRESH



, like this



Aleksandr



Software Architect at NetIQ



When it comes down to allocating resources in the SCRUM planning meeting, one of the points that frequently being advocated at least in the SCRUM training is that "everybody can do everything". Developers are totally replaceable, developers can test, testers can develop. It is a great idea that managers really love, especially when you can outsource them offshore and I think it works great in a stable corporate world. In reality, I am seeing a lot of issues with this:

- Developers are hired to write code, they love it, enjoy it and they can do it the best. Testing activity requires completely different mindset (IMHO). Even the developers that don't complain loud (there may be some) still may not do the job as well as the qualified and experienced tester. I personally don't support the idea that "everybody can test". Everybody may be able to go over the test cases, but it is not the same as full cycle QA with exploratory testing, scenario based testing, etc... Obviously, the reverse is true as well - testers writing code may not always work.

- More general point - In the real agile startup environment, I don't think people can afford to wait until everybody can learn to do everything. It may be more beneficial to have exports in different fields, UI, networking, drivers, etc... I don't think that in a *short term* it is a great idea to have UI guys learn to develop kernel drivers, but again this may pay off later, depending on dynamics of the product. Sometimes, a "Surgical Team" approach (Mythical-Man-Month, Brooks) works betterSteve



Experienced Video Game Producer, Agile & Scrum Coach, Passionate Musician, Critical Thinker, Creative Fellow



@Paul - excellent point and I think great example of how Scrum can be used to expose issues..

Again, I'm going to PO hell but I think one thing that's sometimes difficult to reconcile is this idea that the ONLY thing worth delivering is "demo ready" software or that the burn-down chart meets exactly at 0 neatly at the end of each sprint. But if we're not uncomfortable, chances are good we're not realizing any development framework or principles well. On top of it, we hear easily misconstrued, situational, even counter-intuitive mantras like "it has to be Done with a capital D" or "fail early, fail often". And we're supposed to do all of this with software that we may not even know how to build yet?

I feel sometimes what we learn from the team, the process AND the product from sprint to sprint is just as important - if not more so - than getting "demo software" in the can. This makes it imperative that the team is involved in user story planning and estimation! As a PO, I would much rather see a sprint or two of timeboxed investigation, research or prototype stories on highly complex or unknown work than the ongoing uncertainty and disappointment of the team committing to deliver "THE THING" because they didn't have the opportunity to vet, got lazy, were strong-armed or rushed, etc. IMO, this not a symptom CAUSED by Scrum (or Lean, Waterfall, or whatever). Rather it's a problem that's exposed by

I've brought really crazy stories to a team and with some adjustment, ended up like this:

As a Product Owner, I want the most lightweight yet usable initial prototype of [...] so that we can make a better informed decision as to the necessity/feasibility of the shipping system.

* tbx to [...]hrs

* not pretty, but can use most valuable X Y and Z features

* document programming challenges and learnings and have 30 minute brain dump to discuss findings

A story like this every once in a while always led to better product decisions in my experience.

We need to place value on a learning organization and think critically when the charts neatly land on 0 every sprint - especially for a product with a lot of new features. "Done" and "demo software" feel good - but may not be what you need this sprint.Jem



Agile enabler at Lloyds Online Doctor



Of course Scrum it's challenge areas, to call it perfect would be naive. Someone challenge the term 'commitment' - it is now 'forecast'. This didn't happen without challenging or raising a question on the terminology used in the Scrum guide. Scrum has it's areas to improve on.

Here's one example in my experience where Scrum falls short.

The emphasis on quality.

The Scrum guide clearly states that quality is important, but it's far to subtle in my opinion. I would like to see something more prescriptive with regards to quality given how integral it is to creating high quality Product. Now whether thats SOLID principles, TDD, BDD etc - that's out for discussion - but Scrum as a framework needs to evolve to answer key questions and add prescription where high quality software depends on it.

This is coming from someone who lives and breathes the Scrum mindset, it's my passion but in the interest of Scrum we should challenge areas that need it.Jem



Agile enabler at Lloyds Online Doctor



@Paul, tell me could you dispute the rules of SOLID when it comes to writing quality code? It has almost become prescriptive in the Scrum community that we combine proven tooling form XP within Scrum to achieve the goal of high quality code. Why should we then ask new teams to choose the tools for high quality software when it is known and proven that combining TDD, BDD & SOLID principles we can achieve this? The fluidity of the framework is both a blessing and sometimes a curse. It's for me, identifying when some prescription is beneficial and when it is not. And specifically on code quality - we need to see some prescription in my view.

"In regards to quality, Scrum uses the empirical way of reviewing and adapting in order to tune and adjust behaviour. Continuous attention to detail and technical excellence from within the team is what enhances quality"

You're making a huge assumption that you have high quality developers already in place that are able to provide the right choices to build in quality. Your statement above provides little to no guidance to a new Scrum team that are not bad ass developers versed in SOLID, TDD, BDDfor many others it leaves them floundering searching for a direction. Scrum on its own is not sufficient. Having a coach is one way to help fill the gap Scrum leaves for the engineering processes to be slotted in.Jane



Senior Consultant at Improving Enterprises



Scrum is not perfect. However, Scrum is vastly better than many popular processes out there. Lots of things that Scrum is routinely blamed for are not the fault of Scrum, but are rather organizational problems made visible by Scrum. Other problems that are often attributed to Scrum are due to poor or incomplete implementation, rather than Scrum framework itself.

Scrum does have problems, though. Switching to Scrum is hard, for example. Knowing whether a team is doing Scrum properly is sometimes tricky. Adjusting the process to support distributed teams is hard and under-specified.Jane



Senior Consultant at Improving Enterprises



You are right, Scrum does tell people how to be very good at their jobs. The problem is, it is not very easy. While Scrum makes it somewhat easier, and provides some guidelines, it is not always easy to follow and to check one's being on-target.

It is possible to claim that it's not Scrum's fault that people are not very good. Yet, people are what they are, and any process must deal with reality. Scrum comes with lots of training, coaching, and has a reasonably high failure rate (people fail at doing Scrum properly quite often) - it is a drawback, that at least partly should be attributed to Scrum.

None of the above makes Scrum 'bad'. Scrum is very good - it leads to success most of the time, it is much better than other processes available and appropriate for complex creative endeavors, such as software development. It is also quite realistic - it does provide guidance, and check-points, and nudges to help people do it right.Senior Software Engineer at GlobalX



Screwdriver is good example. Strong, a flexible and well balanced hand could effectively use the screwdriver. Unskillful hands could be improved through practice and training. Without a screwdriver you may still screw, but just less successful or less efficient.

I tend to believe Scrum or alike could decrease fatality rate of software projects, or increase success rate of software projects. :)

There are still many variables out of the "controls" of Scrum, such as team culture, company culture, HR and finance which have critical impact on the success of software projects. A Scrum coach may influence team culture or even company culture, but still there are many out of the grip of the coach. Surely these are not the problems of Scrum, and this is just reality.Paul



Sr. Scientist Semantic Interoperabilityit is about (newtonian) physics, and hence predictable. Building software is about supporting humans in their ever changing environment, context and scope: It is about a *complex* system that has got many interconnections between continously changing elements, and therefore is inherently unpredictable. Only by massively (i) scoping down the interconnections and (ii) limiting the variations, we can cope with it as if it were a mere complicated system.

What I try to say is that, being human, people, when faced with a complex system, try to cope with it as if it were a complicated system [1]. Which it is not. We are familiar with complicated systems: humans have had thousands of years to learn how to master complicated systems, engineers have been educated coping strategies to master complicated systems.

If you look around you, and ignore the people in your environment, you see engineering solutions to complicated problems everywhere. Contrarily, software has evolved, from simple calulating engines to complicated applications that monitor and control very specific tasks in, e.g., satellites and rockets. With it, our development methods have evolved. And now that we are on the brink to building complex software, our methods need to change as well. Hence the agile manifesto, hence Scrum that already incorporates mechanisms that go beyond processes to master complicated problems (see [1], Table 2).

In my opinion, and generalising (!), Scrum succeeds where the problem at hand is "only" complicated, and fails where the problem becomes complex. Not beacuse of Scrum, but because of the complex nature of the problem that we, biased humans, try to cope with by applying, instinctively, strategies for complicated problems.

[1]Jem



Agile enabler at Lloyds Online Doctor



Mike Cohn puts it perfectly...

"While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success.In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes"

Here's the article he refers to Uncle bobs "The land that Scrum forgot". I really think it's clear on what practices prove to build quality into code. It's time we offered more than "build quality" into the Scrum guide, that just aint enough loving for such a vital ingredient to software development !Paul



Team Member at Youmanage HR Ltd



@Jem - Yes, even prescription has a place, e.g. where people aren't yet ready to make good decisions for themselves.

Another aspect comes to mind though, w.r.t. SOLID principles and a few more... in some cases we don't have yardsticks to measure how good we are; in other places we don't always know those goals are good ones to aim for. While I am happy to say it isn't Scrum's job to fill these gaps, I think maybe that "Agile Software Development" in general, could say more on the topic. But then we don't have an 'authoritative voice' in that respect; just many opinions.
Full Post