Scrum Recordings in English (so far)

During the summer of 2017, I took some time to work with the professionals of HigherView to create a couple of recordings on topics related to Scrum that I deeply care about. As I am considering ideas for new recordings, enjoy them here in one place (or look them, and other recordings, up at my YouTube channel):

Scrum, a simple framework for complex product delivery

Scrum Master, a mould for the modern manager

Product Owner, actually, owns the product

Product Backlog and the tea leaves effect

The future of Agile, actually, is in the small

The 3rd Scrum Wave (Will you sink, swim, or… surf?)

Re-vers-ify (Re-imagining your Scrum to re-emerge your organization)

Springtime and work anniversaries

The many congratulations today reminded me of my most recent work anniversaries.

  • April 2013, five years ago. I started Ullizee-Inc. It was a huge step to abandon my safe position at Capgemini, even when it was to move to the home of Scrum.
  • April 2016, two years ago. Letting go of exclusively partnering with Ken Schwaber and working for Scrum.org was, if not just an even bigger step, certainly a more frightening one.
  • April 2018, today. Reflecting, looking back, those were decisions I ‚had‘ to take. For they were the most honorable decisions to take.

Looking back, I regret none of my job changes, despite the losses, the pain, the regret to find we were not in it together after all. They turned out very revealing experiences in many regards, not only professionally but certainly at a personal and human level (if ever those aspects can be separated). Looking back, those were the best decisions possible. Looking back, it leaves the misleading impression that it was all part of some bigger plan.

Looking back even further, I wonder. Quite some of my many job changes actually happened in springtime. More importantly probably, every single one was based on principles and values and was a forward-looking decision, in search of a different, if not better, future.

Over time, certainly, I started recognizing, appreciating and ultimately embracing that I am good at searching, not at finding, that I am good at travelling, not at arriving. Really good at not belonging too, an outsider. Wholeheartedly however. Walking the difficult path, facing the challenge to achieve what I may find I need to achieve without being part of formal, corporate or commercial structures anymore.

There are plenty of challenges, more than I ever will be able to handle, and probably even more deciding to be on my own 2 feet. Some challenges are known, most are not. What life is all about, right?

Allow me to thrive on deliberately emerging opportunities to bring value; to the individuals, the communities, the teams, the organizations I am grateful to work with.

With love

Gunther
Scrum Caretaker
Eternal novice

The Scrum Values (poster)

While developing my book “Scrum – A Pocket Guide” (2013) I described how there is value in the Scrum Values. In 2016 the Scrum Values were added to the Scrum Guide.

The Scrum Values (poster)

As part of an on-going translation initiative by a group of international enthusiasts I have created a poster of the Scrum Values, now available as a free download (PNG): The Scrum Values (poster). Find the slightly updated description of the Scrum Values as a separate section on this website.

The Scrum Values are simultaneously needed for and emerging as part of Scrum. Values drive behavior. Scrum is a tool. Scrum is a (servant) process. Scrum is a framework. Even more however, Scrum is about behavior.

 

 

 

Professional Scrum in France

I am honoured to announce my partnership for Professional Scrum courses with the XEBIA ACADEMY FRANCE.

This is a great extension of the partnership that the Xebia Academy and I, as an independent Scrum Caretaker, have established in the Netherlands.

The Xebia Academy Netherlands has proven to be a professional training provider. They host our classes in their beautiful locations. They provide all that is needed for the course participants and myself to turn our classes into lively events. As a Professional Scrum Trainer, I am gratified to be working with them and am happy they host all my public classes in the Netherlands.

I look forward to connecting with French Scrum practitioners through my work with the Xebia Academy France. It is an important way to have deep conversations about Professional Scrum in France, to serve local Scrum practitioners and to expand my collaborations with more and more people and organizations across Europe.

The first tangible result of our collaboration is the organization of 2 Professional Scrum classes in the main offices of Xebia France in Paris:

PSM_71

A Professional Scrum Master course on 17+18 May 2018.

PSPO_71

A Professional Scrum Product Owner course on 30+31 May 2018.

The courses will run in English, although I embrace the opportunity to improve upon my French.

Scrum Glossary (International Versions)

By the end of 2017 I updated the Scrum Glossary of my book “Scrum – A Pocket Guide” (2013). A group of Scrum enthusiasts subsequently translated that updated version to different languages.

The combined international versions are now available as a free download (PDF): Scrum Glossary (International versions) -March 2018

Share my gratitude that following people spent quite some of their valuable time on this initiative to make these translations available for you:

  • Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia
  • Danish: Rasmus Kaae
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini
  • Italian: Michael F. Forni
  • Polish: Paweł Feliński
  • Portuguese: Leonardo Bittencourt
  • Russian: Konstantin Razumovsky
  • Spanish: Alex Ballarin

