“You can’t be Agile with Scrum…”
Are you serious?! — Episode 17 part 1/2.
I can safely say I’ve engaged a fair bit with the community. I talked to numerous professionals, practitioners and recruiters. At times I’ve been confronted by the argument that: “If you Scrum, you are by default not Agile”. I was surprised by this at first and it made me curious. So I wanted to understand…
But first: are we talking ‘agility’, ‘agile’ or ‘Agile’ or ‘AgileTM’, ‘Heart of Agile’, ‘Modern Agile’? This question in itself reveals a lot about the state of Agile today. I will stick to Agile as how it is defined in the Agile Manifesto (AM), and ‘agility’ as in the ability to timely adapt, respond to change, continuously improve. Sure, the whole Agile Industry has transcended the manifesto, and IMO by disrespecting its very values and principles (I am looking at you SAFe). For Scrum I will stick to its source material: its definition in the official Scrum Guide (SG).
I’ll start by summarising the top 5 arguments and listing some sources that agree with the notion that with Scrum you are indeed not Agile. Let me know if you know any more that surely deserve to be listed here.
Common myths:
- Myth: Scrum is a predefined way of working that doesn’t change and is thus rigid, not agile.
- Myth: Having a set of rules defined in the Scrum Guide is dogmatic, and thus not flexible.
- Myth: Scrum is a merely a framework, but Agile is a mindset.
- Myth: Agile is culture, which is unique for every organisation. The ‘one-size fits all’ idea with Scrum will not enable companies to figure out what works best for them.
- Myth: Scrum is for Software Development but Agile is more holistic and can be applied to any type of organisation.
These statements are a genuine slap to Scrum’s face from Agilists. Let’s debunk them.
Some sources here on Medium:
Why Scrum Doesn’t Make You Agile — Karin Dames
You will not become agile by implementing scrum — Jurriaan Kamer
This motivated me to a tedious exercise of running through every single value and statement in the Manifesto and explain how these come to life through Scrum, as defined in the Scrum Guide.
If Scrum is put into practise as intended, and indeed played the way it should be played, your Scrum Teams are Agile.
“Uncovering better ways of developing software.”
Let’s start with the very first (and often overlooked) mission statement of the Agile Manifesto.
“We are uncovering better ways of developing
software by doing it and helping others do it.” — The Agile Manifesto
This very first statement instantly debunks argument 5 (Scrum is for Software Development but Agile is more holistic). In fact, the opposite would be true today. The Manifesto explicitly mentions it is written for Software Development (it is even titled: Manifesto for Agile Software Development).
Now let’s take a look at the definition of Scrum as defined in the Scrum Guide:
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — The Scrum Guide
Scrum is not limited to Software Development. In fact:
“Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.” — The Scrum Guide
Ron Jeffries wrote up perfectly well why Scrum is not an Agile Software Development Framework.
So yeah, sure one might argue that the Agile Manifesto too can be (and is) applied more broadly too. But here I will also debunk the myth that Scrum is rigidly defined, but Agile isn’t. In fact, again, the opposite is true.
The Manifesto, as its authors have agreed, is a historic document. It will not be changed or updated. Sure there are non-official initiatives like Modern Agile, but no matter how many times we will jump up and down, Agile’s definition will not change. The Scrum Guide, on the other hand, has been revised numerous times. Feel free to suggest improvements too!
But to answer if through Scrum, better ways of developing software are discovered, I can safely say that Scrum Teams are indeed figuring out ways on how to improve Software Development. This happens continuously. With Scrum they implement improvements to the way the Scrum Team does its work all the time, including “its development process and practices”.
Are they helping others do it? Scrum Teams value transparency and openness. Also, the Scrum Master is actively “Helping employees and stakeholders understand and enact Scrum and empirical product development;” — SG. A Scrum Master too works with other Scrum Masters to exchange experience.
Let’s move on to the four values of the manifesto:
Individuals and interactions over processes and tools
“Scrum is a process, right?! it prescribes how teams do their work, righttttt?!” — Err.
“Scrum is not a process, technique, or definitive method” — The Scrum Guide
Scrum doesn’t prescribe processes or tools on the way the Scrum team does its work. Sure, Scrum does prescribe a set of recurring events that enable interactions between individuals. It exists to encourage teams to experiment to make them more enjoyable, meaningful and valuable. They exist so the team can work out their own processes on how to approach their work.
“Scrum is a framework within you can employ various processes and techniques” — The Scrum Guide
At first I didn’t really put a meaning to the term ‘framework’; I found the term to be abstract. Framework, Methodology, Process…so what?!
The best way I managed to explain it to myself is that a framework holds a canvas.
This canvas allows your team to create a world of their own.
“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — The Scrum Guide
Scrum is teamwork. It’s all about enabling interactions between individuals so they can figure out what processes and techniques work best for them.
Working software over comprehensive documentation
“Scrum is all about documenting work up front in User Stories right?” — Err.
Let’s start with the focus of Scrum on ‘Working Software’. Or in Scrum’s more holistic perspective: Working Product (Increments). Scrum Teams aim to deliver working Increments each Sprint:
“the new Increment must be “Done,” which means it must be in useable condition” — The Scrum Guide.
This means that each cycle, the team collaborates to build something that works. Sure, value could be defined upfront to determine what the team should focus on next, and this is defined and refined in a Product Backlog.
However, this doesn’t describe the work that needs to be done on it upfront. This is only defined later on during the Sprint itself, and only to an extend that the Development Team itself thinks is needed.
The Scrum Guide also indicates that refinement of the Product Backlog is generally no more than 10%, so generally the rest of the time is spend on collaboration on the development of the Increment.
Scrum teams focus on a collective Sprint Goal, which is defined by the whole team during a collaborative session. Scrum teams are free to work out their approach as they progress.
At the end of the Sprint, the Scrum Team invites Stakeholders to inspect the working Product Increment and to provide feedback, which is instantly processed through direct interaction, thus limiting the need of exchange of comprehensive documentation.
In general, documentation is poorly written, at times completely in-comprehensive and incomplete. They often describe a ‘desired future state’, which ends up surviving, so it becomes a ‘historic desired future state’, which is generally not representing the actual state. Scrum teams thus frequently inspect the actual product. Some teams embed tests to ensure the product remains in a useable state (ie. TDD, ATDD) and make anything that is known about the behaviour of the actual product as transparent as they can (ie. BDD).
Remember, the statement of the Manifesto doesn’t imply there should be no comprehensive documentation at all. There should. But teams should mainly focus on the working product itself. Scrum enables teams and stakeholders to frequently inspect the working product and make that what is known about the product transparent, and this happens mainly through direct interaction. Documentation occurs, but well within acceptable limits.
“Scrum users must frequently inspect Scrum artifacts [SN: which includes the Product Increment]and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.” — The Scrum Guide
Scrum guides teams to focus on developing working increments responsibly. It promotes that any documentation that does come into play, is transparent and reflects the actual state of the working increment. It explains that, when this doesn’t appear to be the case, “An adjustment must be made as soon as possible to minimize further deviation.” — SG.
All that is technically needed to be refined up-front is, well, just enough so the Development Team thinks it can be done that Sprint.
“Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.”
The degree of documentation is not specified by Scrum and is left up to the team to determine themselves as they align on their definitions of “Done”.
Customer collaboration over contract negotiation
“With Scrum, isn’t there constant negotiation about which scope gets delivered in a Sprint? and what requirements the PO values over others with Stakeholders? Or what about all that negotiation involved in getting clients onboard with open ended scope?” — Err.
Let’s start with the role of Product Owner. A single representative of customers, users, stakeholders that is in fact a member of the team. This representative of the customer is continuously collaborating with the team to work out routinely and directly what the team is working on now and next. This isn’t a negotiation. The Development Team will forecast what it roughly thinks it can do, and the Product Owner forecasts what is likely the most valuable thing to work. The past performance of the team will reveal what the team is likely capable of taking on next, and even that is only a forecast. This should be non-negotiable if the pillars of Scrum’s framework are upheld. If there is a constant negotiation about the estimate complexity of Product Backlog Items, or how much a team has to take on or complete in a Sprint, teams might be forgetting that the entire Scrum theory is based on Empiricism.
That said, continuous collaboration too involves negotiation. This negotiation shouldn’t get in the way of collaboration. The more Scrum’s values are embraced, embodied and lived by the Scrum Team, the more trust is build for everyone. More trust equals more collaboration and less negotiation.
Nowhere does the Scrum Guide refer to how contracts with Scrum are to be negotiated. In a way, all that can be implied is that at least Scrum Teams should frequently inspect and adapt whatever it is they agree upon and make sure everyone has a shared understanding of it.
That said, ScrumInc, does share a model with us called “Money for nothing, Change for free”.
Scrum promotes collaboration through direct involvement of stakeholders and through having a representative (empowered by the customer) as a member of the team. Again the routine facilitates these collaborations, but doesn’t dictate exactly how they should take place. These interactions promote teamwork or partnership if you will. Embracing the values will grow trust. Embracing empiricism shifts negotiation from ‘what a team has to do/should be doing’ towards evaluating what the team has been able to do and trust in the continued performance of a team. Focus also shifts from ‘does the team deliver x timely’, or from monitoring a teams velocity to ‘what is that the team actually delivers, is actually returning’ and collaboration shifts to improving the latter. All this is effectively enabling teams to (learn to) value customer collaboration over contract negotiation.
Responding to change over following a plan
Let me quote Karin Dames here as an example, as I’ve talked to various people who seem to share this conviction in explaining why Scrum doesn’t make you agile. I am sharing this particular one as I can understand why she wrote this and I respect that she did. She challenges the Sprint Cadence. Should it be as consistent (or rigid) as Scrum prescribes? referring to this statement from the Scrum Guide:
“ Sprints have consistent durations throughout a development effort.” — The Scrum Guide.
Why can’t these durations be flexible/adaptable? That doesn’t sound all that ‘Agile’, right? or, as Karin writes:
“The Scrum guide suggests that the sprint, for example, is time-boxed and should have consistent durations throughout development, valuing the plan over responding to change.” Scrum Doesn’t Make You Agile — Karin Dames.
Now, truth be told, Scrum does indeed value making plans. In fact, all the Scrum Events result in a plan. One is even called the Sprint Planning. So I get the sentiment that Scrum is all about planning. It indeed involves continuous planning. However… [wait let me… emphasise this]
HOWEVER!
These plans are adapted, all the time. Scrum teams plan in short intervals not to stick to them, but to adapt them based on what they are discovering throughout their journey.
“The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive.” — The Scrum Guide.
All Scrum’s plans emerge. Though the Sprint Goal (the raison d’être of a Sprint), doesn’t change, the plan on how to achieve it is adaptable. Scrum even accounts for the ability to cancel a Sprint, if the Sprint Goal becomes obsolete, as a means to adapt to rare events.
“ A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.”” — The Scrum Guide.
She suggests that the Sprint interval and timebox should not be fixed, but stay flexible as there could be many events/disruptions that could cause something to take longer or be finished sooner.
Please understand that the Sprints duration is not a deadline for work to be finished, but to keep the routine consistent, as consistency reduces complexity.
“Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.” — The Scrum Guide
It’s to get people together at regular interval so they are routinely and consistently… (here it is:) inspecting and adapting.
“Scrum prescribes four formal events for inspection and adaptation” — The Scrum Guide.
Every day the team inspects and adapts.
“Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.” — The Scrum Guide.
Every day the team is responding to change. They work through newly discovered complexities and what could be of potential value next.
“The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.” — The Scrum Guide.
They focus on what is most valuable that day, each day. If there is anything that is making the team flexible and adaptable… if there is anything that promotes agility… it’s the regular recurring events during which Scrum Teams collaborate on how to adapt.
“Each event in Scrum is a formal opportunity to inspect and adapt something. […] Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.” — The Scrum Guide.
In fact, the entire theory of Scrum is built on empricism:
“ Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” — The Scrum Guide.
Even The Sprint Review, which is held at the end of a Sprint, isn’t meant to check if the team completed its work on time, as there is no such thing in Scrum, but
“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.” — The Scrum Guide.
Even the Retrospective exists to provide the team with an opportunity to adapt as a team.
“Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.” — The Scrum Guide.
So if there is anything that screams ‘responding to change’ it is Scrum’s seemingly tireless routine of inspection and adaptation, occurring in regular consistent intervals. It is, perhaps ironically, this consistency that promotes agility. This consistency does not equal rigidity. And even when the consistency of a sprint cadence sounds fixed, it is not. The Sprint Length can be adapted, but it really pays to know under which conditions this will lead to either increased or decreased adaptability.
So, although I am properly fired up to continue on to the 12 principles, I think it is best to continue that in a second part of this episode.
By all means, I am writing this article, not as a means to one-way promotion of my own assumptions, but to engage. Am I missing the point somewhere? let me know. Please jump in. I’m writing this with a genuine urge to help others better their understanding of Scrum, but also, to better my own. Am I erring? misjudging? misinterpreting?
Finally I would like to say that I truly respect everyone’s perspectives and the effort they take to write them up and share with us. Opening up topics for respectful debate, and allowing us to respond in a similar way is something I value highly.
Continue to part two:
