The importance of human contact against the backdrop of a viral war

Observations from an independent Scrum Caretaker with an eye on humanization the workplace

The United Nations’ World Health Organization (“WHO”) correctly describes “Covid-19” as the disease caused by the “SARS-CoV-2” virus, a new variant within the Corona family of viruses. A Covid-19 infection typically shows through symptoms of fever combined with respiratory problems — a dry cough, shortness of breath, and (severe) breathing difficulties. As we speak, Covid-19 is exponentially spreading across large parts of the world, infecting frightening numbers of individuals. Although “Corona” actually is the name of the family of viruses, references to the current pandemic outbreak typically are “Corona (something).”

Beyond anything else, my thoughts are in the first place with individuals that are infected, whether they are quarantined in hospital, at home, or elsewhere. And I think of their loved ones and the people that are taking care of them –professionally or privately.

As soon as courses at school in Belgium were officially suspended, my wife and I decided to voluntarily put ourselves and our 3 kids in a lockdown situation. Given our oldest son’s progressive disability we weren’t going to take any risks. And although our decision went beyond the measures formally imposed by our government (at the time), we also believed our decision to be in the true spirit of these measures. Our decision encompassed not receiving visitors other than the professionals helping our son, avoiding all external contacts, and only leaving the house for the utmost urgent matters. Less than a week later Belgium officially went into a ‘lockdown.’

The spreading disease has a huge impact on people’s lives worldwide. I have my classes and work assignments being canceled. At a macro and a micro level I see the world brusquely being forced to a standstill. Beyond the dismay and stress, I try to grasp the opportunity to slow down. To some extent this crisis is a chance to pause the rat race, in which we do get caught up more than we like to admit. I try to grasp the opportunity to reflect, step back, pick up on some writing and reading ambitions that have been on hold for too long, do some gardening, and other highly unproductive activities. I further the development of my tortoise side.

Like so many, I am obviously suffering from some financial and economic setbacks. Although financial survival is important, I try not to let the monetary repercussions get me into short-term thinking and actions. I smell the danger of damage in the long run. I honestly believe in slowing down for now. I obviously cannot push “pause” indefinitely. Like so many, I revert to different ways to keep in touch with people and organizations I work with. There is stuff that I will now do virtually, remote, and distributed rather than in-person. There is much more I will not do virtually, remote, or distributed.

Most, if not all, of my work consists of helping and supporting individuals and groups explore complex challenges. We jointly figure out how Scrum can help them and what acting with agility means, in addressing their complex adaptive problems in their professional environments. Activities like teaching and coaching for that purpose require intense live interaction, dialogue, and deep conversations. My materials, my cases, and my approach are designed exactly for that. I am not in the face mask selling business. I do envision alternative ways of helping people, including remote channels. That however requires development of suitable materials and will not be magically available overnight.

Measures are being imposed on us to limit direct inter-human contact. They serve spreading the increase in infections in time and avoiding our care and health systems from crashing. I embrace them and use them as an invitation to consider the importance of human contact. I only see that importance strongly affirmed, more than ever before.

I am in awe of the people taking care of infected people. I try to turn this period into a time to reflect on the madness of our regular working situations — the rat race. Meanwhile I am perplexed, although not completely surprised, to observe how many people and organizations consistently put the economic losses over the human cost. I see the desperate instructions and desires to keep up productivity and efficiency in a situation where people are unable or prevented from coming to their regular workplace, not to mention that they most likely have other stressing concerns on their mind. What strikes me is this primal tendency to believe that ‘the shown must go on’ as if nothing else matters. Just do some tele-work and all will be fine. Really? Why would we pretend we can (or should) continue as if ‘normal’? Or –even worse– call this situation the ‘new normal,’ thereby pretending this will be the future way of working anyhow? I am appalled to see the continued disrespect for people trying to absorb what is happening to them, their children, their elderly parents or grand-parents, their friends, their relatives, their colleagues.

