As the title suggests, this post is about two different aspects of Scrum. The first part deals with Scrum not being Agile and the second part is about Scrum being fragile.
Before going more into detail, a short disclaimer: Everything I present in this post (and in this blog in general) is my personal view and does not represent the view of my current employer, my former employers and any future employers.
Scrum is not Agile
I guess a typical reaction to this heading would go like “How is this possible? Scrum is not Agile? Isn’t Scrum the number one Agile software development process?”. The short answer is that Scrum claims to be an Agile process, but the sad reality is that Scrum is quite far from being Agile. I will show you why.
Lets have a quick look at the Agile Manifesto. It states that it values “Individuals and interactions over processes and tools”. Lets also have a quick look at the meaning of the word agile. According to the Oxford Dictionary agile means “Able to move quickly and easily”. It is not a coincidence that the term agile has been chosen to represent the high-level ideas within the Agile Manifesto. In fact, one major point behind Agile is that in many software projects it is extremely difficult to move quickly and easily. This is not the case for a completely new project, but over time many projects get into a situation where sustainable development is simply not possible anymore. To prevent this (and other issues), the Agile Manifesto and the Principles behind the Agile Manifesto provide several high-level guidelines. These guidelines are not specific well-defined processes or tools and they allow for many different implementations. I suspect that both of these properties (high-level and allowing different implementations) were fully intended. The overall goal was not to present a silver bullet, but to help peers to avoid many of the pitfalls in software development, which the authors of the Agile Manifesto experienced first-hand and which fall into exactly these categories.
Now lets have a look at the Scrum Guide (written by two of the authors of the Agile Manifesto). In contrast to the Agile Manifesto and the Agile Principles, this guide seems quite lengthy. Surprisingly, the whole guide does not mention Agile a single time. I am not sure if this was historically always the case, but if the authors of the Scrum Guide do not claim that Scrum is Agile, then we would already be done with the first part of this blog post. I assume that this is not the case, so lets move on. The Scrum Guide is about a framework which contains “roles, events, artifacts, and the rules that bind them together”. In other words, it is a very specific and well-defined process. This does not sound agile and it also does not sound Agile (remember: “Individuals and interactions over processes and tools”). This is quite ironic and obvious. And this is where the whole Scrum movement should have stopped. But it did not and instead frustrates an increasing number of software developers all around the world. And whenever a Scrum project fails, it is not because of Scrum’s potential flaws, but because Scrum was not implemented correctly. That sounds like a nice transition into the second part of this post.
Scrum is fragile
This part is very short. I thought that the wordplay (Scrum being agile / fragile) is kind of funny and apart from that it perfectly describes one of the things that really bother me about Scrum: Whenever a Scrum project fails, it is because Scrum was not implemented correctly. And you can read about a vast amount of such projects. What does it mean, if a large number of intelligent software developers are not able to implement Scrum correctly? It means the whole framework is fragile. And this is another major argument against using Scrum. What is a framework good for, if it is so difficult to use?
Well, it seems that with the help of expensive consulting and coaching, as well as training and certificates, Scrum might in fact provide value. But it is not clear if this is value for the companies developing software and the hard-working software developers or for those who offer services in and around the Scrum ecosystem.
I would like to finish this post with a bit of my personal view regarding software development, Agile and Scrum. To me it seems that one very important part of high quality software development is to maintain a simple priority queue of tasks. The weight is a combination of the value a task provides for the customer / developers and the estimated effort to implement this task. For some developers this comes naturally. For teams and companies for which this is not the case, Scrum offers a rather expensive and inefficient implementation of a priority queue.
And lets be honest. Software development is a very difficult and complex work. Are we really surprised that so many projects fail? The field is still very young and we need to learn a lot. And this is crucial: We need to learn from past experiences, let it be failures or success stories. And here we collectively fail. We are not using the wrong processes or implementing the right processes in the wrong way. We are simply caught in a rat race and not able to make a short break in order to look at and learn from all the things that happened around us, maybe even before our time. It is our duty to extract the knowledge, the experiences and the wisdom from the many resources that are so easily available to us: The many many books, articles and videos about software development and, last but not least, the Agile Manifesto.
48 thoughts on “Scrum is fragile, not Agile”
I support you 100%. Scrum is basically used because it maximizes micromanagement. It is the form of slave labor that employees (except those like you and me) are wiling to endure.
I also completely agree with you. For 15 years of experience and 7 using scrum, I think scrum’s main and only idea is that a company has developers which it cannot thrust, therefore they should be given tasks as small as possible in order not to break something or change the system in unintended direction. At the same time tasks prioritization is given entirely in managers hands along with BigBrother control like process where developers role in the end turns them into code monkeys with inability to actually write code…
Spot on. I’ve never thought of scrum as a development methodology. It’s at best a management methodology. But it had certifications, titles, and oh so many tools you can but to make it even better. XP, as am agile methodology, at least addresses the developer side of agile – but there are no certifications or badges to add to your resume, and certainly no tools to buy. And so very few managers have ever heard of it. Go to an agile conference and they sponsored by tool companies.
Agree 100%. See my writing in The Pragmatic Programmer (new 20th Anniversary Edition) or some of the work I’ve started on growsmethod.com.
The pragmatic programmer was where it all started for me!
“which the author’s of the Agile Manifesto experienced first-hand and which fall into exactly these categories.”
“author’s” should be “authors”
What’s your alternative solution?
I guess as he mentioned; the Manifesto for Agile Development. https://agilemanifesto.org/
A medium term roadmap (a few months), a priority queue of tasks and a weekly engineering meeting to sync up on next steps and dependencies.
This has worked out great on multiple teams at different companies for me. We shipped a good product quickly.
I also 100% agree having 7 years in waterfall and 3 in scrum. I didn’t have to deal with scrum until I started working for companies that hire offshore devs or heavily contract. I have never worked near an offshore team that I even remotely trust, so I see the value in scrum for managing them, but not for 90% of onshore devs I’ve works with.
I personally made the case to my current supervisor that my attentending scrum meetings was a waste money and time. I can’t generally answer offshore tech questions in real time anyway.
If only we could get companies to hire professional translates for their offshore tea, s so we can have good com3instead of broken misunderstood English instead of scrum masters I think we would be better off.
Your words sounds to me those of an unsatisfied angry developer who spit on scrum because he failed to apply it. (Not judging you, just the words in the post)
You have smart points worth to investigate, but it is sad to see them wasted with the rants (“whole Scrum movement should have stopped”).
I would ask myself if I was you:
* Did scrum ever pretended to be the definition of Agile or the two are different things?
* Which are instead the conditions that brings so many Scrum projects to succeed?
* How do you measure intelligence of developers so to claim that they should be good in implementing Scrum successfully?
In my experience, I was lucky to apply Scrum and Agile correctly so now I understand them and can distinguish between them. In my current job, there are no chances to replicate those conditions and I do not expect Scrum to succeed (although we use a lot of Scrum terms to define what we do).
I think one should have experienced a successful scrum project before being able to criticise it.
Scrum is a tool: you may be Agile without using Scrum or you may find easier to be Agile using Scrum. Doing Scrum does not make you Agile.
Scrum is hard and implementing it takes different skills than those proven by individuals who can write code.
Cristiano writes: “…an unsatisfied angry developer who spit on scrum because he failed to apply it…”
1) He addresses this within the post. Isn’t it funny that whenever someone finds that Scrum doesn’t give the benefits claimed, it’s “because they’re doing it wrong”? If a method is that darn difficult to “do right”, then maybe the fault is with the method, and not all the people “doing it wrong”. Occam’s razor and all that.
2) That’s exactly the same answer you get from far too many people when you say “Communism doesn’t work” — “True™ Communism® has never been implemented anywhere!” Not for lack of trying, it’s been tried in lots of places. If an ideology is so darn impossible to implement, then maybe the problem isn’t the would-be implementers, but the ideology itself. Same thing here.
Cristiano again: “Did scrum ever pretended to be the definition of Agile or the two are different things?”
Maybe “Scrum” itself never pretended that (how could it? It’s a management philosophy; they can’t pretend anything), but all those consultants and managers sure are doing their best to _sell_ it as pretty much synonymous with “Agile”.
Your whole argument vindicates his point about the fragility of Scrum. This sounds more like dogma than like experience.
“Surprisingly, the whole guide does not mention Agile a single time”
There seems to be a single reference to “agility”:
“Understanding and practicing agility”
“I am not sure if this was historically always the case”
At least, this is in the 2004 book title ““Agile Software Development with Scrum”.
Over the years I’ve seen Scrum, and other approaches based on Agile or Watefall, work great, terribly and everything in between.
The Scrum Guide is written as a very prescriptive manner: you must do this, then this, and that. The guide also ends with the warning “although implementing only parts of Scrum is possible, the result is not Scrum.” So what is not present in the guide is a good explanation of how or why the different elements of Scrum are any better than any other methodology or framework for running software development projects.
It was only recently when I read the book on Scrum by Jeff Sutherland and his son Jeffrey Victor Sutherland. This book covers the ethos behind Scrum and gives the reader the information needed to make an appraisal as to whether Scrum may be for them or not. If it is decided not to adopt Scrum in its entirety, a company can decide the merits of each individual practice is useful to them and whether to include some of them as part of their on processes.
Something that tends to get missed a lot in the real world is success or failure usually depends on the presence or absence of an excellent product owner who is able to shield the development team from most of the buffeting winds of the businesses constantly changing demands.
Very often the Scrum Master role is seen as more essential than the product owner, sometimes the Scrum Master is also the product owner due to budget or other constraints, or there is a product owner but they are busy on other work and not in frequent contact with the developers. In short, most companies adopt the Scrum and implement it badly.
As you point out in this article, this could mean that Scrum is not right for the organization, rather than the organization being wrong for spending extra money not making the additional hires and re-organization activities needed to better implement Scrum.
Say this louder for the people in the back: “Something that tends to get missed a lot in the real world is success or failure usually depends on the presence or absence of an excellent product owner who is able to shield the development team from most of the buffeting winds of the businesses constantly changing demands.”
Once you have an excellent product owner, why do you need all the elaborate micromanagement mandated by Scrum?
Being product owner for more than 10 years. I hate scrum. I enjoy more working with Kanban style, less meetings, less micromanagement, less everything that people hate. Once I switched kanban, projects went straight faster and with more quality. That was and is my current experience. Scrum offers some predictability but in most cases it demonstrated me it is not. Saying “you will have this feature in 2 weeks” wasn’t always true, due nature of software development contingencies. But we good team meetings, kanban can be more predictable.
The perfect summary of a very well written piece:
“Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”
― Eric Hoffer, The Temper of Our Time
Couldn’t agree more…
The rules of Scrum offer nothing more than a starting point.
The whole point of a Sprint Retrospective is to examine how the process worked for your team; what went well, and what should be improved. When you decide what should be improved, and commit to that change, you are changing your process. You are adapting. What you end up with might not resemble Scrum at all. For example, if the team finds the daily standup to be a waste of time, they’re welcome to kill it. It’s all about the team optimizing for their needs.
So, yes, it’s true: if you’re not doing all the things Scrum prescribes, then you’re not doing Scrum… BUT that’s only true for the first Sprint. After that, you are expected to adapt it to suit your own needs.
You certainly have a point. My project manager spends ~80% of his time petting our supposedly Agile bug/req tracking tool.
I agree with your take regarding the micromanagement aspect of scrum. While initially I viewed scrum/agile with skepticism when I started using it +10 years ago, I was impressed with it’s brutal honesty and ability to track progress ruthlessly. But after time, I came to see it as you do, a means to micromanage developers. Also, I agree with the concept of using Kan-ban for development beats it hands down all the time.
If you connect Scrum with micromanagement, you miss that everything depends on people involved in work, no matter what kind of an approach you take (Scrum, Agile, Waterfall …). Scrum is all about teamwork, collaboration, etc. none of its part state about (micro)managing the people involved.
And believe me it gets worse when consultants sell “Large Scale Scrum” to the management (LeSS, SAFe, bs acronym of your choice, …). I’m currently experiencing the travesty called “Big Room Planning” which is the worst way of wasting lifetime I’ve ever encountered. It feels like a therapy session for developers who lost their ability to code and now try to spend their time in one useless meeting after another to look busy.
100% disagree. It’s not SCRUM that’s fragile, it’s working with people which is fragile. In my 10+ years in software development, I’ve seen various “frameworks” succeed and fail. And not ever did waterfall sound logical to me. As if any designer, architect or business analyst would know all the requirements of a project that spans multiple years. So that would block the entire “queue”.
It turns out that if you trust people on your team to do their thing and they trust you to do yours, the best software is delivered.
I’ve been a product owner of multiple teams for a couple of years now (not all at the same time, who’s got time for that?), and not once have I used SCRUM as a vehicle of micromanagement, neither offshore or on-site. That’s not what it’s for.
The micromanagement comes with inexperienced stakeholders that need to be educated and need to learn how a team works.
Waterfall is great to projects that can’t fail and can’t be fixed after launched (see Apollo space craft)… not so hot for fast and ever changing (see Amazon Prime).
Scrum isn’t good for either end. It’s a management process not a development process.
I have seen Scrum of many kinds used at many teams at different companies the past 12 years and just as with teams and companies on their own, some perform horrible and some perform great and everything in between. One of the keys to have a good working team is for a team leader and management to determine what is working and not, and what is needed. Scrum methodology can be of great help, but not if you see it as a holy grail or a goal on itself, or a silver bullet solving all problems. Rigidly applying a methodology will hardly ever work and generates bureaucracy, and resistance and negative sentiment amongst employers. It is all about the team, the people, the company, the kind of work, the requirements, and what the customers needs. And also; the entire company workflow and communication with customers often need to change and improve as well if software development is important, not just the development department.
Attempting to rigidly apply anything and then complaining that it is not “agile” seems disingenuous. In order for Scrum to be agile, it must be executed with flexibility. Any other approach will obviously not be agile and will likely be doomed to fail.
Interestingly your first premise seems flawed. You mention that Agile values “Individuals and interactions over processes and tools”, surely you are not saying that that processes and tools aren’t used or valuable in agile?
But you say that Scrum “is a very specific and well-defined process. This does not sound agile and it also does not sound Agile (remember: “Individuals and interactions over processes and tools”)”. Nothing can be done without some level of process and tools, it’s just that agile values individuals and interactions more.
The above article “Scrum is fragile, not Agile” is more informative. This is more helpful and i have gained more knowledge through this. Thanks for sharing
You are hung up on the word “Agile”, but if you substitute the word “Adaptive” for all the uses of the word “Agile” then the manifesto would tell a totally new story. The misunderstanding of “Agile” being “Fast” would have gone away and we would have lived happily ever after – this article then might not have served any purpose.
Really nice information you had posted. Its very informative and definitely it will be useful for many people.
I am expecting more interesting topics from you. And this was nice content and definitely it will be useful for many people.
This is an interesting statement: “Whenever a Scrum project fails, it is because Scrum was not implemented correctly.”
Aside from the fact I have never experienced a ‘scrum project’ (and not I’m wondering if that’s almost an oxymoron) I’m caught on that word “correctly”. Scrum simply creates a space/provides a framework for a context-sensitive process to begin. Any such process is expected to grow/evolve/improve over time. When would it be “correct” I wonder. At the start? Half-way through? At the end (is there an end)?
It also has me wondering what is the cause when /any/ project fails. Could it be that people just were not paying close attention to an ever-changing world, and blundered on working and delivering the wrong thing? Or could it be that the environment the workers were in did not bring out the best in them? There are so many reasons for failure, but of course having a Named Thing always makes it easier to not look at the underlying truth. Blame the Thing.
Scrum is not magic. Scrum actually doesn’t do anything. People do things—and good people do good things.
Scrum is not Agile? That’s good to know. I’d suggest that [uppercase] Agile is not agile. It is big, heavy, clumsy, forceful, unbending, unchanging, violent, oppressive, and tightly tethered by the constraints of profit. Not agile, and not adaptive.
Stop it. Common sense. Proper understanding of what it takes to develop software properly. Ridiculous. Haven’t you heard that the way to success is to enthusiastically embrace the latest fashion … especially when, done badly, it allows managers to micromanage developers and has lots of nice buzzwords and statistics.
I have been in software development for most of the last 40 years. SCRUM is just the latest of a long line of fads in search of a non-existent silver bullet that will enable teams of mediocre developers to produce great software. Smart people were producing great software back in the 1960s and 1970s (e.g. Ritchie, Thompson, Kernighan, Stallman, Gosling) and they were not constrained or hindered by any “ology”). Some of them are still making geat software 50 years later and I would bet lots of money that they are not using SCRUM.
Great software comes from creating teams of appropriate size comprising individuals that understand design, coding and infrastructure, that understand the problem domain, that are competent with their tools, and are personally committed to doing a good, professional job … whatever it takes.
A good manager that can actually manage (rather than merely having the word “manager” in their job title) is also a great asset.
Everything else is secondary, or even gets in the way.
SCRUM is a rigid methodology that is suitable for some kinds of project. It enables one aspect of agility (responding to changing requirements) while hindering the others (especially “Individuals and Interactions over Processes and Tools”). This is all so obvious that it is hard to understand how otherwise smart and capable people can fall for the “SCRUM is Agile” mantra.
Once requirements were complete and development had begun, change was just not something that was easily entertained. Let’s keep in mind that concepts such as Continuous Integration and Configuration Management were unknown and use of source control repositories was not as mainstream as it is now. A change in requirements was just quite difficult to accommodate and was generally frowned upon.
A great response to this article: “‘Scrum is fragile, not Agile’… Are you Serious?!” by Sjoerd Nijland https://link.medium.com/BJbCoHnEtY
In a nutshell, Agile is about communication, teamwork, collaboration, adaptability, iteration, feedback, and of course, agility! The development initiative is broken down into efforts of short duration and change is not only expected, it is embraced by all stakeholders. To successfully implement Agile, an organization must embrace its concepts and philosophies at all levels.
Here’s a little video about “beautifully empty” Scrum from one of the co-authors of the Agile Manifesto, Dr. Alistair Cockburn; answers quite a few questions https://youtu.be/AuUadPoi35M
You know what methodology helps me write great code? SCIENTOLOGY! Anyone who disagrees that L. Ron Hubbard Tech is the Way, the Truth, and the Light is nothing more than a foolish cowboy coder. The Tech ALWAYS works if you chant the mantras in unison with your team every hour and keep your e-meters in working order. Oops, gotta go–I’m late for my collaboration-boosting False Purpose Rundown session! After all, the best code can only be written by certified OT VIII Level Tech practitioners… Stand tall, y’all!
I have been developing from over 20 years. Agile started off encompassing basic common sense principles that all experienced developers and managers already knew. It has since evolved into a cult like mentality with spin-offs like Scrum. You cannot develop a solid, efficient scalable large application with a assembly line mentality following some guide or rule book. You MUST consider the business processes is will include, how it will do them and what it might do in the future. It will just turn into a Frankenstein, bug laden, inefficient mess otherwise, like most modern applications are these days.
Scrum appeals to executive management because it attempts to sell snake oil, a fix for all you development ailments. Every failed implementation of Agile and more so Scrum is explained away by the mantra “You just didn’t do it right” or “That’s not Scrum”. It fails because it invites management abuse and incompetence. It enables managers to use meaningless metrics to show success when in reality the team has created a load of garbage. It gives the perception that as long as you follow the rules you’ll produce workable, desirable software or the ability to “fail fast” to reduce the risk of a revenue black hole. It gives the impression you can hire a team of inexperienced managers and developers and succeed. You simply cannot…
No one that I know of back in the day used waterfall as its currently described, it’s a strawman methodology. No legitimate software company would be so inept as to develop for a year or half a year without working directly with the customer along the way to see if they’re on the right path. We delivered many highly scalable, easy to fix enterprise software solutions for the energy industry. We did have an adequate functional and technical system design. Enough to encompass actual use cases, test cases and the overall business processes prior to development. This allowed for definable milestones for customer sign-off. It ensured there was no waffling on “did we deliver what was promised”. It allowed for the proper measure of success. You knew if you were behind or ahead, whether you delivered something of value to the customer or not.
You can’t create anything manageable and efficient without that analysis, not anything large anyway. Even a small change in a business process or data type can quickly become a monumental task to implement if it was not considered from the beginning as likely possibility. You end up with a bunch of hacks and work-arounds degrading scalability and maintainability due to lack of proper planning. It’s akin to building a house on a concrete foundation without knowing where the plumbing will be.
Scrum also burns out good developers and is a disincentive to innovation and exploration of better methods of accomplishing a programming task. Scrum is promotes a “get it done now” and deal with he consequences later mentality. We used to evaluate code methods under load, attempt create reusable code as much as possible which can be time consuming upfront but saves an immense amount of time on the maintainability side. What’s the point if you have a burn down chart to adhere to. What benefit is it to the developer to do anything like that?
I read a while back Blizzard Entertainment went full on Scrum. I knew at that time their products would quickly deteriorate. Look how many of their recent product releases have utterly failed to meet customer expectations. Is this due to Scrum…I can’t say for sure, but in my experience it’s par for the course. I would argue successful large scale products developed using Scrum do it in spite of Scrum not because of it.
Great blog for scrum software development. thanks for sharing information.
I like xp. Having folks that have questions and others with the answers at the same time is fun and productive. Tracking it in jira (kanban or scrum) makes no difference. The daily standup is all but useless in my 15 years of various “agile” methods