In the document you will also find my Dutch translation.

More translations are being created. Additional initiatives are being considered.

All feedback is welcome. Sharing of the PDF is equally encouraged.

Warm regards
Gunther

The “ScrumAnd” Stance (requiring thought and discipline)

Try organizing a party in a “Yes, but…” atmosphere. The result is probably a zillion obstacles identified, but no party.
Try moving through a door with your eyes stubbornly fixated on the door frame. People seemingly can become deeply obsessed with frames-as-obstacles.

Try benefiting from Scrum in a “Yes, but…” environment, where the primary response is to raise concerns and hindrances, where the conversation is all about obstacles, and that what cannot be done.

“Yes, but” comes in many guises.

“Yes, but” is a tempting stance, offering the illusion of safety. Shifting to “Yes, and” requires thought and discipline. It requires thought and discipline to consciously look for possibilities and opportunities first, no matter how small. This does not preclude awareness of problems and obstacles, but the focal point shifts radically. Check if the door is actually open. Look at the doorway. Trust the door frame for holding the wall from collapsing if you pass the door. If the door is closed, the frame is probably not where the solution is. 

Imagine adopting Scrum from a “Yes, and” stance.

Over the past decade Scrum did more than just gain a critical mass to build on. Since Scrum’s inception in 1995 and the definition of ‘Agile’ as a set of values and principles in 2001, Scrum gradually became the most preferred way for people, teams and organizations worldwide to become more Agile. Agile crossed the chasm (2005-2006) and by now the 3rd Scrum Wave has risen.

Zeitgeist. Inclusive language and an inclusive stance are more helpful today. “ScrumAnd” is today’s way forward to help people increase the benefits realized through their manifestation of Scrum. 

“ScrumAnd” starts with Scrum. Scrum is a simple, yet cohesive framework. In a nutshell:

A Scrum Master fosters an environment where:

  1. A Product Owner assures there is a Product Backlog, an ordered list of work deemed necessary to optimize the value a product delivers.
  2. In consultation with the Product Owner, Development Team(s) pull the work from Product Backlog deemed feasible to get done in a time-boxed Sprint against an overarching Sprint Goal.
  3. On a daily basis the Development Team(s) synchronize their progress and upcoming work toward delivering a releasable version of product, available no later than by the end the Sprint.
  4. All players involved figure out what to work on next and how to best organize as from the next Sprint.
  5. Repeat.

Although crucial to optimize the benefits realized, observation shows how difficult it is to keep Scrum cohesive. There are no practices that can be left out or cut out without harmfully breaking the cohesion (covering up dysfunctions or other ways of undermining important benefits). There is no such thing as individual Scrum practices.

Observation shows how difficult it is to keep Scrum lightweight and nimble. There is no need to aggravate Scrum. The “And” in “ScrumAnd” is not the next excuse to stack practices, rules or roles on top of Scrum. Instead, Scrum can wrap many practices, as tactics to apply the overarching rules, principles and values. Such are inclusive practices. Inclusive practices are needed and even make out a specific manifestation of Scrum. When inclusive practices are applied well, cohesion is preserved in the resultant system that is still recognizably… Scrum. “ScrumAnd” is more about the overarching rules, principles and values of Scrum, than it is about inclusive practices.

“ScrumAnd” starts, and ends, with Scrum. Many roles and domains exist that may not be covered by Scrum, for which Scrum has no rules, events and artefacts in place. Practices in such domains can help an organization get more out of Scrum. They are complementary practices. Complementary practices don’t change your manifestation of Scrum. The “And” in “ScrumAnd” is not about complementary practices.

“ScrumAnd” supports thinking about how to get more out of Scrum, how to be more effective in employing Scrum, and gain agility.

The syntax of “ScrumAnd” -if any- might look like:

Illustrations of “ScrumAnd”:

  • “YES, we have a Product Owner,
    AND a dedicated, full-time Product Owner, acting from a business perspective, with a mandate, and clear decision authority increases our agility in terms of customer proximity.”
  • “YES, we have a Product Backlog,
    AND going from using it merely as an inventory of exhaustive specifications to experiencing it as a collaborative instrument that helps us focus on what is really important and valuable increases our agility in terms of our ability to deal with unpredictability.”
  • “YES, we have a definition of Done,
    AND expanding it beyond producing only coded, tested or even integrated work to creating releasable and valuable Increments increases our agility in terms of our ability to deliver actual value (and close the feedback loop with the customer base).”

The illustrations of “ScrumAnd” are just that, illustrations, representations of what might work, like some earlier illustrations. There are no universal definitions, labels or boundaries, not within an individual “ScrumAnd”, nor across several of them.

And then complexity comes into play.