A storm is sweeping our planet. Is that too difficult to acknowledge? Accept giving up the idea of continuing ‘every day business’ for now. Losses will be incurred. Look beyond today, today’s productivity, and the current crisis. Give people a break, allow them to hit “pause.” Give them room and space now, and they will come back later fully recovered and re-energized. Losses will be incurred. The human cost caused by shifting the rat race from an on-site situation to tele-work today, denying people the opportunity to cope with the stress and tensions, will result into far more grave economic costs once this is over. It will backfire — economically and humanly.

I advise keeping that in mind when faced with all these self-called long-time proponents of distributed and remote ways of working that are suddenly popping up everywhere. Quite a lot are trying to take advantage of the crisis and your fears to increase their commercial position, sales figures or name and fame. Maybe they honestly intend to offer help, like they all obviously claim they do, but they, unintended or not, devaluate in-person human contact while keep people in the familiar productivity stranglehold. I understand how tools, platforms, papers, and more promoting remote work are helpful in this period. On a temporary basis and to some extent! But what is the pressure to keep productivity up to pre-crisis levels good for? I understand how many who are forced into distributed and remote working conditions are trying to make the best from their situation with tools, platforms, and various approaches. They ultimately try to get as close as possible to working in a co-located way. Still, it is no more than a surrogate solution. Even if it comes close, it will never be the same. And it is definitely not the new normal. Don’t allow the current way to turn into a permanent situation if that wasn’t your situation before the crisis.

Don’t allow snake oil merchants to abuse this viral war to spread the virus that human contact is not that important in the end. Don’t allow yourself to be limited to being a cog in a productivity machine. We are human beings. Our identity builds on our contacts, relationships and interactions with other human beings. And those relationships and interactions are richest when happing in-person. More than a cog in someone’s productivity machine, you are a social creature.

I can’t wait to move away from sub-optimal remote communications, go out again, and feel and touch people, shake hands, give a hug, and look my fellow people in the eye for the best collaboration possible. I can’t wait to go out again and enjoy direct human contact.

I wish you all the best. Be safe. Take care, like a humane Scrum Caretaker does.

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).

Announcing the book “97 Things every Scrum practitioner should know”

During the fall of 2019, I got totally consumed (and sometimes drained and overwhelmed) by an exciting new Scrum book project. Having finalized the manuscript I finally feel comfortable sharing more information about it.

O’Reilly Media envisioned adding a book about Scrum to their “97 Things” series and got in touch with me (through Dave West of Scrum.org). By the end of August 2019, we decided to get started. I had the honor of curating the initiative. We agreed on calling our new book “97 Things every Scrum practitioner should know.” The goal was to compose a book consisting of 97 essays with diverse angles and perspectives on the Scrum framework from contributors globally.

I had no idea what I was getting into, or how much 97 actually is (a lot, I discovered), or where it would take me. But I liked the challenge. Once into it, I liked it so much that I decided to make it my main focus, holding off most other work request and re-ordering my existing plans. It turned out an exciting and insightful experience. I had the pleasure of collecting, editing and ordering essays about Scrum from seasoned Scrum practitioners across the planet on behalf of the many seeking Scrum practitioners out there.

In a few incremental waves, we ended up inviting 129 people to contribute, not minded by their title, organization or position. We invited potential contributors for their insights, past or on-going, and the potential value of sharing them with fellow practitioners. In the end, 69 authors accepted our invitation and delivered one or more articles (indeed, an average of 1.406 articles per author). I cannot thank them enough for going through the effort of writing down their thoughts, perspectives and experience, and their willingness to make them available for Scrum practitioners worldwide.

Find an overview of them, alphabetically sorted, in the PDF “97 Things every Scrum practitioner should know (Contributors).” Or try to recognize them on following overview:

In the current version of the manuscript, the 97 essays are grouped and ordered* along following themes:

  • “Start, Adopt, Repeat.” holds 11 Things.
  • “Products Deliver Value.” holds 11 Things.
  • “Collaboration Is Key.” holds 10 Things.
  • “Development Is Multi-faceted Work.” holds 12 Things.
  • “Events, Not Meetings.” holds 10 Things.
  • “Mastery Does Matter.” holds 12 Things.
  • “People, All Too Human.” holds 8 Things.
  • “Values Drive Behavior.” holds 6 Things.
  • “Organizational Design.” holds 9 Things.
  • “Scrum Off Script.” holds 8 Things.

I also owe a huge thank you to O’Reilly Media for the trust and the collaborative partnership, specifically to Chris Guzikowski and Ryan Shaw for initiating this endeavor and to Corbin Collins for sustaining it. More than being a king of punctuation, Corbin has impressively improved the language and clarity of quite some, if not all, of the 97 Things.

I look forward to keeping you updated on the publication date, which we will derive from our actual progress. It is not expected to be later than July 2020, and will probably be sooner. As we speak, O’Reilly and I are working really hard to turn my manuscript into a book available for you, dear reader.

I believe we will be able to connect the world of seasoned practitioners to the world of seekers through “97 Things every Scrum practitioner should know.”

Warm regards
Gunther Verheyen
independent Scrum Caretaker
December 2019
(updated February 2020)

“Scrum – Una Guida Tascabile” is now widely available

As I was working on the second edition of my pocket guide to Scrum in 2018, Michael F Forni proposed to create an Italian translation of my book. It was the start of a collaborative endeavour, in which he got help from Fabio Panzavolta and Aniello Di Florio, towards self-publishing the translation.

I am humbled and honoured for announcing that the result is now available as Scrum – Una Guida Tascabile (Un compagno di viaggio smart)“, in Kindle and in paperback format via Amazon.

I wish all Italian speaking friends of Scrum much joy reading my translated thoughts, beliefs and considerations of Scrum, that simple framework to address complex challenges. I feel forever indebted to Michael, Fabio and Aniello for making my book available for all Italian readers, and to Barbara Knijff of Jellylab for creating the cover.

Loving regards
Gunther
independent Scrum Caretaker

Here is how Michael, Fabio and Aniello introduced their work in the book:

Nel ringraziare Gunther per questa fantastica opportunità – consapevoli della grande responsabilità che porta il compito di tradurre un così importante testo divulgativo come la sua Guida a Scrum – chiediamo al lettore di essere comprensivo e di focalizzarsi il più possibile sulla sostanza del pensiero dell’autore, piuttosto che sulla forma di volta in volta scelta dal traduttore: il reale valore di manuali come questo non sta infatti nel successo – o meno – di riuscire a cogliere esattamente il senso della singola parola o frase, bensì quello di trasmetterne efficacemente i concetti, gli esempi e le pratiche da applicare al proprio contesto individuale.

Per la traduzione della terminologia Scrum, ferma restando l’assoluta inopportunità, pienamente condivisa con l’autore, di modificare o storpiare i consolidati sostantivi caratterizzanti del framework (oramai divenuti d’uso comune nella Comunità Internazionale degli Agile practitioners) – sono state tenute in debita considerazione: 1) le traduzioni passate ed attuale delle versioni in Italiano de “La Guida a Scrum” 2) il lessico oramai d’uso comune tra i praticanti di Scrum 3) la nostra sensibilità di bilingue, che naturalmente risente delle esperienze personali.

Contiamo che il lettore sia indulgente e non ce ne voglia; qualora rilevasse errori, imprecisioni o volesse dare il proprio contributo migliorativo, saremo felici di essere contattati per apportare ulteriore valore a quest’opera.

Buona lettura!

Michael Fabrizio Forni – Co-traduttore e curatore dell’opera
Fabio Panzavolta – Co-traduttore
Aniello Di Florio – Correttore bozze

 

Can you say ‘yes’? (10 questions about your Scrum)

