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”.
In 2010, the principal co-creators of Scrum, Jeff Sutherland and Ken Schwaber, agreed on the first version of the Scrum Guide, thereby creating the official BOK (body of knowledge) for Scrum. A few small, functional updates have been released since then. There have been no drastic changes to the core definition of Scrum. The updates that were released reduced complexity of the Scrum Guide or introduced clearer terminology. Language and words do matter.
The Desire for Precision
I imagine the difficulty of every rephrasing involved in updating the Scrum Guide. The Scrum Guide holds the single definition of Scrum for countless practitioners across the world, all employing Scrum in unique environments and varying situations. I imagine the discipline of updating the Scrum Guide knowing that many people will not read it. Most of all, I imagine the difficulty of updating the Scrum Guide knowing that many will micro-dissect the texts to identify the tiniest of changes. Many over-think individual words upon the misassumption of traps, tricks and hidden messages. Many still look for methodological exactness and universal precision.
Regardless, the fact that Scrum has a clear and documented definition is priceless. The Scrum Guide provides clarity and purpose, albeit not the perfect precision that many seem to look for.
Scrum is a tool. Useless unless employed.
The Scrum Guide intentionally has no universally applicable, detailed instructions or tactics that in the end only work in specific circumstances. The Scrum Guide describes how the tool works, the rules and roles that apply, the behaviors that make the tool work; not the tactics to apply the rules. Scrum, by design, offers room and breathing space, inviting people to conceive an approach specific to their context upon the empirical foundation of Scrum. Scrum is a framework, not a traditional (IT) methodology. The Scrum Guide describes the framework, the minimal boundaries within which people deal with complex challenges and create complex solutions in complex circumstances.
All exact decisions within those boundaries depend on people, tools, technology, business domain, organizational environment, market situation, and many other aspects.
What is the availability of people? Their skills, experience? How well do teams gel? Do they work remotely, or co-located? How long have they been working together? How much multi-tasking does a team or team members have to do? How well are teams facilitated by the environment? What technology is being used? Which version? What dependencies are at play? What development practices does a team have in place? What tools and infrastructure are at the teams’ disposal? How long are the Sprints? How is the connection with product management? What is the competition doing?
Scrum does not have the false pretence nor ambition to offer universal truths, universal answers that apply in every single situation. Scrum essentially invites people to regularly match the actual state of their work against reality, in order to optimize flow and progress, while re-aligning and adapting to new circumstances, highly disruptive events and new insights. Scrum is a simple framework for complex product delivery.
Deliberately imprecise
The Scrum framework offers the simplicity needed to address complex challenges, without being simplistic about the unique and specific problems that teams and organizations face. Many people struggle with this deliberate imprecision when they try to improve their understanding of Scrum. They look for detailed instructions. They ask universal questions and demand exact and precise answers. How long should Sprint Planning be? And the other events? How much time does the Product Owner role take? Is the Scrum Master role a full-time job? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? How many business analysts are needed in the team? How should we calculate utilization? How can we measure productivity? Should the Product Owner and the Scrum Master understand the technology? What if… ?
No document, no matter its length, can provide exact answers to all of these questions for all Scrum practitioners of all workplaces around the world. It requires skilled professionals (Scrum Masters, trainers, and otherwise) to build on the language and words provided by the Scrum Guide and explain intent and purpose. It requires courageous professionals to help teams, organizations, and students grow an understanding of how Scrum supports them in empirically dealing with the diverse, complex challenges they face in their real-life complexity. Such professionals understand that what works today might not work tomorrow. Exact instructions lead people astray, undermine their ability to think autonomously in terms of Scrum. It is highly disrespectful. Answers to the ‘what if’ questions will emerge from the use of Scrum, from the inspections performed in Scrum. Be prepared to learn and adapt.
My personal stance, as a trainer, a friend, a trusted advisor, a whatever in Scrum, is to facilitate people in understanding the purpose of the rules and the roles of Scrum. This is at the heart of my book, Scrum – A Pocket Guide, and all my actions of promoting and explaining Scrum. The only viable way forward for people is to devise their own solutions employing Scrum. No external instance, expert or otherwise, can or should do that for them. It may be tempting. It is certainly highly convenient. It might make a person appear knowledgeable. But it promises certainty where there isn’t. That is unprofessional. It ignores context and complexity. It ignores people’s intelligence and creativity.
Every case of Scrum is unique. There is no copy-paste. There are no universal truths in the complex novelty space. The definition of Scrum requires no methodological precision. There is no future in ignoring complexity.
Organizations suffer as they fail to act with agility through product releases, on the market, for users and consumers, facing competitors. Scrum is mandated and it is overlooked that the agility demonstrated outwardly also depends on the setup of internal structures.
Organisational rigidity is the result when people are separated in functional silos, when collaboration is instructed through hand-overs and governance, when go-see management is not practiced, when the daily work has no room for discontinuous innovation. Basically, such rigidity is the anti-thesis of Agile and impedes outward agility.
Scrum is a simple framework for complex product delivery. Scrum thrives on the self-organizing capabilities of collaboractive people creating finished versions of product in short cycles, called Sprints. Scrum is in itself agnostic of internal structures, positions, titles, hierarchies. Scrum has no mandatory rules for organisational constructs. Scrum is simple, not easy. The simple rules and roles of Scrum are most often twisted and broken to fit an existing organization. Yet, it is nearly impossible to benefit really from adopting Scrum without updating the internal operating systems.
The sensible and courageous way forward is to re-vers-ify, to re-imagine your Scrum to re-emerge your organization. It is a path, not the destination. The destination, an updated organization, is unknown, remains to be discovered.
Use Product Backlog as the single plan for one (1) meaningful initiative (project/product/service). Slice the initiative if it is too big.
Reset the accountabilities for the selected initiative to Product Owner, Scrum Master and Development Team(s).
Facilitate the eco-system with tools, infrastructure and a (Scrum) team zone in order for them to create sashimi releases. A controlled and automated deployment pipeline is certainly a much needed step forward.
Repeat, grow, learn, expand.
“Re-vers-ify” is a narrative to help people re-invent their organizations; an invitation for people to re-imagine their Scrum to re-vers-ify their organization. Over the course of 2017 I have introduced re-vers-ify in several ways. I have now highlighted the essence in a short movie. It takes only slightly over 3 minutes of your time. Enjoy!
Much has been said, is being said, and will be said about Scrum, the most adopted Agile process.
Scrum, in the end, is a simple framework for complex product delivery. Scrum has a limited set of mandatory rules and roles. They all serve to create an environment within which people inspect their work regularly, so they can adapt. Scrum is an open framework in the sense that people can employ a variety of specific practices. When these practices are employed well, the integral result is still… Scrum.
Despite/due to its popularity and simplicity, much misunderstandings exist. I highlighted the essence of the Scrum framework in a short movie. It takes less than 3 minutes of your time. Enjoy!
A Scrum Master is rarely seen, let alone enacted, as a management role. The role however does show us how a modern manager would act.
Scrum Master, as a modern manager, fosters an environment of safety. An environment of safety is an environment in which people, from a traditional point of view, act in a highly unsafe way; speaking up, challenging, sharing, thinking, pausing, collaborating, deviating, creating, innovating.
In the past I have already published my views on how Scrum Master is a manager. I have now highlighted the essence of the Scrum Master role in a short movie. It takes less than 3 minutes of your time. Enjoy!
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.
