“Scrum is fragile, not Agile”… Are you Serious?!
A serious reply.
Serious Scrum is a community for those who dare ask for help and are committed to practise Scrum well. We encountered many Scrum practitioners haunted by anti-patterns, myths, misconceptions, outdated notions and ignorant management. We also address many trending articles as a response to helping those improve both their understanding and their practise of Scrum.
In this ‘serious reply’ we reply to Dennis Weyland’s blog post to share our perspective on his argument that ‘Scrum is fragile, not Agile’:
I fully respect and understand why Dennis is critical of Scrum and that anyone should be critical over its appliance. And, with Dennis being a researcher too, I hope that he is open and will enjoy a critical response to his article.
“Scrum is not agile”
Dennis opens up with a defence. He sets the stage by responding to a typical reaction he imagines to the statement “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.” — Dennis Weyland
Now, to be fair, our reaction to “Scrum is not Agile” would be “Are you serious?!”.
Let’s break down Dennis’ response:
“Scrum claims to be an Agile process” — Dennis Weyland
Dennis builds on Scrum being a process so as to leap to “Individuals and interactions over processes and tools”… in order to conclude that Scrum is not Agile.
I would like to know where Dennis’ based this claim on that Scrum is a ‘process’, which is a well established myth/fallacy. Dennis even goes as far to stating
“This is quite ironic and obvious. And this is where the whole Scrum movement should have stopped” — Dennis Weyland
Dennis argues that the Agile manifesto intends for teams to be able to allow for different implementations of processes. Dennis, don’t you know that Scrum enables teams to construct, adapt and employ various processes?… in fact:
“Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.” — The Scrum Guide. Emphasis added.
Scrum is teamwork. It’s all about enabling interactions between individuals, so they can figure out what processes and techniques work best for them.
“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — The Scrum Guide
Team decides.
“The Scrum Guide doesn’t mention ‘agile’ at all.”
Dennis continues his argument stating that the Scrum Guide doesn’t mention the term ‘Agile’ ergo, Scrum is not Agile… Are you serious?!
“Now let’s 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. [..] 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.” — Dennis Weyland
As Dennis states that Agile Manifesto is written by authors of lightweight development frameworks (including the creators of Scrum and including Mike Beedle who also helped write the Agile Manifesto and that he too practised Scrum). The intention of Scrum is indeed not for teams to become ‘AgileTM’. The intention of Scrum is in fact to enable people to address ‘complex adaptive problems, while productively and creatively delivering products of the highest possible value’. One of the ways Scrum enables teams to do this, is to increase a team’s ‘agility’ and to enable teams to embrace empirical process control over defined process control. Yes, the Scrum Guide doesn’t mention ‘Agile’, but Dennis conveniently ignores that the guide does refer to ‘agility’, ‘flexibility’, ‘empiricism’ and ‘adaptation’ multiple times, throughout.
“Scrum is fragile”
Dennis opens up the argument that Scrum is ‘fragile’ based on the concept that “whenever a Scrum project fails, it is because Scrum was not implemented correctly.” — Are you serious?!
“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.” — Dennis Weyland
Whether or not teams and organisations can experience the benefits of Scrum is not determined by the number of intelligent developers that practise it. It highly depends on a number of prerequisites like embracing values that create trust, for teams to be both cross-functional and self-organising, for incremental development to be enacted through a routine of creating transparency, performing inspections and practising adaptations, but also for the organisation to not only understand Scrum, but to support it too. And that’s what makes Scrum difficult to master.
But does ‘difficulty’ equal ‘fragility’? Dennis makes the leap that Scrum is hard, ergo it is fragile.
“What is a framework good for, if it is so difficult to use?” — Dennis Weyland
Scrum is, as its guide states: “Difficult to master”. There is no easy hack to maximising value in complex environments, but through Scrum we are discovering increasingly easier and creative ways to become better at it.
Practice and persistence breeds excellence. Similar to a sports organisation or sports team, those that give in with a blame-the-game mindset “cause it’s haaaard” won’t indeed enjoy the benefits of Scrum like making work valuable and enjoyable. Dennis correctly anticipated this response as the community appears divided between those experiencing the value of Scrum and those who struggle with their practise. There are indeed many who rather blame the game whilst practicing it in a half-assed way.
It’s important to understand that Scrum acts as a mirror. Transparency. If you don’t like what you see or experience… you can adapt or remove the mirror, sure… Or you can improve on that which it shows.
Then there are those attempting to improve their own play through continuous inspection and adaptation. Continuous Improvement is simply not something many office-dwellers are accustomed to. Many simply settle comfortably somewhere along the path of least resistance inside a SNAFU status quo.
“A Queue Of Tasks”
Dennis closes his argument explaining this own personal perspective of Scrum is that being a ‘a simple priority queue of tasks’ which ‘weight is a combination of the value a task provides for the customer / developers and the estimated effort to implement this task’ and that ‘Scrum offers a rather expensive and inefficient implementation of a priority queue.’
If this is indeed the definition of Scrum put in one’s own words, it points directly towards the essence of where Dennis’ challenge with Scrum lies. If Scrum is not perceived to be a canvas that enable teams to create a better world of their own, if it is not perceived to be a means to enable continuous improvement of the product, work-environment and team, if it is not considered a means to develop products of increasingly higher value and quality in an enjoyable way… how can one not see it as indeed something other than a way to organise tasks?
Dennis somewhere along the way missed the concept of self-organisation in Scrum, and that ‘the best architectures, requirements, and designs emerge from self-organizing teams’.
Dennis missed that in Scrum ‘at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly’ (through Sprint Retrospectives for one).
Dennis missed how Scrum’s events exist to promote interactions between individuals so they can self-organise their work, processes and tools and that these events exist because ‘the most efficient and effective method of conveying information to and within a development team is face-to-face conversation’.
Dennis missed that a team’s constant focus on that which is most valuable and to collect feedback from customers by reviewing continuous deliveries together is because it is their ‘highest priority is to satisfy the customer through early and continuous delivery of valuable software.’
And how did Dennis miss that Scrum Teams adapt their plan daily as they ‘welcome changing requirements, even late in development’ because ‘Agile processes harness change for the customer’s competitive advantage’?!
Dennis… are you serious?!
Complex work
“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.” — Dennis Weyland
Indeed Dennis, Software Development is complex and that is precisely why so many software development organisations adopt Scrum as it is designed so people can self-organise their own approach to address complex adaptive problems and it does so by staying lightweight itself. Scrum is designed to probe-sense-respond (transparency-inspection-adaptation).
Dennis closes his argument with a call-to-arms:
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.” — Dennis Weyland
If you are not making the short breaks to inspect the way you work, to learn from it and adapt, you have completely, and I do mean completely, missed what empiricism in Scrum is about and why (for example) events like Retrospectives (where Scrum Teams ‘take a short breaks to look at and learn from things that happened around them’) exist.
“Empiricism asserts that knowledge comes from experience and making decisions based on what is known.” — The Scrum Guide; emphasis added.
The craft of Software Development is indeed young in comparison to woodcraft for example. Hence Scrum’s foundation is that of empirical process control, which is making choices based by carefully inspecting and adaption based on actual practical experience.
“In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide
Why so serious?!
Sure enough, if you share the conviction that organisations collectively fail at Scrum ergo Scrum is not Agile, you can settle the argument there. But that is not all that constructive. If instead you are open to consider that maybe, just maybe, it is one’s own understanding and practice of Scrum that could use a little tweaking too…. and if you are willing to put in a little bit of effort, consider joining our community of Serious Scrum practitioners who are there to help each other along their journey. Share with us whatever it is you or your team is struggling with and we can provide share experiences and maybe help you with some simple next steps. We enjoy sharing experiences and helping others improve.
continue watching:
Roel Trienekens kindly introduced this video to how Alistair Cockburn (also a co-author of the Agile Manifesto) puts it:
continue reading:
continue the debate:
