Posted on 1 Comment

Rocks moved (small or big) in 2021 (besides other accomplishments)

Life isn’t about finding yourself.
Life is about creating yourself.

What have I been up to in 2021?

Next to spending time on running my one-person company Ullizee-Inc (always more time than expected and hoped for), I feel gratified for having facilitated the learning process of 300+ people in various courses and workshops. In 25+ speaking engagements I have tried to share ideas and observations regarding different aspects of Scrum (check out my YouTube channel for recorded sessions).

Besides those ‘regular’ activities at least a few rocks got moved (small or big):

  • Creating a dedicated website for my Scrum Glossary (with translations in 25 languages);
  • Creating a dedicated website for the Scrum Values (with translations in 25 languages);
  • Publication of the 3rd edition of my bookScrum – A Pocket Guide“;
  • Creating and facilitating various sessions of my new workshop “The value in the Scrum Values”;
  • Creating and distributing a “Certificate of Gratitude” to all people having attended my courses or workshops in 2021.

Overall and despite these accomplishments, it’s been a more than challenging year as an independent Scrum Caretaker. Yet, I look forward to 2022 and uncovering more and more diverse ways to humanize the workplace with Scrum. It is my North Star, my infinite game. What is yours?

With love

Posted on 2 Comments

Product Owner. Not the Agile name for project manager, requirements engineer or other outdated functions.

The Product Owner in Scrum is accountable for the value delivered. Besides the fact that value is a very different driver than volume is (think outcome versus output), that accountability can hardly be demonstrated without a clearly identified ‘product’. Product is the vehicle to deliver value. Neither can a Product Owner be accountable and effective without a mandate to make decisions. Product Owner accountability cannot be mapped on existing roles or functions, nor can it be effectively enacted through deliverables and meetings dating from the industrial paradigm.

Although ‘product’ determines the scope, span and depth of Scrum, it is one of the most ignored considerations when Scrum is introduced. Organizations often introduce Scrum by constructing teams within existing departments and silo structures. The ‘Product Backlogs’ that they work off may be fascinating collections of work, but they are rarely for a…product. But how can you then know what the Product Owner actually owns? What purpose serves Product Backlog if not the single source of work to optimize for the value that a product delivers? What is it that releasable Increments are being created of when not of a well-defined product?

Without a clearly identified ‘product’ optimizing for value is hardly possible and Scrum is hardly used effectively.

When teams work within the confines of a traditional line organization, the highest achievable definition of product is often a part of a system, a component, a module or ‘something’ to be shipped tosomeone’. Teams deliver work to other teams that in turn combine it with their work or the parts of the system, components or modules they produce. And other teams again depend on the work to be received from them. As the different teams often operate under different line management, it ends up with nobody minding the synergies across them, with nobody minding the actual product and the value delivered to end-users, with nobody minding how poorly Scrum is organized and employed. One might wonder where the courageous Scrum Masters have gone but in the end the effective use of Scrum is impeded by mapping it to the old delivery structures to keep producing the same parts and modules for the same sub-products in a series of open-loop systems rather than thriving on closed-loop feedback control.

The challenge is to know your product or service so you can start organizing your Scrum to best serve the people consuming it and the organization funding its development, while increasing the sense of accomplishment for the people performing the work!

After knowing the product, the mandate and autonomy of the Product Owner is the next tactical challenge to tackle. Is your Product Owner the best placed person to make business decisions or is your Product Owner a proxy, a distant representative, a temp like a project manager or some other intermediary? Are the decisions by your Product Owner fully supported or does your Product Owner have to check in with managers, directors or the steering committee before making a decision? Any decision?

Regardless, the minimal purpose of the Product Owner role in the Scrum framework is to inject and uphold the business perspective in the product development work. The Product Owner connects the worlds of (1) product management and the business side of the organization (think market research, sales, finance, legal, marketing), (2) the user and consumer base and (3) the delivery or development parts of the organization.

Connecting those worlds includes engaging with them to assure that all product management aspects and the wider business perspective are integrated into the actual development. In the other direction it allows the Product Owner to keep stakeholders and product management people up to date on the actual progress, so they can organize or re-organize their work accordingly. Being a connector is not the same as being a bottleneck. Product Owner, not information barrier.

Regardless, the Product Owner is the one person making the final call on the order of the work in the Product Backlog. Product Backlog shows all the work currently envisioned for the product, all work that potentially increases the value that the product delivers. Smart Product Owners show openness for great ideas whatever their source or origin and they gracefully employ skills of development people to convert product ideas and business solutions into requirements. Product Owner, not product dictator.

