My new whitepaper “Scrum. Not Scrum. (Redefining the Future Through the Roots)” is now available. I derived the content from the new book I am writing. That new book will hold my vision on how to deeply and systemically redesign organizations towards a more humane system based on a new development paradigm in which ‘productivity’ is about value and is aligned with ‘humanity’. Revisiting the roots of what is called “Scrum” showed me the path to shaping the future of development as part of a better world to live and work in.
In December (2025) I started working on a new book. Again. And at the same time…finally. Over the years I have gone through several attempts to write a new book, but they all ended up in the bin. This time was different. Maybe it was some inner drive that made it feel different?
In 2019 I shared my observations about what I called The Illusion of Agility in a short movie and in a whitepaper. They hold my observations on what I had seen happening with most—if not all—so-called ‘Agile Transformations’ or similar attempts of organizations to become Agile by adopting Scrum or otherwise. Because pointing out the problem (“inspection”) without offering a way out (“adaptation”) is hardly helpful, at the same time I also shared my advice to “Re-imagine your Scrum” in a short movie. However, I never got to writing the full whitepaper until the fall of 2025. Finally publishing this whitepaper really was the spark I needed to get going on a new book.
The plan was to elaborate on the ideas of “Re-imagining (your) Scrum”, expand and enrich it with ideas of “Moving (your) Scrum Downfield” and add a chapter on why and how to “Humanize the Workplace”. These are the topics of most of my speaking engagements since 2020.
As you are reading this, a complete calendar month has already (almost) gone by in 2026, this not so ‘new’ year anymore. We are 29 January 2026 as I am writing this. I hope your year has started off brilliantly and I wish you all the best. That wish, by the way, is not just for 2026 but for many, many years to come.
Our daughter made the paintings for the above greeting cards at our request. We feel it makes it so much more personal. I hope you like them too. My creativity is so much less, which shows in the cross-stitching work that I have picked up on again (after many years):
As much as every end has a start, every end also is a start–as we know from transitioning into a new year. Would you agree that transitioning into a new year does not really belong in the “big, disruptive” category? My online presentation “Re-imagine your Scrum” for the Scrum Caretakers of the Universe (SMOTU) on 15 January 2026 will have been my last public session. This Scrum Caretaker Courier (nr. 16) will also be my last. I have other ambitions and aspirations on how to connect with people. Allow me to still share how I look at 2025 and at 2026.
Warm regards Gunther independent Scrum Caretaker and Workplace Humanitarian
In 2003 my life of Scrum didn’t actually start with Scrum but with eXtreme Programming that we subsequently wrapped in Scrum. As my professional life in 2025 still revolves around Scrum, can I safely say that I have a ‘career’ of more than two decades of Scrum?
There are a few important milestones that I passed in all those years, although I didn’t plan for them:
Virtually moving to the Netherlands in 2011 and working with large organizations,
Creating my book “Scrum – A Pocket Guide” in 2013,
Partnering with Ken Schwaber and Scrum.org in 2013,
Continuing my professional life as an “independent Scrum Caretaker” in 2016,
Collecting and curating the views of experts around the world in the book “97 Things Every Scrum Practitioner Should Know” in 2020.
Today, in 2025, it feels like I am passing an important milestone again. Over the past two decades of Scrum I seem to have been gathering many, many pieces without being able to see the puzzle, the overall picture. Over the past 4-5 years however, those pieces did start to fit and form one holistic vision.
In 2019 I described my observations regarding “The illusion of agility” in a paper. But, the plan to write a follow-up paper called “Re-imagine your Scrum” never worked out. That is strange because I had created small recordings on both topics in 2019. After all, they are related in the sense that inspection and adaptation are. Today, I am happy to share that I have-finally-written that follow-up paper.
Still, I feel that I couldn’t have expressed my follow-up views and advice in writing sooner than now. Although it is not the complete story of how I look at the future state of Scrum (that will be the topic of my next book), I strongly believe it is already more than enough to get many people, teams, and leaders to start thinking beyond their (current instances of) Scrum.
I hope you will enjoy watching and reading my views and ideas on how to “Re-imagine your Scrum (Firm up your agility)” through the recording & (NEW) WHITEPAPER.
If you want the full history, do read what follows…
On 3 January 2025 the Project Management Institute (PMI) and the Agile Alliance® published an announcement that they signed an agreement on 31 December 2024 through which Agile Alliance® joined PMI, to be known as “PMI Agile Alliance” from that day on. I have no idea where the ® went but it certainly caused a lot of fuzz and noise on so-called social media. As I don’t really care and I don’t expect it to cause that much fuzz or noise on the workfloor, I wasn’t planning on joining any of the debates.
But, Frank Ray asked me on LinkedIn if I had any ‘take’ on this. Despite my initial thought “Not really”, his question was seemingly still enough to trigger me and to get me thinking anyhow (which is something to think about in itself). So, I decided I might as well jot down my thoughts quickly:
I am not involved in or associated with either organization, or their offerings. I never was. What strikes me most are the large, corporate structures that they both have in place. Too large, too corporate for me to feel comfortable with anyhow. So large, so corporate that I am not too sure about the extent to which they actually represent their practitioners and members. I obviously do know a lot of these practitioners and members.
I did find it interesting that Mike Cohn, one of the original co-founders of the Agile Alliance, shared on LinkedIn how the reason for this merger/absorption is the decline in revenues from events since the Corona crisis. Isn’t it fascinating how in general it is said that organizations need to become more ‘Agile’ in order to adapt to changing markets and business conditions? And that of all organizations, the home of Agile has been unable to do so unless giving up on its independence?
At the time of the creation of the Agile Manifesto (2001) and the subsequent establishment of the Agile Alliance (I know Ken Schwaber was also a co-founder but I have never been able to have a clear confirmation on who else was), the world of software development was “dominated by plan-driven, industrial views“[1], “in times when failing heavy-weight, waterfall approaches were replaced by heavy-weight, waterfall-like RUP implementations“[1]. At that time, the PMI certainly was part of the problem, and not of the way out.
In complex and uncertain environments, more is unknown than is known. There is much we don’t know. What we know is subject to change. Only what we have achieved is known (unless we prefer to cover up). Progress is in what we have done, more than in what we plan to do. What we plan to do are assumptions that need validation by emerging actions and decisions. We make and incrementally change decisions based on what is known.
In Scrum it is considered a good idea for teams to know about the progress they have been making. It is one parameter (of several) to take into account when considering the inherently uncertain future.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.
Teams express this Scrum Guide guidance of ‘past performance’ often as ‘Velocity’. Although not a mandatory concept, it is a good tactic to apply in Scrum and for many teams even useful to increase their proficiency in self-management.
Painful problems arise however if Scrum gets managed through the distorting lens of the old, industrial paradigm. Purpose gets lost and ideas get corrupted. No more than an illusion of agility is created. One such case is when Velocity becomes an indicator of volume (of tasks and features produced) and is measured for external justification (i.e. beyond the team boundaries).
Although Scrum can be employed to address any complex challenge, Scrum is foremost applied as a framework for complex product delivery. For many organizations the availability and usage of their products and services is life-critical. They adopt Scrum because they need to act with more agility against that life-critical purpose. Scrum is designed to deliver agility to these organizations under the form of releasable versions of products, called Increments. The purpose is to enable organizations in having an effective impact on the market place no later than by the end of each Sprint. This is a crucial trait of agility for organizations that are highly product or service-dependent.
Against that purpose it is not helpful to not have a releasable product version by the end of a Sprint. We allow even what we have done to remain full of unknowns. We undermine the only base we have for making decisions. We undermine the solidity of our already fragile decision process even more. In terms of real progress, Velocity is actually… zero.
In the face of the purpose of increased agility through Scrum, it doesn’t add much value to discuss Velocity at Sprint Review when no releasable Increment has been created throughout the Sprint. There are probably more serious problems to address first. There are more important challenges than measuring how many points were burned. Let alone the completely futile attempts to standardize, normalize, industrialize, or equalize Velocity across an organization.
In the absence of teams’ capability to effectively produce releasable Increments, such discussions do no more than distract from the more serious problems. Velocity becomes an obfuscating indicator. The definition of Done provides the real transparency for inspection and adaptation. The definition of Done shows what is lacking to increase product quality up to the point of Increments being releasable. In the face of the urgency of agility, the question of what is defined as Done is much more important than registering the amount of unreleasable work produced.
You can obviously measure the Velocity at which undone work is created, and be more predictable in creating even more undone work. It will not help you make progress towards increased agility and having an impact.
Rather, at the Sprint Review ask yourself “What is our impact on the market? What is our ability to go to market?” It will steer the conversation in very different directions than merely reporting how much tasks were completed. Take the findings to your Sprint Retrospective to figure out what is needed to improve on the possibility to go to market next Sprint. Have the ambition of going through an engaged retrospective, rather than one of unfocused fun. Aspire to start creating valuable Increments with a demonstrable impact, no later than by the end of your next Sprint. Nobody external to the team will care about your Velocity, as an external indicator of progress, anymore.
In the face of the purpose of increased agility through Scrum, Velocity, actually, only makes sense if a measure of a team’s capability to create releasable Increments of product, no later than by the end of a Sprint.
Many of today’s enterprises are hardly fit to play a leading role in today’s world. They are designed on the past-world premises of stability and high predictability, of repetitive work with easily scalable results. They experience profound difficulties having to navigate the predominantly uncertain and unpredictable seas of today’s world. An increase in agility is needed. They adopt Scrum. Rather than updating their past-world structures while introducing Scrum, they twist Scrum to fit their currentorganization. No more than an illusion of agility is created as a result.
Imagine they would re-imagine their Scrum and re-emerge their organization to firm up their agility…
Organizations, certainly if they have been around for a while, grew into very complicated and extremely interdependent internal structures. These structures are often the root of the problems organizations seek to resolve by adopting Scrum. Work is essentially seen and organized as assembly line work. Many bodies, meetings, hand-overs, resources, deliverables, processes and departments are required to produce and deliver even the smallest chunks of work.
Organizations naturally revert to familiar recipes when facing the need to become more Agile, including mass-production and cascaded approaches, separate transformation projects, copy-pasting what other organizations do or blindly following blueprint prescriptive models.
Individuals are grouped into ‘teams’. The teams are ‘coached’ into complying with standard sets of practices and processes, unified Sprint lengths and electronic process tools. This is uniformly done across the whole organization, regardless business domain, expertise or technology at play.
The existing organizational constructs are not touched, or touching them is cleverly obstructed, if not sabotaged. Teams (often micro-sized) are typically established within existing departments or other forms of functional separations. Higher-up optimizations, like synergies across teams and departments, are ignored in the same way they were before. The systemic disconnectedness that used to inhibit collaborative problem solving between individuals now inhibits collaborative problem solving between micro teams.
More Agile teams does not make a more Agile organization.
Practitioners worldwide turned Scrum into the most applied definition of Agile. Despite Scrum being the new reality, most organizations continue struggling with Scrum. They struggle as they think teams can be constructed. They struggle as they try to map Scrum’s accountabilities on existing functions. They struggle to understand that inspection without adaptation is pointless in Scrum. They struggle to understand how Scrum can wrap a variety of practices, allowing each expression of Scrum to be tuned to a specific context without fundamentally altering the framework. They struggle to re-invent their organization around Scrum to inject agility in their internal structures, although this will ultimately be reflected in their business outcomes. Organizations lack the imagination to picture how Scrum can work for them, mentally blocked to think beyond their current set-up.
Can you imagine Scrum being employed as designed and intended, regardless your current organization? Do you have the will to deeply reflect? Go back to the ‘why’ of your Scrum? Face your clear and apparent urgency? And take action? Recover, reboot, re-imagine?
In order to firm up their agility, courageous seekers re-imagine their Scrum to start re-emerging their organization. They leave behind past attempts, choices and approaches (all that didn’t work). Over-ambition, magnitude anxiety and deflation angst are mitigated by downsizing to small again and subsequently growing iterative-incrementally. They go through incredibly hard work when they:
1/ Re-consider what the ‘product’ is for the implementation of Scrum (or select another clearly bounded and meaningful initiative). Slicing the initiative if it is too BIG.
2/ Re-imagine Scrum for the selected product/initiative/slice.
Use Product Backlog as the single plan, holding all development work, whether technical, functional or non-functional. Establish what it means for product Increments to be releasable.
Reset the accountabilities to Product Owner, Scrum Master(s) and Development Team(s), full-time dedicated to the initiative and optimizing for the whole rather than for titles, positions and utilization. The eco-system, this newly established Scrum zone, is facilitated with tools, infrastructure and space.
3/ Create coherent, small and tasteful sashimi releases, no later than by the end of each Sprint, through a controlled and automated deployment pipeline.
Repeat.
Courageous seekers take a few Sprints before expanding to a next product/initiative while still improving the existing initiative(s) and relentlessly removing all impediments to the envisioned state of product delivery. Is an environment in place where people are willing to demonstrate the undiluted accountabilities of Scrum? Are teams self-organizing toward delivering releasable Increments providing start-to-finish value, no later than by the end of a Sprint? Are the teams fully equiped with all skills needed, a dedicated team space, all tools, infrastructure and authorizations?
It takes quite some persistence and belief to keep fighting the past-world tendency to control individuals. Remind yourself (or welcome others reminding you) that value is in the outcome of the work, not in the volume produced. At the Sprint Reviews, consider the value a team has potentially created in a Sprint, and align with them on what seems most valuable to work on next. Move away from judging individuals for their hours spent on individual tasks. Team Engagement is the key.
People who are engaged actually care a lot more about customer outcomes and profitability.
Continue re-thinking your internal constructions as initiatives grow, new initiatives spin up and start delivering value. Solve further organizational issues and inadequate policies as you run into them. Start re-emerging the organization upon conscious acts of re-imagining Scrum; funding, HR policies, rewards and incentives, governance, quality assurance, sales and marketing, legal and regulatory compliance. Unleash a way of working that will sometimes lead you to quite unpredictable destinies.
It is hard work. It is a path of learning, experimenting, falling and getting back up. It is transforming how you work, not adding work and complexity to what you already do. It is gradually re-merging your organization towards a networked system of self-sustaining product hubs. A product hub grows or shrinks as needed (following product ambitions and market needs). A product hub is added or disappears as needed (when spinning up or exiting a product). Embed the empirical approach of inspection and adaptation in your managerial practice and in your organizational set-up.
Agility is a unique and continuously evolving state that is typical to a specific organization. It is a state that corresponds to the combination of an organization’s people, set-up and history. A traditional (industrial) approach to becoming more Agile commonly creates no more than an illusion of agility.
Agility is a specific state as it reflects the unique lessons and learnings that an organization and its inhabitants went and go through. It reflects the way in which specific annoyances and hindrances were and are overcome, the many inspections andadaptations that occur along the journey. It is a state that prepares organizations for the unknown future challenges that will demand distinct responses.
Agility is a unique signature with imprints of all people involved and their relationships and interactions, of used and abandoned tools, processes, and practices, of the constructs within and across the many eco-systems that make out an organization, potentially even stretching across the organization’s boundaries.
No model can predict, anticipate or outline the unique signature that an organization’s state of agility is.
However, many of our organizations have their roots, and their beliefs, in the past industrial age. As they feel the need and the pressure to increase their agility, they naturally revert to familiar, yet old-school, industrial recipes. They undertake cautiously planned attempts to gently shift to the Agile paradigm (although they need to leap) wrapped in separate change projects (although their organizations need re-integration). They look around and imitate what other organizations do. They copy-paste what others, regardless whether they operate in the same economical domain or not, claim brought them success. They enforce unified ways of working and practices in a cascaded and mass-production way. They rely on text-book models that prescribe generic pre-empted blueprints of organizational structures. The learnings and the hard work needed to acquire sustainable agility, tuned to the organization’s specific context, are conveniently ignored.
Ironically, these are the exact approaches that block these organizations in their growth. These are the exact ways of working that they need to abandon in order to enter and survive the new worlds, the worlds that require a higher agility.
The mismatch is fundamental. They need and want to hose downtheir industrial ways, yet they end up re-enforcing them. No more than an illusion of agility is created as a result. This is painfully revealed when the deflation by reality hits hard, often after several years. When the actual increase in agility turns out negligible, a painful finding certainly in the face of the urgency. The actual results turn out disappointing. The lost time is a catastrophe.
Increasing agility is a path. Progressing on that path requires vision, belief, persistence and… hard work. Agility, as a state of high adaptiveness, can only be achieved by regularly… adapting. Adaptations only make sense upon inspections of actual work and observable results. Think feedback loops (all around). The new reality, for which higher agility is needed, mandates that what works today might not work tomorrow. What works for one company (i.e. a complex system of interconnected people, processes and tools) might not work for another company. What works for one combination of teams, technology and business might not work for another combination.
Signposts that might help you detect whether an illusion of agility is being created:
It is not a transformation if it doesn’t change how you work;
It is not an Agile transformation if it doesn’t simplify how you work;
It is not an Agile transformation of Scrum if it doesn’t increase the actual collaboration of people (customers, teams, stakeholders).
Note. None of the above makes sense if no proper attention is given to technical excellence.
The new reality tells us we need to act in the moment more than we did before. Ever. Embracing uncertainty and unpredictability has a great potential too. Getting the most out of the possible thrives upon acceptance of the unwritten state of the future and what that future might bring. It reminds us that we are not alone in this, that each individual, no matter their function, level, position or silo, can contribute. Living the art of the possible against unpredicted outcomes has the potential benefit of engaging people as it shapes their future. Acceleration comes from vision, determination and dedication; from the courage to move away from following a plan or copying a model to continually shaping and re-shaping your future.
Regardless an organization’s past attempts and choices, the path of hard work is always a workable way out, a way to break the illusion of agility.
The Agile Manifesto, and the movement that stemmed from it, has hugely improved the world. I believe in continuing the Agile dream and create an even better world (rather than focus on the inevitable downsides of the success).
In February 2001, seventeen software development leaders gathered at the Snowbird ski resort in Utah (United States) to discuss their views on software development. Those were times of failing waterfall and heavy-weight RUP projects (‘Rational Unified Process’). These 17 people were following different paths and methods; Scrum, eXtreme Programming, Adaptive Software Development, Crystal, Feature Driven Development, etc.
Much to their own surprise they found an agreement over a set of common principles, beliefs and viewpoints, published as the „Manifesto for Agile Software Development“. The adjective ‘Agile’ became the label to describe the views described in the Manifesto.
Even more to their surprise ‘Agile’ turned into a success, with many people signing the Manifesto and -albeit gradually- Agile taking over the world. A new paradigm was born, in the realm of the software industry. A movement stemmed from it, with Scrum as distinct definition of Agile heading the pack. Over time, Agile seeped into other domains of work and activities, beyond software and product development.
Today, the balance of society incessantly keeps shifting from industrial (often physical) labor to digital (often virtual) work. In many domains of society, the unpredictability of work increases, drastically and continually. The industrial paradigm is rendered useless, definitely. The need for the Agile paradigm is bigger than ever. Scrum is the new reality, now and in the foreseeable future. Actually, Agile and Scrum are inseparable ingredients.
The success of Agile was unplanned, unpredictable, a huge gamechanger and… undesirable (to some).
It deeply saddens me to read, hear and feel the scorning, the resentment, the cynicism. It deeply saddens me that people find little other purpose in life than to make a day job out of negativity, out of pointing at flaws (real or imagined), perceived shortcomings and the incompleteness of Agile. It deeply saddens me to hear people that still are not over the feeling they should have been invited to the Utah event.
Agile as described in the Manifesto, indeed, is imperfect and purposefully leaves room for ambiguities. And, yes, Agile partially turned into a business in itself with forms of bastardization into marketing and moneymaking schemes. And, maybe, there are people and organizations that don’t „get it“ and demonstrate a lack of ‘true’ understanding. That might mean we have not done a good job of helping them discover the value of Agile (in which case a new name will not solve the problem). It might just be in the eye of an ignorant beholder or self-acclaimed experts alike. Who are we to judge?
Regardless, Agile was and is a huge improvement to the world. I am grateful that those 17 people provided us with an amazing foundation upon which to build, discover even better ways to do our work, and keep creating a better world to live and work in.
And, yes, I am wary of the new cult too, the Big gestures and the beatification. I also see the hunts for adoration, name and fame. I observe ideas being stolen, ripped and degraded. All speaking against the Agile and Scrum Values, I know. In avoiding falling into the trap of scorning myself, I have no other choice than to remain with my belief that Agile is not about comic figure-like stereotypes and dress-up routines. Agile is not about massive tap dancing crowds or cheerful ticker tape parades. Agile is not in your title, not in how you look. Beyond being in what you say, Agile is primarily in what you do, how you act.
Still, Agile is a choice, not a must. Nobody needs to join me on my path of continuing the dream. I like to think I am open for any other new, deviant, disruptive idea that introduces more improvements and further humanizes the workplace. In the meantime, I’ll stick to trying whatever I can do to demonstrate the value of Agile, with the Scrum framework as favouritetoolbox in my backpack. I can only suggest others to allow their ideas to speak for their positive selves. I am sure blaming Agile (for its broad adoption) is hardly helpful in that regard.
Warm regards Gunther
your independent Scrum Caretaker
(Thank you, Higher View, for your professional expertise in video creations)
Every individual is naturally T-shaped. I have never worked with a single person who mastered no more than a single skill only. Every individual I worked with had the (at least intrinsic) capability to perform more than one type of work only. Every individual I worked with had the (at least intrinsic) technical and social capability to join forces with people that master other areas of expertise better and still contribute to that ‘other’ work, learn from it or even acquire it as a new skill.
Ultimately, when people self-organize, i.e. form organized groups without external instructions being imposed on them, around shared challenges and objectives, they unite to form collectively T-shaped eco-systems, entities, teams. The entity as a whole is cross-functional and houses all the disciplines to tackle the complex challenge end-to-end. Within the entity, ultimately cross-fertilization of skills happens.
Every individual is naturally T-shaped. I have also never worked with a single person who mastered every possible skill needed to perform any type of work that might arise when dealing with complex challenges like software and other forms of new product development. The demand for people to be able to do that, is absurd. Yet, it is how the T-shape metaphor is abused. The idea that a cross-functional entity can only be composed of fully cross-functional individuals, in which every single person can pick up every possible task, is absurd.
I find over and over that people are impeded or blocked from employing their intrinsic T-potential rather than being unwilling to do so. Common causes are function descriptions, hierarchy, systems, structures, procedures, instructions, incentives, rewards and other HR processes, enterprise career pressure.
The message that external forces need to mould people into T-shapes is an expression of distrust and disbelief in the potential of people. People are not resources or an assembly of ‘skill’ parts. People don’t need to be deconstructed, disassembled, reconstructed or amended for any preferred shape, like parts forged to fit a pre-empted construction. Systemic impediments need to be removed that prevent people from exploring and discovering their needs and interests, from growing their talents and potential.
Rather than judging people for the expertise they (don’t) demonstrate, focus on creating a context, an environment in which people can unleash their motivation and their multi-skilled potential. Focus on fostering an environment where people can bring in their multi-skills and expertise to leverage a cross-functional and multi-skilled entity (like contributing to T-shaping a team). In the end, complex problems go beyond any individual’s problem-solving capabilities, T-shaped or not. They need T-shaped teams and eco-systems to be an integral part of. And -ultimately- a context in which cross-fertilization happens; people extending their skill sets through peer collaboration and peer learning.
Check in with people about their feeling of valuation. Help them increase their feeling of valuation and unleash their intrinsic motivation. Help them become better at what they do and how they do it. Or, if needed, help them move to a place where they would feel more valued. Help them increase their feeling of valuation.
Is the work you are doing right now in your domain of interest? Does it excite you?
Do you feel you have the talent and skills to be great at what you do? Can we help you develop your talents and skills?
Is the work happening in a (business) domain that makes you feel at home?
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The purpose of the Scrum framework is to establish essential boundaries of such an environment of self-organization and intrinsic motivation thriving on the professional drive of people to create excellent products. Scrum frames people’s creativity and intelligence with empiricism. Scrum Master, as a modern manager, is accountable for fostering such an environment of Scrum. A safe environment where people can demonstrate traditionally unsafe behavior, like going beyond the limitations of their function descriptions.
I observe a revived interest in Scrum. I observe how people, teams and organizations re-discover Scrum. Scrum has the simplicity they grasp for. They see the value Scrum brings. Simple and valuable, not easy. In a forward-looking observation I described it as the third Scrum wave that is rising.
Scrum is simple indeed, yet has so many aspects to be discovered by so many organizations. Scrum serves a journey of product discovery. Adopting Scrum is a journey of discovery in itself.
Scrum is a simple, yet sufficient framework for complex product delivery, for managing complex challenges. There is a high cohesion in the minimalist set of rules and advised activities of Scrum. There is no such thing as individual Scrum practices. Scrum lays down essential boundaries within which people self-organize, within which people devise a way of working tuned to their own context. Scrum can wrap many practices. When applied well, the integral result is still… Scrum.
The themes of the recent past of Scrum were ‘scale’ (volume) and ‘divergence’ (different names and movements). Distractions. People, teams and organizations realize that it did not result in the agility they need in their complex context. I observe a revived interest in the cohesion of Scrum, the framework as a whole. People, teams and organizations learn that over-focusing on isolated elements of Scrum has not helped them tackle their complex challenges and humanize their workplace.
While rediscovering Scrum, as a whole, people, teams and organizations discover that Scrum still leaves plenty of room for their context-specific needs. Scrum is designed to holistically support people, teams and organizations to create, maintain and sustain complex products. Scrum does not replace people’s intelligence and creativity, rather provides a frame for people to operate within and create valuable results. Scrum is intentionally low prescriptive. Scrum offers a limited set of mandatory prescriptions, which in turn allow many variations to apply the rules.
Scrum most often does not fit the existing, rigid structures of many organizations, the hidden impediment to achieve true agility. Stick with Scrum. Consider the core framework to be immutable. Period. Start small. Through practice all people involved will ingrain new behavior, enact the Scrum Values and grow a new working culture, a more humanized workplace.
Twisting Scrum, hacking into the basics of the framework breaks its cohesion, covering up dysfunctions rather than revealing them, probably disregarding the principles and foundations upon which Scrum is founded, rather than promoting great behavior. Such versions and implementations are possible. Isolated use of Scrum’s terminology or individual elements is possible. They might look like fun. They might work. They lack cohesion. They are not Scrum.
The 3rd Scrum wave is rising. Will you sink? Will you swim? Be a laggard of the second wave? Or will you surf?
On a personal note I want to add that I am delighted to see a shift from ‘Agile Coach’ to… Scrum Master. A good sign. A sign also that the need is real to have someone working with the teams and with the organization in fostering a healthy environment, an environment where innovation and creativity can emerge, where people can demonstrate traditionally unsafe behavior.
