Posted on Leave a comment

My PSM class of May 2020 will be online.

A virtual and integral learning experience.

In April 2020, I facilitated my first PSM course (‘Professional Scrum Master’) in an online mode. Ever. Looking at the feedback received, I needlessly worried over the ability to have some great conversations and interactions:

I was pleasantly surprised with the online setup. It did really work and definitely with the size of our group. It was a job well done!

It was amazing to see how Gunther can tell a story and take you into the wonders of Scrum seamlessly. I read the guid upfront but he made it comprehensible and into one story.

So, that certainly increased our confidence and allow our next Professional Scrum Master course to happen online again. Check your agenda for your availability on 28 and 29 May 2020. Seats are limited. Get in touch via my partner Sugar-Me.

Posted on 5 Comments

Availability of the book “97 Things Every Scrum Practitioner Should Know”

My new book “97 Things Every Scrum Practitioner Should Know” is widely available, electronically as well as in print.

Following are a few channels: eBooks.comAmazon.com, Amazon UK, Amazon Netherlands, Amazon Germany, Amazon France, Amazon SpainGoogle Books, Barnes & Noble, Bol.com, Computer Bookshop IndiaAmazon India, Books.com Taiwan, Amazon Japan and PWN Poland.

No fewer than 68 practitioners expended the effort to write one or more essays about Scrum for you. We did not invite them for their titles, ranks, or positions. We invited them because they have valuable insights to share with fellow practitioners like you. I thank every single one of them.
I thank you, reader, for buying the book, but even more for employing Scrum and for sharing and spreading how you make use of Scrum in addressing your specific challenges. Keep being an inspiration to other Scrum practitioners.

Find the full description of the book also at the website of the publisher, O’Reilly Media.

– – –

O’Reilly Media and I started collaborating on the book in August 2019. Looking back, I had no idea what I was getting into, where it would take me, or how much 97 is (a lot, actually, as I discovered). Inviting and working with authors from around the globe was an exciting endeavor however.

The work has much consumed (and sometimes drained and overwhelmed) me, but I am very happy with the result. Given the tons of available literature on Scrum, it proved not an easy feat trying to still make a difference. Thanks to the generous and insightful contributions of the participating authors, I believe we have done that.

I enjoyed looking for commonalities and shared themes as essays poured in. I have tried to group and order the collected essays in a way that makes sense to the many seeking Scrum practitioners out there. It was a way to create some flow across the book:

  • Part I. Start, Adopt, Repeat: 11 Things. Because adopting Scrum is more than just a one-time effort of introducing Scrum; it is a continual exercise of thinking, rethinking, and discovery.
  • Part II. Products Deliver Value: 11 Things. Because in a complex world of unstable requirements and ever-evolving technologies, “product” provides a minimal form of stability to organize your work with Scrum.
  • Part III. Collaboration Is Key: 10 Things. Because creating, sustaining, and evolving complex products and services in complex and changing environments requires collective intelligence, skills, and expertise.
  • Part IV. Development Is Multifaceted Work: 12 Things. Because development of complex products (in often complex circumstances) requires more than technically producing work (like coding or programming only).
  • Part V. Events, Not Meetings: 10 Things. Because what are commonly called the Scrum meetings are actually events that provide specific opportunities for inspection and adaptation.
  • Part VI. Mastery Does Matter: 12 Things. Because mastery matters not just for Scrum Masters, although they are quite important as masters of ceremony.
  • Part VII. People, All Too Human: 8 Things. Because development is done by people, often resulting in work for people. And people are…people.
  • Part VIII. Values Drive Behavior: 6 Things. Because Scrum is a framework of rules, principles, and…values. And values drive behavior.
  • Part IX. Organizational Design: 9 Things. Because introducing Scrum is not possible without impacting the organization and existing organizational structures.
  • Part X. Scrum Off Script: 8 Things. Because for Scrum practitioners to help shape the future of Scrum, we need imagination combined with historical awareness.

Fortunately, the essays can be read separately as well. At the end of the book, a Scrum Glossary was added, listing and explaining in the simplest way the terms used in the book.

Warm regards
Gunther
independent Scrum Caretaker

Posted on Leave a comment

Moving Your Scrum Downfield (Six Essential Traits of the Game)

Apparently, it is easy to get stuck at interpreting the rules of Scrum. In the publication “Moving Your Scrum Downfield” I have described the six essential traits of the game to help you get unstuck and up your game. As they express rather intrinsic and implicit principles, they are too often disregarded. Yet, they are needed for a more unconsidered performance of Scrum, which allows minding the goal of the game–push back the old adversary of predictive rigidity–rather than the rules. These six essential traits are indicative of Scrum coming to life.

Having worked with Scrum since 2003, I am fascinated by its ever-expanding use, which is not limited to software and (new) product development.

Jeff Sutherland and Ken Schwaber moved the development of Scrum forward in the early 1990s. They are the co-creators and gatekeepers of (what is) Scrum.

Ken Schwaber first documented Scrum in 1995 in the paper “SCRUM Development Process.” In 2010 he initiated the creation of the Scrum Guide. Upon Jeff Sutherland’s consent, the Scrum Guide became the definitive body of knowledge holding the definition of Scrum (and what is not Scrum). A few small, functional updates were released since then, without drastic changes to the core definition of Scrum.

Scrum was instrumental in embracing software development as a form of new product development, and thus as complex work. An ever-increasing variety of work in modern society however is inherently complex too. Software and (new) product development are a subset of complex challenges, but the use of Scrum is not limited to it.

As an independent Scrum Caretaker, I care for people and organizations asking for guidance and support on their journey of Scrum, no matter the nature of their problem.

My work builds on the belief that organizations best envision their Scrum. I don’t believe in mechanistically reproducing past or others’ ways. Every case of Scrum is unique. Your Scrum is unique. No external instance—expert or otherwise—can devise your Scrum for you. There is no copy-paste. What works today might not work tomorrow. Rather than cookbook solutions, I offer help in developing people’s ability to think in terms of Scrum.

Apparently, many get stuck at interpreting the (exactness of the) rules, meanwhile losing sight of the goal of their game. Having authored the books Scrum – A Pocket Guide (2013, 2019) and 97 Things Every Scrum Practitioner Should Know (2020) I took a step back to consider what it is that makes Scrum work. The rules of the game are well documented. Assuming they are understood, what is needed to get unstuck, engage, and up your game?

I believe it is in embedding the six essential traits of the game. As expressions of rather intrinsic and implicit principles, they are easily disregarded. Yet, they are crucial to excel at Scrum and need to underly your game strategies. They are indicative of Scrum coming to life. They need to be ingrained and embodied for a more unconsidered performance of the game, for you to focus on the goal of the game again rather than on the rules.

Consider how the six essential traits of the game are indicative of Scrum coming to life:

  1. Scrum Is Simple, Yet Sufficient. The players unfold the potential of Scrum by using the simple rules that apply and explore how tactics, interactions, behaviors, and the six essential traits make Scrum work.
  2. Scrum’s DNA. The players form a self-organizing unit around the challenge of collectively creating observable, Done Increments of work, while employing empiricism to manage all work and progress.
  3. Players Demonstrate Accountability. The players contribute to valuable system outcomes through spirited collaboration, and sharing and challenging rules, agreements, skills, practices, ideas, and viewpoints.
  4. Transparency for a Flow of Value. The players use the Scrum artifacts to uphold transparency over all work done and work to be done, manage for a flow of value and preserve the ability to capitalize on unforeseen opportunities.
  5. Closing the Loops. The players regularly and repeatedly close the many intertwined loops within a Sprint toward full closure by the end of a Sprint and preserving unburdened adaptability at the macro level.
  6. The Scrum Values. The Scrum Values of Commitment, Focus, Openness, Respect, and Courage take prominence in the behaviors, relationships, actions, and decisions of the players and their ecosystem.

Are you ready to start moving your Scrum downfield, push back the old adversary of predictive rigidity and sustainably increase your agility?

Gunther Verheyen
independent Scrum Caretaker

Posted on Leave a comment

Daily Scrum Pocketcasts – Episode 5

Ever since the accidental creation of my book “Scrum – A Pocket Guide” in 2013, and its deliberate evolution in 2019, I’ve been receiving inquiries about an audiobook version. So far, I have not been able to make that happen but the 2020 pandemic storm got me into implementing the audio idea in a different form.

In subsequent daily broadcasts I have read all chapters from my pocket guide to Scrum. Every reading session happened on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions were open for 100 attendants and were time-boxed to a total of 1 hour of me reading.

On Monday 30 March 2020 I delivered episode 5 (the final) of my “Daily Scrum Pocketcasts” in which I have read following chapters from my book:

4. THE FUTURE STATE OF SCRUM

4.1 Yes, we do Scrum. And…
4.2 The power of the possible product
4.3 The upstream adoption of Scrum

ABOUT THE AUTHOR

Besides the recorded episode being available on my YouTube channel, find the audio version on SoundCloud.

Posted on Leave a comment

Daily Scrum Pocketcasts – Episode 4

Ever since the accidental creation of my book “Scrum – A Pocket Guide” in 2013, and its deliberate evolution in 2019, I’ve been receiving inquiries about an audiobook version. So far, I have not been able to make that happen but the 2020 pandemic storm got me into implementing the audio idea in a different form.

In subsequent daily broadcasts I have read all chapters from my pocket guide to Scrum. Every reading session happened on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions were open for 100 attendants and were time-boxed to a total of 1 hour of me reading.

On Friday 27 March 2020 I delivered episode 4 of my “Daily Scrum Pocketcasts” in which I have read following chapters from my book:

2.7 The Scrum values

3. TACTICS FOR A PURPOSE

3.1 Visualizing progress
3.2 The Daily Scrum questions
3.3 Product Backlog refinement
3.4 User Stories
3.5 Planning Poker
3.6 Sprint length
3.7 How Scrum scales

Besides the recorded episode being available on my YouTube channel, find the audio version on SoundCloud.

 

Posted on Leave a comment

Daily Scrum Pocketcasts – Episode 3

Ever since the accidental creation of my book “Scrum – A Pocket Guide” in 2013, and its deliberate evolution in 2019, I’ve been receiving inquiries about an audiobook version. So far, I have not been able to make that happen but the 2020 pandemic storm got me into implementing the audio idea in a different form.

In subsequent daily broadcasts I have read all chapters from my pocket guide to Scrum. Every reading session happened on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions were open for 100 attendants and were time-boxed to a total of 1 hour of me reading.

On Thursday 26 March 2020 I delivered episode 3 of my “Daily Scrum Pocketcasts” in which I have read following chapters from my book:

2.5 Playing the game (continued)
2.6 Core principles of Scrum

Besides the recorded episode being available on my YouTube channel, find the audio version on SoundCloud.

 

Posted on Leave a comment

Daily Scrum Pocketcasts – Episode 2

Ever since the accidental creation of my book “Scrum – A Pocket Guide” in 2013, and its deliberate evolution in 2019, I’ve been receiving inquiries about an audiobook version. So far, I have not been able to make that happen but the 2020 pandemic storm got me into implementing the audio idea in a different form.

In subsequent daily broadcasts I have read all chapters from my pocket guide to Scrum. Every reading session happened on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions were open for 100 attendants and were time-boxed to a total of 1 hour of me reading.

On Wednesday 25 March 2020 I delivered episode 2 of my “Daily Scrum Pocketcasts” in which I have read following chapters from my book:

1.6 Combining Agile and Lean

2. SCRUM

2.1 The house of Scrum
2.2 Scrum, what’s in a name?
2.3 Is that a gorilla I see over there?
2.4 Framework, not methodology
2.5 Playing the game (intro)

Besides the recorded episode being available on my YouTube channel, find the audio version on SoundCloud.

 

Posted on 4 Comments

Daily Scrum Pocketcasts – Episode 1

Ever since the accidental creation of my book “Scrum – A Pocket Guide” in 2013, and its deliberate evolution in 2019, I’ve been receiving inquiries about an audiobook version. So far, I have not been able to make that happen but the 2020 pandemic storm got me into implementing the audio idea in a different form.

In subsequent daily broadcasts I have read all chapters from my pocket guide to Scrum. Every reading session happened on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions were open for 100 attendants and were time-boxed to a total of 1 hour of me reading.

On Tuesday 24 March 2020 I delivered episode 1 of my “Daily Scrum Pocketcasts” in which I have read following chapters from my book:

Foreword by Ken Schwaber
Preface
1. THE AGILE PARADIGM

1.1 To shift or not to shift
1.2 The origins of Agile
1.3 Definition of Agile
1.4 The iterative-incremental continuum
1.5 Agility can’t be planned

Besides the recorded episode being available on my YouTube channel, find the audio version on SoundCloud.

 

Posted on Leave a comment

Daily Scrum Pocketcasts

Ever since the accidental creation of my book Scrum – A Pocket Guide (A Smart Travel Companion) in 2013, and its deliberate evolution in 2019, I frequently receive inquiries about the availability of an audiobook version.

Although I see value in the idea, I have not been able to make it happen so far.

Given the current pandemic storm, forcing many friends of Scrum to remain at home, I decided to implement upon the audio idea in a slightly adjusted form.

Starting Tuesday 24 March 2020, I have planned a first series of five “Daily Scrum Pocketcasts.” In subsequent daily broadcasts I will read my Scrum Pocket Guide front to back. I will do a reading session on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions are open for 100 attendants. Registered attendants can send me questions about the book, or parts of it. I plan to read for 30-45 minutes every day after which I hope I can address questions related to the chapter(s) of the day. Every daily session will be time-boxed to a total of 1 hour.

I plan to also record the sessions and make them available via my YouTube channel. I hope to collect the questions and my (written) answers in a document that, if all works out, I will share for free with everyone.

I have no idea where this will take us, how long it will last, or how the idea and its emerging implementation will unfold. Of one thing I am sure, it won’t all be smooth. Come find out with me, and register on Zoom (or copy following link to your browser https://us04web.zoom.us/meeting/register/upclduugrT8ruk_h1txTV8KP1_59Dj9sZg). Note that each session requires separate registration.

Warm regards
Gunther
your independent Scrum Caretaker

Posted on Leave a comment

Minimal measures for minimal stability in a complex world (that will help you optimize your Scrum)

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; by explicitly acknowledging software and new product development to be complex work, serving to deliver complex products in complex circumstances.

Scrum is increasingly being discovered as a simple framework to address complex problems and situations other than software and product development. More and different people, teams and organizations ask for guidance and support on their journey of Scrum, no matter the nature of their problem. Organizations discover that fighting complexity with complexity is not helping. Too much waste, organizational redundancy and fundamental impediments remain unaddressed by the overly complex approaches that organizations use. No sustainable agility is achieved. Organizations discover that they have been seeking for (or were pointed to) universal truths where there are none.

Complex work, of which software and product development are good examples, does not have the high degree of predictability to apply the old approaches that build on linearity, causality and predictive management.

One aspect of ‘complexity’ are the parameters, variables and events that influence an activity and its course. Think of your work, make a list. Consider how predictable the listed variables are, how much control you actually have over them and how sure you are that you listed all of them. However, it is not only the number of known parameters that is important, but also the available as well as the required knowledge over these parameters. What is the level of detail required to comprehend a variable as well as the future behavior of that variable? How long does it take to gather that information? How stable is that information, once collected? Even if a parameter is known, the level of detail may be too deep to be able to manage and control it. And then, of course, the behavior of the parameter is still not necessarily predictable. A known variable may still behave completely different compared to what was planned or expected to happen. And, do not forget that all variables, known and unknown, are related and impact each other, typically in non-linear ways.

‘Complexity’ is also dependent on the nature of the work itself. The combined steps, tasks and activities that make out complex work are not predictable with any degree of high precision. They have not been performed before, or not in the same way or context. They are not repeatable. New insights, techniques and approaches emerge, even while the work is already taking place. Also, the exact and detailed outcomes of complex work are hard to describe and predict before or even at the beginning of the actual work. Expectations change. Markets evolve. Competitors surprise you. And, complex work typically requires the cognitive and creative capabilities of people performing the work. The engagement and involvement of people is dependent on more circumstances than we comprehend, let alone can control.

Complex work is actually more unpredictable than it is predictable. Complex problems are dynamic, not static. The degree of dynamism of a problem or activity requires the right forms of process and stability to be in place in order to have some form of control. Stability in complex work performed in a complex world comes not from fixing requirements, outputs, timelines or plans. These are destined to be unstable and will change. Stability is not about certainty or predictability. Stability is about an environment and boundaries within which to explore and experiment, within which to continually diverge and converge towards incremental solutions answering your complex needs.

Too many organizations end up in total chaos when they experience how the old elements of stability no longer work, but fail to replace them with the minimal measures that would help them optimize their Scrum to better address their complexity:

Start with identifying your problem (product).

In a typical Scrum setting, the problem is developing complex solutions, often a product or a service.

Define and identify your product first. Then organize your Scrum, or re-imagine your Scrum, to optimally tackle your problem or serve your product.

I have observed too many many organizations form Scrum Teams within existing specialist silos and departments, doing little more than renaming existing titles and functions to Scrum terms,
certainly not minding the scope of their Scrum, let alone capitalizing on synergies that exist across those individual Scrum Teams, like the fact that they actually all work on the same product. Disconnectedness is not resolved. The complex problem is not adequately tackled. Parts or components of product are being built, rather than integrated, cohesive product versions that provide end-to-end value.

Have dedicated teams working in dedicated team spaces.

Complex problem-solving requires focus, interaction, communication, collaboration, cross-fertilization and collective intelligence. It requires dedication.

Teams should not be all over the place in terms of getting dragged to external meetings regularly or having to work in multiple teams or on multiple projects. Your teams should be able to primarily dedicate their time maximally on the problem/product at hand, self-manage their work in Sprints and even figure out and establish their own team size and team composition. I have observed too many teams that were really jelling and achieving a highly collaborative state, until being pulled apart by people external to the team; resource managers, departments heads, project management offices. Each one of those teams ultimately plummeted, demotivated.

Teams definitely need a dedicated team space to get the most out of their collaboration, conversations and interactions. Open offices kill innovation and creativity, even more when combined with clean wall policies. People dare not speak up or need to move to separate meeting rooms to do so. Open offices are good for… office work, not for intense and collective problem-solving.

Benefit from the consistency that the Scrum events provide without industrializing your Scrum to death.

Scrum by default offers stability and consistency by suggesting to keep Sprint length stable over a substantial period. It allows people to, often unconsciously, grow an intuition of what is (not) possible, which is extremely helpful in forecasting Sprint and Product Backlog work. It offers minimal stability. It is why Sprints, as container events, have a fixed time-box. Sprints don’t end sooner or later than the set time-box, while the other events can end sooner. Sprint is a stable container event that provides overall rhythm and cadence to the opportunities for inspections and adaptations foreseen within a Sprint; Sprint Review, Daily Scrum, Sprint Review and Sprint Retrospective.

I am astonished however how organizations dictate a fixed Sprint length to all teams across the organization, regardless of their problem, technology, business domain, product. Organizations tend to industrialize their Scrum, rather than standardize on Scrum. Scrum can be introduced and adopted, allowing all within an organization to speak the same language, without eliminating the option of tuning your Scrum to a specific context.

Scrum only defines that Sprints should be no longer than 4 weeks. Within that range every complex product development endeavor can decide over its own right-size Sprint length. This right-size stability factor is not necessarily the same for all products. This brings us back to the necessity of identifying your product or service first, and then organizing your Scrum to optimally serve your product (including considering the Sprint cadence for all teams serving the product).