Gunther Verheyen

Somewhere along my journey of Scrum, that started in 2003, I started calling myself an independent Scrum Caretaker on a journey of humanizing the workplace with Scrum. Because there is more to Scrum than ‘process’....

Scrum has been around for a while, they say. The Scrum Guide holds the definition of Scrum, they say. The first, official version of the Scrum Guide was released in February 2010. So, how was Scrum defined before 2010 then? How did its definition evolve before and after 2010 and become the framework that we know today? What else happened along the road to the way that Scrum is defined and represented? In the paper "Scrum: A Brief History of a Long-Lived Hype" I have described what changed to the definition and representation of Scrum over time, before and after the creation of the Scrum Guide. It shows how Scrum evolved into the framework that we know today since its first formal introduction in 1995. Because a touch of historical awareness is more than helpful in understanding Scrum and caring for the future of Scrum. I looked for sources that are not just credible in terms of authorship but also offer regular enough check points. In the end, the sources I used for describing the evolutions of the definition of Scrum are: The paper “SCRUM Software Development Process” by Ken Schwaber (1995, 1996) The paper “SCRUM: An extension pattern language for hyperproductive software development” by Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber and Jeff Sutherland (1999) The book “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle (2002) The book “Agile Project Management with Scrum” by Ken Schwaber (2004) The book “The Enterprise and Scrum” by Ken Schwaber (2007) “The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2009, 2010) “The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2011, 2013, 2016, 2017) “The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2020) For every source I have described the same three topics to show what Scrum consisted of at the time (regardless the different terms used), what the ‘definition’ of Scrum was at the time: Roles, responsibilities, accountabilities Controls, deliverables, artifacts Phases, meetings, time-boxes, events For every source I have included a graphical representation of Scrum or of a Sprint that was either taken from the source directly, either from an alternative source of the same period. Finally, I have shared my thoughts and observations on the changes to the definition of Scrum for every source. Obviously, they represent what I deem noticeable. They hold no judgement, directly nor indirectly. To complete the paper I have listed some important landmarks in the history of Scrum and included some personal musings on the topic of “Scrum and the Desire for Universal Truths” (and what the Scrum Guide was not created for). I hope you will enjoy reading the paper. I hope it will help you grow a deeper understanding of Scrum. I hope it will help you shape your Scrum to get the most from it. I hope it will help you create better products with Scrum while humanizing your workplace. Take care Gunther Verheyen independent Scrum Caretaker . . . Originally published at https://guntherverheyen.com on December 17, 2020.

Scrum, in its more general definition, is a simple framework to help us address complex challenges. Product development is the subset of complex problem domains where Scrum took root first...

I call myself a Scrum Caretaker. I aspire inspiring people using Scrum. I prefer sharing positive experiences and cases that demonstrate how amazing working with Scrum can be, what problems can be tackled and how, the level of excellence we can build into our products, how Scrum can engage people.

Sanjay Saini, owner of Agile WOW("Agile Ways of Working"), kindly invited me, as an independent Scrum Caretaker, to open and close the event. I hope many Scrum practitioners register at scrumdayindia.org and join the event. In the end, only eager attendants can turn events into insightful experiences!

Agility is a continuously evolving state that is unique to a specific organization, given the organization’s people, its constructs and its history. A traditional (industrial) approach to becoming more Agile (adaptive) commonly creates no more than an illusion of agility.

Try organizing a party in a “Yes, but…” atmosphere. The result is probably a zillion obstacles identified, but no party.

Do you think people need to be forged into a T-shape? Think again. Focus on the aspects preventing people from employing their intrinsic T-potential. I have never worked with a single person who mastered no more than a single skill. Every individual I worked with had the intrinsic capability to perform in more than one type of work. Every individual I worked with had the intrinsic ability to join forces with people that master other areas of expertise. Every individual is naturally T-shaped. Ultimately, people can unite to form collectively T-shaped eco-systems, entities, often teams. I have 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. The demand for people to be able to do just 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. Every individual is naturally T-shaped. 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. 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, problems in the Complex Novelty space 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-fertilisation happens; people extending their skill sets through peer collaboration and peer learning. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (Principle #5 from the Agile Manifesto) 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 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. {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/oX3KDscq1yM.jpg?itok=a414tAzj","video_url":"https://youtu.be/oX3KDscq1yM","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]}

Our real-time, globalized world thrives increasingly on information and technology. The balance of businesses and society has rapidly shifted from industrial (often physical) labor to digital (often virtual) activities. The world seems to be changing faster and less predictable than ever before. We used to believe a majority of our problems to reside in the ordered stability space, but we find ourselves living and working in the complex novelty space nowadays, the space where more is unknown than is known. The industrial recipes of Excel-based management, unlimited expansion, shared resources, efficiency and utilization don’t apply anymore. Agility became a critical state for organizations. The Agile paradigm is replacing the old, industrial paradigm. Scrum is a clear and the most adopted definition of Agile, and the third Scrum wave is rising. The principles and ideas underlying Scrum are a better fit for navigating the complex novelty space. Scrum introduces new language and terminology to express the novelty of those principles and ideas. It makes the impact of the change more transparent. The new language and words however are often copy-pasted to be embedded in a broader old, industrial setting; against the illusion that work happens within the ordered stability space. The words get disconnected from their novel intent, meaning or feeling. Shifting to a new paradigm includes the conservative tendency to mimic, isolate, copy, paste what is perceived as trendy, popular and profitable. Rigor is required in morphing towards an Agile way of working. The real challenge is not even to just sense whether our words are remainders of the industrial paradigm and don’t apply anymore. We need to remain conscious about the continual evolution of insights within the new paradigm, and how this is or is not expressed in our language. Unknowingly we grind, grow complacent. The Agile space, in which we operate, keeps evolving. We discover better ways to express our intents than blindly repeating what others are saying: Do you recognise how teams need to be ‚high-performant‘, and such high-performing teams must be built? A team however cannot be constructed by an external force. Nor is a group of people necessarily a ‘team’. A team is a cohesive collective of people working towards common goals and objectives, thereby jelling and overcoming resistance, internally and externally. A team is what emerges through intense collaboration. Performance arises from such intense collaboration. Rather than aiming at high performance in itself, often hinting at productivity, facilitate collaboration. Foster an environment, clear the way for people to interact, to share, to disagree. Highly collaborative teams will perform. ‚Maximization‘, even unintendedly, has a smell of infinite expansion, endless growth. As does ‚continuous improvement‘. It leaves an impression of unlimited accumulation; more, more, more. Where is the room for reflection, adjusting, changing direction, adapting, maybe even turning back? Consider to optimise what you do. Make the best of what you have, of what you are able to do. And while doing so, in order to do so, regularly adapt. What works today might not work tomorrow. More changes than remains stable. Continuously adapt and optimise the value of your work. Many inhabitants of the environments in which we operate are discovering that in the complex novelty space more changes than remains stable. Exact, detailed, upfront, long-term predictions no longer work. At most we strive for 'predictability'; forecasts based on the past reality. I prefer reliability even more, the fact that people and teams are reliable and transparent in the hard work they do. It creates awareness that it is all about discovery, discovering what is needed to make the best possible progress towards hopes, goals, ambitions and vision. Technically, Scrum says an Increment should be releasable no later than by the end of a Sprint. For many organisations that already represents an incredible leap forward, let alone the ability to have releasable versions of product even sooner. We can raise the bar even beyond that, set a new dot on the horizon. We can share the expectation with teams and organisations that Increments are expected to be not just be 'releasable', but be valuable. Consider what you are defining as Done. An Increment, by default, is potentially valuable, as value is an assumption that can only be validated by releasing and gathering feedback. Mind that language, when not blindly mimicked, expresses your mind-set and beliefs. Reflect on what became traditional Agile terminology in the meantime. Move away from false dichotomies that don’t reflect the reality of iterative-incremental discovery; eternal growth, succes vs. failure. Mind your words. What you say can and will be used against you.

If agility is why your organization adopts Scrum, look for more sophistication in employing Scrum. Through Scrum, teams and organizations create the opportunity of having a releasable version of product no later than by the end of each Sprint, where a Sprint takes no more than 4 weeks, and often less. This provides an organization with a foundation for agility. A professional organization only releases "Done" Increments. In order for everyone to understand what “Done” means, a definition of Done needs to be in place, the shared understanding of what it means for work to be complete. Without a definition of Done, Scrum cannot be applied effectively. At several points in time a definition of Done provides crucial clarity: When forecasting work deemed feasible for a Sprint. When assessing whether work on Product Backlog items and the product Increment is complete. Over progress of development throughout a Sprint. When considering the opportunistic value of the product functionality offered in the Increment. Scrum professionals adhere to the definition of Done. Always. No "undone" work is part of an Increment. No undone work is put into production. Ever. Committed professional teams keep looking for ways to improve product quality as reflected in the definition of Done. Many teams across the world seem to be unable to create actually releasable Increments of product. Code is entered, and potentially tested, within a team. But the actual Increment remains scattered and hidden in long-lived branches. Or the work delivered at the end of a Sprint still needs to be integrated with fellow product teams. Or -even worse- it is to be shipped to different departments for that purpose. In those cases Scrum reveals important information over critical organisational dysfunctions impeding your agility. There is a substantial amount of “Undone Time”, the time it takes to go from an undone piece of work to a Done Increment. This time kills the option of opportunistic releases. The purpose of a Sprint in Scrum is not to just result in a piece of work that can be shipped to another team, functional group or department. An Increment is expected to be in a useable condition, ready for production. At least an Increment is to be integrated across teams and systems to have it in a production-deployable state. Most often teams include in their definition of Done all the development activities (of which in general a lot of testing) to be performed to consider an Increment as “Releasable”. Imagine however any non-software industry. Can you imagine ‘quality’ being expressed in terms of the machines, tools and practices to be applied? Is this not ‘how’ to create quality, but not a definition of quality? Quality is defined through the characteristics of a product. Quality is in the qualities that a product should exhibit. A “Done” product in Scrum is not just a product on which rigorously proper development standards were applied. A “Done” product is a product that exhibits your organization’s set of product qualities. Shifting the balance toward creating Valuable Increments is truly enacting Scrum, and living by the highest Agile principle: The Agile Manifesto: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software". (bold-indication by author) The Scrum Guide: "A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value". (bold-indication by author) So, do you have a definition of Done? If so, what are you defining as "Done"? Is it 'Releasable', or 'Valuable'? Is every Increment you create valuable? Why not? Does your Scrum Master know? Your management? And what are you doing about it?