“ScrumAnd” illustrations can be created for all elements of the Scrum framework. The implied “ScrumAnd” stance shifts the mind to the exploration of options and possibilities, patterns of improvements, away from the frame (Scrum) or obstacles only.

And then complexity comes into play. There is a “ScrumAnd” in understanding and employing “ScrumAnd”. “ScrumAnd” is not for judging or assessing, it is more than a simplistic model of linear progression, more than phases, maturity or other levels. Inspection without adaptation is pointless anyhow, to start with. Despite the possible creation of individual “ScrumAnd” representations, the topics they target are necessarily connected, matched, intertwined. They reinforce or diminish each other without clear cause-effect relationships.

Complexity kicks in even more. One “ScrumAnd” may not result in improved agility through Scrum. Improvement requires concurrency and comes in Increments too. Reversely, increased agility through Scrum cannot be attributed to one “ScrumAnd” alone. “ScrumAnd” abides by the sfumato principle, the reality that reality has layers and shades of gradual progression, shadows rather than cold delineations, monochromatic color areas and binary separations.

  • A PDF of this text is available for download
  • The “ScrumAnd” poster (PNG) is available for download

Le parole di Scrum (Italian version of the Scrum glossary)

I am excited to announce that Michael Forni is working on an Italian translation of my book “Scrum – A Pocket Guide”. We aim at releasing “Scrum – La Guida Tascabile” (working title) in 2018, hoping it brings value to many Italian Scrum practitioners.

I took the opportunity to revisit my original text (dating from 2013). It resulted in small revisions and an update to my Scrum Glossary. Michael and I hereby share the translation of the latter as “Le parole di Scrum“. We are more than happy to evaluate any suggestion you might have.

Note: in the translation process of the Scrum vocabulary and definitions, besides the obvious care in avoiding to change or alter the well-consolidated words of Scrum, we also considered the well-spread wording among the Agile community and the Italian version of the Scrum Guide.