The Product Owner manages Product Backlog based on the product vision as a longer-term view of the road ahead. A product vision captures why the product is being built and why the product is worthwhile investing in. A product vision helps the Product Owner set or reset specific goals, hopes and dreams, express the expectations and ideas captured in the Product Backlog better and better order the items in the Product Backlog for value.

If anybody wants to know what work is identified and planned for the product, it suffices to look at the Product Backlog, at one artifact only. To understand what is planned for or what is in the product, and why, it suffices to ask the Product Owner, one person only.

Sprint Review is a great opportunity for a Product Owner to learn about the assumed or actual value that the product delivers. At the Sprint Review, (key) stakeholders, the team and (potentially) consumers or (key) users collaborate over what got done and what didn’t get done, what influenced the work and what was the purpose of that work. But value as the overall purpose is a very different driver than volume is. The purpose of Sprint Review is not reporting or justification of the amount of tasks executed and features implemented but sharing relevant information on usage and impact, competition and market trends; feedback that will help optimizing for value in the next Sprint(s). The goal is to collaboratively identify what is the most valuable work to do next for the product. This is evidently captured in the living artifact that Product Backlog is.

There cannot be any doubt that being a Product Owner implies expectations, skills and traits that go beyond those of a traditional requirements engineer, a requirements provider throwing work over the wall to developers or a similar proxy. Product Owner, actually, owns the product and is the owner of the product. Such ownership of a product implies strong organizational adoption of the role. It allows a Product Owner to act like a product-CEO (again, not a product dictator). That accountability cannot be mapped on existing roles or functions, deliverables and meetings. The role simply did not exist in the industrial paradigm.

Note. This article is based on texts that are taken from my current book-in-progress “The House of Scrum” (to be released in 2021).

Posted on 1 Comment

My life of Scrum (did not start with Scrum)

October 1995. After a few years of searching and experimenting, “Scrum” was documented and presented to the general public.

October 2020. Scrum turns 25. Hip hip hooray! I record a few highlights of “My life of Scrum”, a few aspects from the past 17 years of the life of an independent Scrum Caretaker.

September 2003. The founding managers of the company that employs me, ask me to have a look at the challenge of delivering the core server platform for a digital television implementation (one of the first in Europe at a bigger scale). Due to delayed negotiations, the project is already late and the real work hasn’t even started. Two software architects give me a 15-minutes introduction of eXtreme Programming. I fall for it. Completely. The urgency and feeling of crisis is also such that we are allowed to start applying it. We throw away all existing plans, create an ordered pile of User Stories, get together a great gang of developers, and go to work in iterations of 3 weeks. Later, we add Scrum to our approach. Scrum cannot be applied effectively without clear and agreed development practices and standards in place.

May 2004. I attend a CSM class (“Certified ScrumMaster”) by Ken Schwaber. It turns out the first CSM class in the region (Belgium, Netherlands). We join with 5 people from our organization. There are 25 people in total. We need to pay in cash. In my memory it was a 3-days class. Although that is said to be impossible, in my memory it still is. I am not to be trusted in such things. I don’t care about titles, positions, certifications, career. I don’t keep up with all the certifications being created, but just practice Scrum with different teams, in different domains, for the next 7 years.

December 2010. I attend a PSM class (“Professional Scrum Master”) by Ken Schwaber as part of my journey towards obtaining a license as a Professional Scrum Trainer. I also start working full-time in the Netherlands: helping, assisting, coaching, guiding, and advising large organizations on their journey of adopting Scrum. I could not have done so without the 7 years of practice that preceded this phase of my professional life. I would have not had the firm foundation to stand my ground. Some things take time. More dots get connected as I engage in a partnership with Ken and from 2013-2016, and as I continue my journey afterwards as an independent Scrum Caretaker.

Posted on 6 Comments

Surprise. I am no wizard. Agile nor Scrum.

I regularly get inquiries from people reaching out for instructions, assistance, or other forms of guidance to learn about Scrum, pass exams, become a trainer, or advance their career towards “Agile coach”.
Surprise. I am no wizard. I do not have the magical powers that would be required.

I really don’t want to go into people’s motivation to approach me with those desires (‘free’ seems to be a recurring theme), but I can share my personal and professional stance and considerations.

(1) Honestly, I don’t know what an “Agile Coach” is or does. Not even attending a “Coaching Stance” class by the Agile Coaching Institute in 2012 has helped me in that regard. The same goes for having worked with many people holding the title. I have never called myself that and I have never used the label in my profile, CV, or service offerings, let alone that I would have the powers to turn somebody into it.