I call myself a  Scrum Caretaker. I aspire inspiring people using Scrum. I prefer showing that I care by sharing positive experiences and cases that demonstrate how amazing working with Scrum can be, what problems can be tackled and how to, the level of excellence we can build into our products, how Scrum can engage people. Ultimately I hope to help people employ Scrum to re-humanize their workplace.

But then it regularly dawns on us — the many, many misconceptions that exist over Scrum. We feel provoked to try to correct the recurring and worrying interpretations of Scrum that are out there. Sometimes that is fun. Often it is not. It can be energizing. In general it drains us. A few lifetimes can be spent fighting that battle. We limit the energy spent fighting to make room for constructing. 

A good place to start is reminding people of what ought to be in place according to Scrum. It provides clarity over what is mandatory in Scrum (and therefore, what is not).

Unlocking the benefits of Scrum requires however a lot more than just knowing what Scrum consists of. Scrum is the foundation to a complex adaptive system (‘CAS’) producing results that cannot be attributed to its individual components separately. Unlocking the benefits of Scrum depends more on the way the whole of Scrum is being used, through the rules that bind its constituent parts together. Unlocking the benefits of Scrum depends even more on what the people practicing Scrum do, more than what they know or say in the name of theory. It depends on how people interact within the framework, the conversations they have.

Here are 10 questions to help you assess what you do with the 11 elements of Scrum. Can you say ‘yes’?

  1. The accountabilities of Product Owner, Development Team(s) and Scrum Master are identified and enacted?
  2. Work is organized in consecutive Sprints of 4 weeks or less?
  3. There is an ordered Product Backlog?
  4. There is a Sprint Backlog with a visualization of remaining work for the Sprint?
  5. At Sprint Planning a forecast, Sprint Backlog and a Sprint Goal are created?
  6. The result of the Daily Scrum is work being re-planned for the next day?
  7. No later than by the end of the Sprint a Done Increment is created?
  8. Stakeholders offer feedback as a result from inspecting the Increment at the Sprint Review?
  9. Product Backlog is updated as a result of Sprint Review?
  10. Product Owner, Development Team(s) and Scrum Master align on the work process for their next Sprint at the Sprint Retrospective?

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions, meanwhile collaboratively exploring different  If you don’t overthink your way of working along that road of evolution, you might find Scrum to be of a bare essence actually.

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions.

If you don’t overthink your way of working along that road of expansion and evolution, you might find Scrum to be of a bare essence actually. Do know that understanding that Scrum requires 11 elements to be in place is only the beginning. My 10 questions might help you better understand how they relate to each other. Find yourself at the beginning still. Understand how all of them serve empiricism, the act of regular inspection and adaptation, and how inspection without adaptation makes no sense in a world of Scrum. Separate rules from tactics to play the game. Use empiricism also to explore different tactics

My Scrum Gameboard not only represents the 11 mandatory elements, but also 3 principles underlying Scrum. Understand how the Scrum Values drive behavior.

Keep learning.
Keep improving.
Keep… Scrumming.

Warm regards
Gunther
independent Scrum Caretaker

The Scrum Glossary and the Scrum Values are now also available in Tamil

Thanks to the hard work of Mohammad Umar Farooq and Balachandhiran Sankaran, the international versions of the Scrum Glossary and the Scrum Values have been expanded with Tamil.

Download your PDF of the Scrum Glossary, your PDF of the Scrum Values and your poster of the international Scrum Values. Share and use them as you see fit.

