Why Scrum alone does not work,
Why Scrum (alone) does not work,
and, what will work much better:
The purpose of this post is to describe the limitations of (just using) Scrum and then later we describe what would work much better, while still using incremental product development. In particular, in the second part we focus on how to move well beyond the mantra of delivering “value” to something far more real, beneficial and measurable, collaboratively.
Agile is a collection of values and principles relating to software development. A number of “Agile” methods have emerged (since 2001), the most common of which is Scrum. However, Scrum has become controversial and 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. Furthermore, we believe that Scrum is not enough for the majority of projects and especially when you are engaged 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 and includes many rules, that it says must not be broken. Some of those rules lead directly to the issues that follow.
- Scrum focuses on product development via the product backlog. On vast numbers of projects, there are many other things (1) that have to be done and managed outside of the product development and Scrum ignores these or assumes the team will recognise these things (while they are being judged by their velocity in relation to the software development) and collaborate to get them all done. Scrum defines a team as only being the “professionals” required to “produce a single product increment“, while literally forbidding any other role to exist other than the Product Owner, outside of the core Scrum team (2). This is simply not real world. Scrum does not cover all you have to do or recognise you will need many other roles to deliver a successful project.
- 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.
- Scrum includes no Software Engineering practices and can easily result in technical debt, considerable code refactoring or even development being scrapped, once requirements are fully understood in later Sprints, making 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.
- Scrum encourages that deployable code is developed per sprint, but makes no mention of the relationship between deployment and updates to business processes and functions that are likely to be required/impacted.
- Scrum is inflexible and prescriptive (3) – it states there are only 3 roles allowed even though none of these roles are likely to pick-up and manage the items mentioned above in #1. It is full of “Rules of the game” which is always going to raise the likelihood of issues (and gaps) that really should not be happening.
- 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.
- 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 the real reason why Scrum authors themselves admit (4) that large numbers of Scrum teams do not produce shippable product at the end of each Sprint. The other reason for this is that large numbers of Scrum teams fail to test inside Sprints, and 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.
- The guide makes some astonishingly sweeping statements about all Scrum teams: “Everyone focuses on the work of the Sprint and the goals of the Scrum Team”. While this statement sounds great, if we are being honest, if we are all being totally honest we know it is optimistic. As an underlying key principle and assumption, it leads Scrum to make some very bad decisions, especially around areas such as leadership. Scrum lacks leadership.
- 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 can be wildly optimistic (5). There are some key responsibilities on projects that Scrum places on them that they are rarely going to do in practice (6).
- 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 (7). 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.
- Scrum refuses to recognise roles such as “lead developer”. This de-motivates people and affects quality.
- Scrum quotes words like “openness, respect and professionals” while defining a framework that results in more micro-management than most people care to be subject to. Especially when you add the use (and misuse) of velocity. Add this to the frequency of sprints and many highly professional developers are going to see this as a very short-term environment for them. Burnout is going to happen very quickly.
- 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.
- Scrum Masters don’t lead dev teams but they do lead the Scrum process in a team. Anyone can get a Scrum certification after two days of training, regardless of what they did previously and call themselves a Scrum ‘coach’. Or even worse: an Agile transformation coach.
- Scrum and Agile are often described as a “religion” (8). A religion is something a group of people believes in, but no one can prove its basis. When any kind of belief starts to alienate people who are not from within, bad things usually follow.
What would work much better?
- 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 intended 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.
- 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 and technology leads and delivery managers. This is to ensure we have optimum ideas and we start to build a common understanding of what we are trying to achieve, not just what we are trying to build. We must always be focused on the outcomes we want to achieve, not just the products/solutions we want to build.
- 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.
- As soon as possible, we should then involve people who have experience of design, architecture and/or systems engineering, depending on the exact nature of the solution. We should also involve a project manager who preferably has experience of this type of project. As early as possible, we should start to evolve an understanding of the full scope of work of the project, not just the product development. We should look at aspects such as design, integration, testing, data migration, business change and deployment at the whole project level to ensure there is coherence and validity to all aspects, especially integration and testing (two aspects where Scrum is 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.
- 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 not be managed in isolation; it must be managed as an integral part of the overall project. All people in the whole project team must be fully aware of the broader business needs of the project and the outcomes it is intended to achieve, and they should take these into account in all their decisions.
- Then, we should decide which development approach we can and should take. This may be Agile assuming Agile is a good fit for the project. If it is 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 in terms of the approach and 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 flexibly and with skill but never in a prescriptive manner.
- 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 this, we should involve all the functions involved in the project about their own element and what their needs are to be successful and what they need from others. We should make the overall plan highly visible, and address risks associated with any part of the project, to develop increasing confidence in and commitment towards the plan. We should make all responsibilities within the plan as crystal clear as possible and should it be necessary to revisit this question at any stage of the project.
- Regardless of whether we are using Agile or not, we should employ a cross-functional team, develop an environment for the project where issues are raised and highlighted as quickly as possible, have visibility and transparency around progress, and invite feedback from stakeholders as early as possible and as frequently as we feasibly can. We should involve as many people as we reasonably can in decision making too while ensuring there is clear leadership around the whole goals of the project, and most importantly the outcomesit is intended to achieve.
- We should 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, which 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 – possibly the single most valuable thing any project can have.
- 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 do not reflect real-world needs of customers, stakeholders and delivering projects successfully (i.e. the business outcomes that underpin why the project is being done in the first place). If this can all be achieved realistically via the Product Owner, fine; if not other arrangments must be respected. In real Agile projects, the highest priority is delivering maximum value to customers, not “religious” adherence to fixed “rules”.
- 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; and yes, dates matter and dependencies (outside of the product development) cannot be ignored in that process 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”, “framework” etc. as if doing projects is like a manufacturing (stable) process. Projects are nothing like this and trying to borrow concepts from the manufacturing world is only going to address a small part of delivering projects well. It can also lead to a major mismatch in terms of what is really needed.
- The following was sent to me in April 2018, involving a current 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.
- 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.
- 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.
- “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”
- “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.
- “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 previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal”. Really?
- “Each Sprint may be considered a project with no more than a one-month horizon”.
- 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.
Contact Us Now
Email us today to find out more on how we can help you.