Looking back on the 16+ years that have passed since I started applying the powerful combination of Scrum and eXtreme Programming in 2003, I realize I only ‘had’ to start thinking about and explaining what ‘Agile’ might mean, or what an “Agile Coach” is, since 2010-2011 (7 years later). I don’t think it is a coincidence that this is when I started engaging with large companies and the wave of ‘scale’ sweeping my world, the time when ‘Agile’ became a corporate thing. I still can’t clearly explain what an “Agile Coach” is or does.

(2) I have always been and am still all about Scrum. It makes transparent what I stand for, it makes tangible and actionable the services I offer and bring, and it includes plenty of room and openness for contextual customizations. As Scrum is an open framework, an organization can standardize on Scrum and substantially increase their agility without industrializing their Scrum to death.

The continuous balancing act of a Scrum Master, including the coaching aspect

(3) I don’t create them for that reason, but I am humbled when people say my writings (books, articles, papers) or my classes were useful in achieving a certification, in becoming a trainer, or in passing some other milestone. I am comforted knowing that those individuals did the actual work. They might have gotten some insights and language from me, but that’s about it. I did not hold their pen or control their brain. It is likely that they struggled, fell, got back up, failed, tried again. Maybe along the road they took a break, read more, gained more experience with Scrum, and demonstrated other forms of patience, persistence, and belief.

The many requests from people that seem to believe that I can ‘make’ them a trainer or ‘make’ them achieve a certification leave me flabbergasted. Surprise. I CANNOT. And even if I could, I wouldn’t. It would not be helpful for the requestor’s autonomy and development.
I don’t know whether it has anything to do with the current covid-crisis sweeping the planet, but I worry seriously how this seems an obsession for quite some people.

On a personal note, I want to share that my journey of Scrum started in 2003. And I spent 7 years (seven!) of just applying Scrum, and enjoying how it helped deliver great results, make users and consumers happy, and observe highly engaged teams enjoying their work. During that time, I had no idea about certifications, grades, or career moves, and I can honestly say that I couldn’t care less. It was only by accident in 2010-2011 that I became what I didn’t know I wanted to be. Looking back it still feels odd. Although it may look as if there was a plan, there wasn’t.

Even after more than 16 years of this stuff, I am no expert. Nor am I tired of Scrum. Not even close. I am an eternal novice. There is so much to learn. There are so many ways to consider and explain Scrum, even having published two books and considering two more books as we speak.

I welcome everybody to join my classes or workshops to find out how I express Scrum, or attend the many events and webinars I participate in, check out my YouTube channel, hire me for some consulting and coaching. I will do my best to help you understand Scrum, its purpose and design, how to get the most out of it, and learn to think for yourself in terms of Scrum. Regardless of how much I care however, I cannot ‘make’ anyone a trainer, a Scrum Master, Product Owner, or “Agile Coach”. I cannot ‘make’ anyone pass some certification assessment or exam. That is not in my powers (if even that would be helpful). I am no wizard. I have no magic, some empathy at most.

And, like it or not, the primary source of learning about Scrum is from practice, from doing Scrum. It is the way to learn Scrum, beyond learning about Scrum. There is a huge difference.

Yours truly
independent Scrum Caretaker

Posted on

“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
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


Posted on 2 Comments


I have been employed by different enterprises, large and small. I never had the ambition to be a wild duck 🦆, though I typically ended up being seen, treated and described as one anyhow. How strange as I am someone who habitually avoids rather than looks for conflict. How strange to always end up being the person that the powers that be would love to hate, but can’t get beyond ignoring. It is hardly comforting that most instances only get to the stage of tolerating me while ignoring me.

There is no having friends for those not having enemies.

Wild ducks are “bad for business,” say the powers that be, enthusiastically supported by the business suits, the career hunters, the position addicts. Yet, every time I decided to leave an enterprise the drama couldn’t have been bigger. How strange that it was even worse “for business” that I would leave. Honestly, the expected disasters never actually materialized. No company ever went out of business over this maverick duck flying off.

Although I know a few people that prefer calling me a Scrum panda 🐼, wilfully choosing the path of independent Scrum Caretaker ultimately lead to me feeling more like a butterfly 🦋 today. Like a butterfly, I flap my wings. I observe, I create, I connect, I share. Like a butterfly flapping its wings I do it because it is in my nature, not because I envision specific consequences, big or small, or set goals or targets, hard or soft. Most consequences are inherently unpredictable anyhow.

More than often I see how my ideas get used and re-used without consultation, citing or other forms of attribution. I am flabbergasted by it. Likely unintended (people not thinking twice), but there is a smell of disrespect. Much worse is it when my ideas are altered, turned simplistic, changed into stereotypes, their sfumato masked and concealed in black and white boxes, when concepts are twisted, cut up, even butchered. That is… theft. No words can describe my emotions over this.

Regardless the lost art of attribution and the hurt it causes, I keep flapping my wings. Observing, creating, connecting, and sharing is in my nature. It makes no sense for a butterfly to stop flapping (or even try to). I’m not sure how that is for a wild duck.

It took time to realize, accept and embrace that most things take time, especially creating who you are. Is the tortoise 🐢 in me gradually taking control?

The toughest fight in life in the end is the fight of not having to turn bitter.

(Louis Paul Boon – “My little war,” 1947)

Posted on Leave a comment


At some point in time the term “Framework” became really fashionable. I don’t remember when it was exactly, but it was when smart businessmen assumed it was better for sales, as commonly used terms like methodology or process got burned. At least, that can be seen as an achievement too. Most likely they guessed it explained the wide adoption of Scrum, and aspired the same ’success’.

Today, the word is omnipresent and can surely be added to the list of most misunderstood words in the world of “Agile”. That does not change the fact that we did not start using the word lightly in the past. It was not about marketing or selling. It was about sincerely describing the lightweight nature of Scrum, as a simple set of rules, principles and values that define a framework for inspection and adaptation, a way for people to address complex challenges.

Regardless of fashion of the day and obfuscation, this is not a term to leave to the sharks. Language matters. Scrum is a framework, not a methodology, as I described in 2013 and in my book “Scrum – A Pocket Guide”.

Posted on 4 Comments

The international versions of the Scrum Values (September 2018)

In May 2013 I described how there is value in the Scrum Values. I included that text in my book “Scrum – A Pocket Guide” that was published in November 2013. Early in 2018 I updated my description slightly to be included in a revision of my book that I anticipate. A group of Scrum enthusiasts subsequently translated that updated version to different languages.

The last incremental update of the September 2018 release of the international versions of the Scrum Values is now available, as a free download (PDF): The Scrum Values (international versions) -September 2018 (R3).

Early in September following new languages were released as a new baseline version: Filipino-Tagalog, Indian-Hindi, Polish, and Spanish. Throughout September we went into a continuous delivery mode and released additional languages as they became available: Persian, Arabic, and Danish.

A poster of the international versions of the Scrum Values is available as a free download (PNG): The Scrum Values (International Versions poster).

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

  • Arabic: Rasheed Raya.
  • Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia.
  • Danish: Mikkel Toudal Kristiansen.
  • Filipino: Shirley Santiago, Warren Yu.
  • French: Fabio Panzavolta, Mohamed Gargouri.
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini.
  • Hindi: Punit Doshi, Hiren Doshi, Nagesh Sharma.
  • Italian: Michael F. Forni.
  • Persian: Mehdi Hoseini.
  • Polish: Krystian Kaczor.
  • Portuguese: Leonardo Bittencourt.
  • Russian: Konstantin Razumovsky.
  • Spanish: Pablo Bernardo.
  • Turkish: ilkay Polat, Lemi Orhan Ergin.

In the document you will also find my Dutch translation. I maintain the base English version on the Scrum Values section of my website.

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

Warm regards

Posted on Leave a comment

Scrum Glossary (International Versions, April 2018)

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. A first release of those international versions was done in March 2018.

The new, April 2018, release of the international versions is now available, as a free download (PDF): Scrum Glossary (International versions) -April 2018

  • Four new languages were added: Filipino-Tagalog, French, Indian-Hindi, Turkish.
  • The definition for “Definition of Done” was rephrased.
  • A definition for “Product” was added.

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
  • Filipino: Shirley Santiago, Warren Yu
  • French: Fabio Panzavolta, Mohamed Gargouri
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini
  • Hindi: Punit Doshi, Hiren Doshi
  • Italian: Michael F. Forni
  • Polish: Paweł Feliński
  • Portuguese: Leonardo Bittencourt
  • Russian: Konstantin Razumovsky
  • Spanish: Alex Ballarin
  • Turkish: Ilkay Polat, Lemi Orhan Ergin

In the document you will also find my Dutch translation. I maintain the base English version on the Scrum Glossary section of my website.

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

Warm regards