At some point in time the term “Framework” became really fashionable. I don’t remember when it was exactly, but it was when smart businessmen assumed it was better for sales, as commonly used terms like methodology or process got burned. At least, that can be seen as an achievement too. Most likely they guessed it explained the wide adoption of Scrum, and aspired the same ’success’.
Today, the word is omnipresent and can surely be added to the list of most misunderstood words in the world of “Agile”. That does not change the fact that we did not start using the word lightly in the past. It was not about marketing or selling. It was about sincerely describing the lightweight nature of Scrum, as a simple set of rules, principles and values that define a framework for inspection and adaptation, a way for people to address complex challenges.
Regardless of fashion of the day and obfuscation, this is not a term to leave to the sharks. Language matters. Scrum is a framework, not a methodology, as I described in 2013 and in my book “Scrum – A Pocket Guide”.
Scrum was for the first time publicly presented and described in the paper “Scrum Development Process” in 1995. Scrum is turning 21 years old.
It starts and ends with people.
Scrum can only last and prosper -across the globe, across industries- because thousands and thousands of people, organized in teams, departments, organizations, employ Scrum to deal with complexity, to tackle difficult challenges, to create valuable product. Day in, day out. (Depending on the source, 70-90% of all Agile teams worldwide say they use Scrum.)
Regardless of region, organization, culture, or background, every individual has the intrinsic capability to self-organize and thrive by working in the context that Scrum creates. Through people those benefits can be unlocked to wider ecosystems.
Are we Done with Scrum?
In my book “Scrum – A Pocket Guide” I present 2 major challenges, that will help define the future state of Scrum:
1/ The Power of the Possible Product
From having implemented Scrum for the ‘how’ of product development, adding more focus now to ‘what’ needs to be built is crucial. That shift will help organizations discover the power of the possible product, reduce the amount of product built, instead of merely optimizing the way that the product is being developed. (Scrum – A Pocket Guide, November 2013)
2/ Upstream Adoption
More than about process and techniques, moving from the old, industrial paradigm to the new Agile paradigm is about culture and behavior. The common bottom-up enthusiasm that arises from doing Scrum is unlikely to be sufficient for such transformation. For a lasting effect the common bottom-up enthusiasm needs to be supported and facilitated by upstream adoption. (Scrum – A Pocket Guide, November 2013)
Besides these ones there are obviously many more challenges related to implementing and adopting Scrum, related to getting more benefits, a higher agility out of Scrum, a higher ability to adapt:
Let alone the secondary-order challenges that many organizations get themselves into with attempts to re-define, wrap, package, and rename Scrum, although the core engine they build upon is still… Scrum.
Scrum, essentially
What if, moving forward, we focus on the essence, the core purpose of Scrum?
If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. (“Done is a crucial part of Scrum, actually“, May 2015)
Scrum is a tool that supports people, teams, departments and organizations to gain agility; ‘agility’ being the ability to adapt, to change course, to explore unthreaded paths. Agility is not achieved at the insides of an organization. It is validated through external impact.
Hence the purpose of Scrum to create a Done Increment of product, no later than by the end of a Sprint, where a Sprint takes 4 weeks, no longer and often shorter.
An Increment in Scrum is not really Done if it can’t potentially increase such impact. An Increment is not Done if it’s not releasable. An Increment in Scrum can be Done before a Sprint expires, but no later.
How Done are you?
Over the past year I started actively inquiring on how many people using Scrum create Done Increments, with “Done” reflecting a state of actually ‘releasable’. From all people and teams saying to be using Scrum, at most 10% indicate their Increments are in a releasable state. And even then the biggest struggle is to maintain this high state of quality Sprint after Sprint after Sprint. I recently heard Jeff Sutherland say his experience says it is certainly no more than 20%.
The crucial questions for every Scrum practitioner are:
Do you have a definition of Done?
Does your definition of Done reflect releasable?
Do you create actually releasable Increments of product?
Every Sprint?
Then ask yourself, “What is stopping me?” and take action. Involve your Scrum Master in removing the Impediments that are preventing you from creating releasable Increments of product. Expect your management to be involved as well.
The future present
It is obvious that we are not Done yet with Scrum. We’re not sufficiently employing Scrum to the level that every Sprint, or sooner, we have a Done, releasable Increment of product. This however is the foundation of agility, of empiricism, and the ultimate sense of fulfilment.
The future present of Scrum is the creation of Done Increments. It is an ambition that will get us a long way, if not another 2 decades.
Scrum begins with Done. Let the next 20 years be about enacting Scrum.
Scrum, actually, has been around for a while. Scrum emerged in the early 1990’s through the work of Jeff Sutherland and Ken Schwaber. They packaged their practices into a cohesive set of rules and roles and named the entirety „Scrum“. The term, actually, was inherited from the ground-breaking 1986 paper The New New Product Development Game. The reference to the game of rugby reflects the importance of team engagement.
Scrum, actually, has had a stable core since its first public presentation in 1995. The essential definition of Scrum was codified in the Scrum Guide in 2010. This definite body of knowledge describes all parts of Scrum, and the rules that tie them together. Scrum is defined as intended and designed, i.e. a cohesive set of rules and roles implementing empiricism for complex product development. The rules and roles described in the Scrum Guide gain full clarity when read as an expression of the Agile values and principles.
Scrum, actually, is intentionally kept low prescriptive. Scrum sets the frame for people, teams and organizations to create, maintain and sustain complex products. Scrum does not replace people’s intelligence and creativity, merely guides the work. Scrum’s basic rules are immutable. Flexibility comes from the zillion variations to apply the rules, selected and tuned to context and circumstances. Hacking the basic rules of the framework breaks the cohesion, and disregards one or more principles and foundations upon which Scrum is founded.
Hacked versions and implementations of Scrum are possible. Isolated use of Scrum’s terminology or practices is possible. They might work. They might be fun. They are not Scrum.
Scaled implementations of Scrum don’t change the fundamental rules and roles of Scrum, nor the underlying principles. They only require different tactics. Instances that change the core of Scrum are not Scrum.
Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty. Scrum can wrap many development and organizational practices, tools and techniques. Scrum creates the capability of continuous adaptation in a environment of constant change, regardless whether that change is caused by our own will or by external turbulence. Scrum turns complexity from a threat into an asset.
Scrum, actually, propels agility through releasable Increments of software. A releasable Increment is available by the end of a Sprint or sooner, not later. A Sprint takes no more than 30 days, and is often shorter. Frequently an updated, improved version of software can be made available to its users and consumers. Feedback from actual use can be gathered to drive changes, improvements, enhancements. Assumptions are turned into learnings, ultimately into a pivot if required.
Scrum, actually… is a means to an end, a tool designed for a purpose: people, agility, value.
Scrum has no exhaustive and formal prescriptions on how to design and plan the work, actions and behavior of all players involved in product development against time, let alone how such designs and plans would have to be documented, approved, stored, etc. Scrum has no rules for upfront predictions of document types and (intermediate) deliverables to be produced or the time at which they should be produced. Instead of installing and thriving on hand-overs, toll gates and control meetings like IT methodologies typically do, Scrum helps eliminating them as a major source of delays and waste.
‘Methodologies’ are typically composed of stringent and mandatory sequences of processes and procedures that implement predefined algorithms. As such, methodologies tend to rule out the creativity, autonomy and thinking of people with components like phases, tasks, must-do practices, techniques and tools. As long as the methodology is being followed everyone feels safe, because they are formally covered, even in the absence of working results or proven progress. Methodologies depend on high degrees of predictability, otherwise the preset algorithms fail. Complex problems, for which Scrum was designed, are more unpredictable than they are predictable. Today’s world has more complex challenges than simple cases.
Scrum is not a methodology. Scrum is even the opposite of such big collections of interwoven mandatory components and instructions. Scrum implements the scientific method of empiricism, the process of inspecting in order to adapt at regular intervals, not aspiring to try to predict what the adaptations will be. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and thriving on the self-organizing capabilities of people to deal with unpredictability and address complex challenges.
Is Scrum a process?
If Scrum is a process, it is certainly not a repeatable process. That might be a challenge to explain, because the term ‘process’ typically invokes a sense of algorithmically predictable steps, repeatable actions and enforceable top-down control; the sort of expectations that in our world are typical for a… methodology.
Scrum is not a commanding process. If referred to as a ‘process’, then Scrum is a servant process. What works best for all involved players, their working process, emerges from the use of Scrum. The players discover the work required to close the gap between an inspected intermediate result and an envisioned outcome. Scrum is a process that helps surface the real (daily) process, structures and a way of working that are continuously adapted to the actual context and current circumstances. Therefore we call Scrum a… framework.
Scrum is a framework
Scrum describes the roles and rules upon given principles that help and facilitate people in a low-prescriptive way, that help people create a framework for regular inspections and adaptations. The Scrum Guide holds the definitive description of the base rules of the game. The prescriptions are minimal, but every single one of them addresses dysfunctions that were (and are) common in (software) product development.
Over the 2+ decades of Scrum, the rules of Scrum, as captured in the Scrum Guide, have gradually evolved, with small functional updates and releases. The prescriptions of Scrum, what needs to be in place to have the full benefits of Scrum, become more and more focused on emphasizing ‘what’ is expected in developing complex products over instructing ‘how’ to do it.
A good illustration of such an evolution is the elimination of burndown charts from the Scrum framework as mandatory (a ‘how’ of managing progress). This obligation however has been replaced by the explicit expectation that progress on the mandatory Scrum artefacts, the Product Backlog and the Sprint Backlog, is visualized (the ‘what’). The form or format of the visualization is no longer prescribed, thereby turning burndown charts into a non-mandatory, but still good practice; a good way to play the game and suitable in many situations.
Yes, it’s Scrum if Product Backlog and Sprint Backlog exist and if a visualization of their progress is available, accessible and clear. This may be a burn-down chart with open effort. It may also be a burn-up chart in value. It may be a Cumulative Flow Diagram. It may be as simple as a Scrum board.
The Scrum framework leaves options for different tactics to play the game, ways that can at any time be adopted to the context and circumstances. Scrum, as a framework, can wrap many practices. When applied well, the overall system will still be recognisably… Scrum.
The Scrum core values give direction to the actions, the behavior and the additions to the framework. Upon that core, in a ScrumAnd way of thinking many opportunities emerge. Have a look at some illustrations of ScrumAnd.
