Why Scrum alone does not work

and how to make it much better:

The purpose of this post is to describe the limitations of Scrum and why Scrum alone will often not work.  Later we describe what would work much better, while still using incremental product development. In particular, we focus on how to move beyond the mantra of delivering “value” to something much more specific, beneficial and measurable, collaboratively.

Agile is a collection of values and principles relating to software development.  A number of “Agile” methods have become common (since 2001), the most popular of which is Scrum.  However, Scrum is controversial. Technical forums are awash with feedback from developers who do not support the method, to put it mildly. But that is only part of the issue.

Our view is that some of Scrum reflects Agile principles but much of it is anti-Agile. Also, we believe that Scrum is not enough for the majority of projects. Especially, when we engage in Enterprise-wide system development and deployment, or large-scale or complex system development.

The reason we say Scrum is anti-Agile is that the Scrum Guide is prescriptive. It includes many rules and explicitly says they must not be broken.

Many of those rules lead directly to the issues that follow.

The specific issues with Scrum:

1. Scrum focuses on product development via the product backlog. However, there are also many other things ⁽¹⁾  outside of the product backlog to be done on vast numbers of projects. Scrum refuses to recognise these even exist. At best, it assumes the Scrum team will do these things, while they are being judged by their velocity in terms of completion of product backlog items. Really?  Scrum defines a team as only being the “professionals” required to “produce a single product increment while forbidding any other role to exist outside of the core Scrum team ⁽²⁾. This is simply not the real world. Scrum does not cover all you typically have to do (in projects). It refuses to recognise that you will need many other roles to deliver a project successfully.
2. Scrum is totally introspective. Not once, in the whole guide does it mention the needs of others outside the Scrum team. It totally avoids any relationship between the work of those outside the Scrum team and Scrum teams.
3. Scrum includes no Software Engineering practices. This often results in technical debt, considerable code refactoring or even development being scrapped. Especially once requirements are understood in later Sprints. It can even make current software or designs no longer usable. Scrum almost ignores design and encourages emergent Architecture and Design. This adds further risk around technical debt, flexibility of Design around future requirements, and maintainability of developed code.
4. Scrum encourages that deployable code is produced per sprint. However, it does not mention or recognise requirements for updates to business processes and functions.  These are part of the bigger ‘project’. It only refers to “Product Increments”.
5. Scrum is inflexible and prescriptive ⁽³⁾. It states there are only 3 roles allowed. However, none of these roles is likely to pick up and manage the items mentioned above in #1. It is full of “Rules of the game” which are always going to raise the likelihood of issues (and gaps) that really should never happen.
6. Scrum states it proves it is a vehicle for dealing with complexity. It says that it is ideal for dealing with complexity but offers zero comments on how to. In reality, following Scrum’s fixed model (“religiously”) will result in complexity issues, not resolve them.
7. According to the guide, Scrum teams: are “highly flexible and adaptive”. They also need to be stable but it fails to mention this. Both of these requirements are very hard to achieve in the real world. That is one of the reasons why Scrum authors themselves admit ⁽⁴⁾ that large numbers of Scrum teams do not produce shippable products at the end of each Sprint. The other reason for this is that large numbers of Scrum teams fail to test inside Sprints. Those that do, often develop an ever-growing “bug fix” backlog that is in addition to the product backlog. I recently (April 2018) heard of one (from a single project in a major corporation) that had over 3000 items in it. Yes, that is three thousand, yet their “velocity” was still based on stories supposedly “done”. No doubt claims of amazing new productivity are still being made, by some.  It is also true that in many Agile teams test plans are a thing of the past. Where this is true, it has a clear relationship with this whole issue.
8. The guide makes some astonishingly sweeping statements about all Scrum teams. E.g. “Everyone focuses on the work of the Sprint and the goals of the Scrum Team”. While this statement sounds great, if we are being really honest, it is optimistic, at best. As an underlying key principle, it leads Scrum to make some very bad decisions, especially around areas such as leadership. Scrum lacks leadership.
9. No one would argue against having a product owner. However, outside of software houses where the core business is developing software, the expectations around the PO are wildly optimistic ⁽⁵⁾. There are some key responsibilities that Scrum places on them that they are seldom going to do in practice ⁽⁶⁾.
10. Scrum can make you very short-sighted, focusing no further than the end of the next Sprint. It even uses an analogy of saying the next Sprint is the project ⁽⁷⁾. This is a very bad habit and risks creating an attitude among teams that anything beyond this horizon does not matter (yet). Projects often encounter long lead times, and should this be the case, this is just one reason why this “habit” is very damaging. Understanding requirements around sequential iterations can mean earlier decisions have to be re-visited. In some cases, that may be very difficult, costly or even not feasible.
11. Scrum refuses to recognise roles such as “lead developer”. This de-motivates people and affects quality.
12. Scrum quotes words like “openness, respect and professionals” while defining a framework that results in more micro-management than most people will endure. Especially when you add the use (and misuse) of velocity. Add the frequency of sprints and many professional developers will see this as a very short-term environment for them. Burnout happens quickly.
13. Scrum does not recognise dependencies (outside the Scrum team) and in any kind of development, it’s almost impossible to eliminate them. To ignore them is disastrous. Projects do not just consist of the software alone.
14. Scrum Masters don’t lead dev teams but they do lead the Scrum process. Anyone can get a Scrum certification after two days of training, regardless of what they did previously. Then call themselves a Scrum ‘coach’. Or even worse: an Agile ‘transformation’  coach.
15. Scrum and Agile are often referred to as a ‘religion’ ⁽⁸⁾. Religion is something a group of people believes in, but no one can prove it is true. When any kind of belief starts to alienate those who are not from within, bad things normally follow.

What would work much better?

1. Scrum (and many in Agile) throws the word “value” about (e.g. customer value) constantly. I have no idea what this really means, and I suspect I am not alone. But it sounds great, right?. Projects don’t start with a Product Backlog. They should always start with far more strategic elements, such as: the specific problem you are trying to solve; the project goal; and the outcomes that the project is to deliver.  These things should be articulated clearly around stakeholders like customers and should be measurable in as many cases as possible.  The whole thinking and assumptions must be validated (in a very “light touch” way) with the key stakeholders and especially those funding the project. This might be harsh, but this piece really does matter and goes much further than throwing around the word “value”. Also, all of this must happen before there are any commitments to the “solution” or assumptions could become very costly.
2. Once you have decided you have a problem really worth fixing, you can explore ideas and options. We can weigh these up and make a decision on which way to go, involving the right people. This will be people from the business, technology leads and delivery managers. This is to optimise ideas and start to build a common understanding of what we are trying to achieve, not just what we are building. We must always focus on the outcomes we want to achieve, not just the products/solutions we want to build.
3. Once we get to the point of settling on a solution, which may involve product development, we can start to explore what the product needs to look like and do. But, all efforts and decisions must be focused on maximising the outcomes we want to achieve. All those outcomes will be business outcomes, as that’s how we fund projects and more.
4. As soon as possible, we should involve people with experience in design, architecture, and/or systems engineering. We should also involve a project manager who preferably has experience with this type of project. As early as possible, we should start to understand the full scope of work of the project, not just the product development. We should look at all aspects such as design, integration, testing, data migration, business change and deployment. This is to ensure that there is validity to the plan, especially integration and testing (two aspects where Scrum is especially weak). We should test all major assumptions as soon as we can. Those assumptions can relate to the solution or the outcomes the project is intended to achieve.
5. We should develop a team, which includes all the key people (parties) responsible for all the major elements of the project, not just the product development. The product development element must be managed as an integral part of the overall project. It must never be managed in isolation. Every team member must be fully aware of the broader business needs of the project and the outcomes it is intended to achieve. They should take these into account in all their project decisions.
6. Then, we should decide which development approach we can and should take. This may be Agile, but only if Agile is a good fit for the project. If not, it will bring more risk than reward. The goal is to deliver a successful project in its entirety. Not to adopt a single development methodology religiously. We must be pragmatic. We must admit if the circumstances for any single approach will not work or are not appropriate. If Agile is a good fit, we should implement it skillfully but never in a dogmatic manner.
7. Once we have made that decision, we can evolve a plan for the whole project. We may have a release plan by then which could form a key element of that plan. In developing it, we should involve all the functions in the project to understand their needs and what they need from others. We should make the overall plan highly visible. Address risks associated with any part of the project, to develop increasing confidence in the plan. Make all responsibilities within the plan as crystal clear as possible. And we should revisit these questions at any stage of the project, if necessary
8. Ensure visibility and transparency around progress. We should:
   1. employ a cross-functional team regardless of whether we are using Agile.
   2. develop an environment where people highlight and raise issues as quickly as possible.
   3. invite feedback from stakeholders as early and frequently as we feasibly can.
   4. involve as many people as we reasonably can in decision-making while ensuring there is clear leadership around the whole goals of the project. Most importantly, the outcomes it will achieve.