The descriptions are now available in more than 20 different languages, thanks to all volunteers that worked hard to create these gifts.

  • Arabic: Rasheed Raya
  • Belarusian: Vasili Shymanski
  • Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia
  • Danish: Rasmus Kaae, Mikkel Toudal Kristiansen
  • Dutch, English: Gunther Verheyen
  • Filipino: Shirley Santiago, Warren Yu
  • French: Fabio Panzavolta, Mohamed Gargouri
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini
  • Greek: Thodoris Bais, Nikolas Friligkos
  • Hindi: Punit Doshi, Hiren Doshi
  • Italian: Michael F. Forni
  • Persian: Mehdi Hoseini
  • Polish: Paweł Feliński, Krystian Kaczor
  • Portuguese: Leonardo Bittencourt
  • Russian: Konstantin Razumovsky
  • Spanish: Alex Ballarin, Pablo Bernardo
  • Tamil: Mohammad Umar Farooq, Balachandhiran Sankaran
  • Turkish: ilkay Polat, Lemi Orhan Ergin
  • Ukrainian: Andrii Glushchenko
  • Vietnamese: Khoa Doan

“Scrum – Um Guia de Bolso” is now widely available

As I was working on the second edition of my pocket guide to Scrum in 2018, Rodrigo Silva Pinto and Leonardo Bittencourt proposed to create a Portuguese translation of my book. It was the start of a collaborative endeavour towards self-publishing the translation.

I am humbled and honoured for announcing that the result is now available as Scrum – Um Guia de Bolso (Um companheiro de viagem inteligente)“, in Kindle and in paperback format via Amazon.

(note: the primary market for the Kindle version is Brazil which allows me to keep the price affordable. The paperback’s primary market could not be set to the same so I had to set that to the US. Both versions however are available through all market places of Amazon.)

I wish all Portuguese speaking friends of Scrum much joy reading my translated thoughts, beliefs and considerations of Scrum, that simple framework to address complex challenges. I feel forever indebted to Rodrigo and Leonardo for making my book available for all Portuguese readers, and to Barbara Knijff of Jellylab for creating the cover.

Loving regards
Gunther
independent Scrum Caretaker

Here is how Rodrigo and Leonardo introduced their work in the book:

Rodrigo Silva Pinto, Agile School, junho 2019

Tenho a oportunidade de formar centenas de pessoas todos os anos em treinamentos de Scrum que vão dos fundamentos a conteúdos mais avançados. Um pedido comum entre os alunos é a indicação de literatura do gênero. Mas a resposta por muito tempo era não satisfatória: “O livro Pocket Guide do Gunther é o melhor, mas só está disponível na língua inglesa”. Havia uma lacuna, faltava uma boa referência literária do Scrum para os falantes de língua portuguesa.

Cansado de esperar, resolvi fazer parte deste projeto, propagando um conteúdo de altíssimo nível e me associando a um dos autores mais influentes do tema, depois dos próprios criadores do framework.

Espero que as horas dispendidas em “Scrum – Um guia de bolso”, possam contribuir com a comunidade Ágil e o mercado brasileiro para juntos construirmos produtos com alto índice de profissionalismo e que gerem impacto necessário para mudar o mundo.

Leonardo Bittencourt, Principal Lean/Agile Consultant, junho 2019

Tive o prazer de conhecer o Gunther pessoalmente durante Agile Tour Vilnius em 2017. Posteriormente colaborei com a tradução de dois de seus trabalhos para Português, o Glossário Scrum e os Valores do Scrum. Indubitavelmente ele faz juz ao que se auto-intitula, Zelador do Scrum (Scrum Caretaker).

Nesta obra, Gunther usa uma linguagem simples que vai direto ao cerne do Scrum, aborda os pontos cruciais e clarifica o framework Scrum de uma forma cirúrgica. Este livro lhe ajudará a evitar armadilhas, equívocos e adoção de um Scrum mecânico. Você compreenderá o propósito do Scrum Framework bem como os porquês de cada elemento que o compõe.

Manter o conteúdo sem distorções e com a mesma clareza, onde as palavras usadas na versão original foram minuciosamente pensadas, trouxe uma boa dose de desafio extra.

Indico este livro para quem está iniciando e para quem já tem experiência com Scrum. Lhe garanto que durante sua leitura – ou releituras como no meu caso – sempre haverão novas descobertas.

Não perca tempo. Boa leitura e Scrum on!