Nota: per la traduzione della terminologia Scrum, ferma restando l’inopportunità di modificare o storpiare i consolidati sostantivi caratterizzanti del framework, si è tenuto in debito conto il lessico oramai d’uso comune tra i praticanti di Scrum, nonché le traduzioni delle varie versioni in italiano de “La Guida a Scrum”.

  • Daily Scrum (sost. m.): evento a cadenza giornaliera limitato nella durata (time-boxed) a non più di 15 minuti – o meno – necessario a ri-pianificare il lavoro di sviluppo durante uno Sprint. Questo evento serve al Development Team per condividere i progressi giornalieri, pianificare il lavoro delle 24 ore successive e per aggiornare lo Sprint Backlog di conseguenza.
  • Definizione di “Fatto” (Definition of Done): insieme di elementi attesi e qualità che un prodotto deve dimostrare di avere affinché lo rendano rilasciabile, ad esempio compatibile ad un eventuale rilascio agli utenti del prodotto.
  • Development Team: gruppo di persone responsabili di organizzare e realizzare tutto il lavoro di sviluppo incrementale necessario per creare un Incremento rilasciabile non più tardi del termine di uno Sprint.
  • Durata dello Sprint: Durata, limitata nel tempo (time-box), di uno Sprint. Può essere di massimo 4 settimane o inferiore.
  • Emersione (Emergence): processo che porta alla luce o mette in risalto elementi non previsti, oppure la conoscenza di un fatto non precedentemente noto o diventato visibile inaspettatamente.
  • Empirismo: tipo di controllo dei processi nel quale le decisioni sono basate sull’osservazione di risultati, esperienze e sperimentazione. L’empirismo prevede di implementare ispezioni ed adeguamenti regolari, basati sulla trasparenza che, così facendo, viene ulteriormente rafforzata. È anche noto come “controllo empirico dei processi”.
  • Grafico “Burn-down”: rappresentazione grafica che mostra la progressiva e cumulativa diminuzione del lavoro rimanente rispetto al tempo.
  • Grafico “Burn-up”: rappresentazione grafica che mostra l’aumento di un parametro (ad esempio il valore) rispetto al tempo.
  • Impedimento: Qualunque intralcio o ostacolo che blocca o rallenta il lavoro del Development Team e che non può essere risolto attraverso l’auto organizzazione del Development Team. Deve essere segnalato non più tardi del primo Daily Scrum disponibile. Lo Scrum Master é responsabile della sua rimozione.
  • Incremento: set di lavoro potenzialmente utilizzabile che si aggiunge agli Incrementi precedentemente creati e coi quali forma – nell’insieme – un prodotto.
  • Previsione (Forecast): anticipazione di un trend futuro basato sull’osservazione del passato. Tipicamente selezione di determinate parti di Product Backlog ritenute consegnabili durante lo Sprint corrente o in quelli futuri, anche in relazione al Product Backlog futuro.
  • Product Backlog (sost. m.): elenco ordinato sempre in evoluzione di tutto quanto è ritenuto necessario dal Product Owner per poter creare, consegnare, manutenere e sostenere un prodotto.
  • Product Owner (sost f./m.): persona responsabile dell’ottimizzazione del valore espresso da un prodotto, attraverso la gestione incrementale del Product Backlog, nonché l’esplicitazione di tutte le aspettative e idee in esso contenute; referente unico dello Scrum Team verso tutti gli Stakeholders.
  • Affinamento (Refinement) del Product Backlog: attività portata avanti con continuità  durante lo Sprint, attraverso la quale Product Owner e membri del Development Team aggiungono granularità al Product Backlog, in continua evoluzione potenziale.
  • Scrum (sost. m.): (1) framework semplice per il rilascio di prodotti complessi; (2) framework semplice per la gestione di problemi complessi.
  • Scrum Master (sost f./m.): persona responsabile di favorire e sostenere un contesto Scrum attraverso attività di guida, addestramento, insegnamento e facilitazione di uno o più Scrum Team, nonché del loro sviluppo nella comprensione e corretto utilizzo di Scrum.
  • Scrum Team: combinazione delle responsabilità in capo a Product Owner, Development Team e Scrum Master.
  • Sprint (sost. m.): evento della durata massima di 4 settimane o meno, che funge da contenitore di tutti gli altri eventi Scrum. Punta a realizzare un sufficiente ammontare di lavoro, assicurando regolari ispezioni, riflessioni e adattamento a livello di prodotto e di strategie. Gli unici altri eventi ammessi in Scrum sono: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
  • Sprint Backlog (sost. m.): visione d’insieme – materializzata in varie forme ed in continua evoluzione – di tutte le attività selezionate dal Product Backlog da parte le Development Team e relative allo sviluppo necessario alla realizzazione dello Sprint goal.
  • Sprint Goal (sost. m.): affermazione sintetica che esprime l’obiettivo generale di uno Sprint.
  • Sprint Planning (sost. m.): evento della durata massima di 8 ore o più breve, che segna l’inizio del nuovo Sprint. L’evento è funzionale allo Scrum Team per ispezionare gli elementi del Product Backlog ritenuti in quel momento di maggior valore, nonché per determinarne la pianificazione all’interno di uno Sprint Backlog tenendo in considerazione lo Sprint Goal generale.
  • Sprint Retrospective (sost. f.): evento della durata massima di 3 ore o più breve, che segna il termine dello Sprint; l’evento è funzionale all’ispezione – da parte di tutti i membri dello Scrum Team – dello Sprint che si sta per concludere, nonché per decidere come lavorare nello Sprint successivo.
  • Sprint Review (sost. f.): evento della durata massima di 4 ore o più breve, che segna il termine dello sviluppo relativo allo Sprint. L’evento è funzionale all’ispezione – da parte dello Scrum Team e degli Stakeholders – dell’Incremento, del progresso generale e dei cambiamenti strategici, per permettere al Product Owner di aggiornare il Product Backlog.
  • Stakeholder (sost. f. / m.): persona esterna allo Scrum Team 1) portatrice di specifiche conoscenza e/o 2) rappresentante di un interesse per un prodotto, necessari per l’ulteriore evoluzione del prodotto.
  • Standard di sviluppo: l’insieme di standard e pratiche che un Development Team identifica come necessarie per creare Incrementi di prodotto potenzialmente rilasciabili non oltre il termine dello Sprint.
  • Time-box (sost. f.): contenitore temporale limitato, caratterizzato da una durata massima e potenzialmente fissa. In Scrum tutti gli eventi sono caratterizzati da una durata massima, ad eccezione dello Sprint, che ha una durata fissa.
  • Valori di Scrum: set di 5 valori e qualità fondamentali il framework Scrum: impegno, focalizzazione, apertura, rispetto e coraggio.
  • Velocity (sost. f.): indicatore molto diffuso che misura l’ammontare medio di Product Backlog trasformato in un Incremento, potenzialmente rilasciabile durante uno Sprint da parte di uno specifico (o dalla composizione di uno) Scrum Team. La Velocity rappresenta essenzialmente un utile supporto alla previsione del lavoro rilasciabile (forecast) a disposizione del Development Team, parte di uno Scrum Team.

On a personal note I want to share that I regularly get requests or suggestions for translations. Few get to the point of actually starting. I thank Michael for his commitment and wish him the persistence it takes for such a hard and complex endeavor. Rather than making a simple word-by-word translation, it involves adaptations, interpretations and redirections requiring affinities in English, Italian and Scrum​.​ This is far from trivial.