9. Employ product-based planning at the heart of the project, again, regardless of whether using Agile or not. The configuration of the system should be highly evident (and central) using this approach. This will enable effective planning around each configuration item. The same can be said for integration, test and deployment planning. It will also provide the perfect vehicle to identify risk and develop a systematic risk management plan. Quite possibly the single most valuable thing a project can have.
10. Assuming we are using an Agile approach, all development planning (including release and iteration planning) must take place within the context of the overall project plan. There will be times when parties outside the development team will need to have input to iteration plans.  This is to respect the needs of the customer and the overall project. Having “rules” that prevent this does not reflect the real-world needs of customers and stakeholders. Nor will it maximise the business outcomes from the project. In simple terms, why the project is being done in the first place. If the Product Owner can realistically achieve this, fine. If not, other arrangements must be respected. In real Agile projects, the only priority is delivering maximum value to customers, not ‘religious’ adherence to fixed ‘rules’ or methods.
11. The goal is not to execute any single development methodology. It is to deliver a project that achieves the outcomes the customer is looking for. Yes, dates matter and dependencies (outside of the product development) cannot be ignored. Nor can we pretend they do not exist. Lastly, budgets matter too. Just like they would if it was our own money.

Lastly, why no diagrams or pictures in this post?

Because, as soon as you do, people start to discuss “process” and “frameworks” etc.  As if doing projects is like a manufacturing (stable) process.  Projects are nothing like this and trying to rigidly use concepts from the manufacturing world is only going to fail.

Notes/ references:

1. I received the following in April 2018, about a project in a major US Government department. It is not an isolated case (the sender gave me permission to publish this). “Yep, we had lots of challenges implementing Agile for important parts of the project, that didn’t involve software development. Training, contract management, RFPs, HR, data migration, coordination with external integration partners, etc. Scrum seemed to pretend those things didn’t exist and no one needed to manage them”. Under Sprint planning, the Guide says “The development team forecasts the functionality  that will be developed during the Sprint”. Clearly, there is a message here: Scrum teams work on functionality. They do not work on all those items listed above. “The Product Backlog is an ordered list of everything that is known to be needed in the product”. Another statement in the guide that clearly defines the scope of Scrum.
2. There is also the Scrum Master. But they are just a “master” of Scrum. They (usually) don’t do any work on the project. They are not going to manage the majority of what is in point #1 above if any at all.
3. Anything that includes both words “immutable“ and “rules” is prescriptive. There are many, many rules in Scrum. Prescriptive is anti-Agile. We will leave it to the readers to decide why Scrum is prescriptive.
4. “https://ronjeffries.com/articles/2015-03-01-testing-in-sprints/” and “https://twitter.com/jeffsutherland/status/571006531103100929” and “https://www.scruminc.com/getting-to-done/” and “https://labs.openviewpartners.com/succeeding-with-scrum/#.WwrpCe4vzIU”
5. “For the Product Owner to succeed, the entire organization must respect his or her decisions”.  That would be very nice – but will likely be a first. Is that what collaboration really is?  I must have been missing something all along.
6. “Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next”. This is a full-time highly specialist role. In non-software houses especially, this would be beyond the capacity of most product owners. “The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at the previous Sprint. Reviews to assess progress toward completing projected work by the desired time for the goal”. Really?
7. “Each Sprint may be considered a project with no more than a one-month horizon”.
8. Go to LinkedIn and put the word “Evangelist” into the search bar. Look at how many profiles come up, and what they all have in common.