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)

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:


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


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

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

Scrum Vocabulary (updated)

Driven by the prospect of an Italian translation of my book “Scrum – A Pocket Guide” I decided to revise it slightly; minor tweaks of words and terms, although a lot of them.

As part of my revision, I also updated the Scrum Vocabulary of my book:

  • Burn-down Chart: a chart showing the decrease of remaining work against time.
  • Burn-up Chart: a chart showing the increase of a parameter, e.g. value, against time.
  • Daily Scrum: a daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves for the Development Team to share the daily progress, plan the work for the next 24 hours and update Sprint Backlog accordingly.
  • Definition of Done: a set of expectations and qualities that a product must exhibit to make it fit for a release in production.
  • Development standards: the set of standards and practices that a Development Team identifies as needed to create releasable Increments of product no later than by the end of a Sprint.
  • Development Team: the group of people accountable for all incremental development work needed to create a releasable Increment no later than by the end of a Sprint.
  • Emergence: the process of the coming into existence or prominence of unforeseen facts or knowledge of a fact, a previously unknown fact, or knowledge of a fact becoming visible unexpectedly.
  • Empiricism: the process control type in which decisions are based on observed results, experience and experimentation. Empiricism implements regular inspections and adaptations requiring and creating transparency. Also referred to as ’empirical process control’.
  • Forecast: the anticipation of a future trend based on observations of the past, like the selection of Product Backlog people believe they can deliver in a Sprint or in future Sprints for future Product Backlog.
  • Increment: a candidate of releasable work that adds to previously created Increments, and – as a whole – forms a product.
  • Product Backlog: an ordered, evolving list of all work deemed necessary by the Product Owner to create, maintain and sustain a product.
  • Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Team add granularity to future Product Backlog.
  • Product Owner: the person accountable for optimising the value a product delivers by incrementally managing and expressing all product expectations and ideas in a Product Backlog; the single representative of all stakeholders.
  • Scrum (n): a simple framework for complex product delivery (1); a simple framework for complex problem management (2).
  • Scrum Master: the person accountable for fostering an environment of Scrum by guiding, coaching, teaching and facilitating one or more Scrum Teams and their environment in understanding and employing Scrum.
  • Scrum Team: the combined roles of Product Owner, Development Team and Scrum Master.
  • Scrum Values: a set of 5 fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
  • Sprint: an event that serves as a container for the other Scrum events, time-boxed to 4 weeks or less. The event serves getting a sufficient amount of work done, while ensuring timely inspection, reflection and adaptation at a product and strategic level. The other Scrum events are Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
  • Sprint Backlog: an evolving overview of the development deemed necessary to realize a Sprint’s goal.
  • Sprint Goal: a concise statement expressing the overarching purpose of a Sprint.
  • Sprint Planning: an event marking the start of a Sprint, time-boxed to 8 hours or less. The event serves for the Scrum Team to inspect the Product Backlog considered most valuable and design that forecast into an initial Sprint backlog against an overarching Sprint Goal.
  • Sprint Retrospective: an event marking the closing of a Sprint, time-boxed to 3 hours or less. The event serves for the Scrum Team to inspect the past Sprint and establish the way of working for the next Sprint.
  • Sprint Review: an event marking the closing of the development of a Sprint, time-boxed to 4 hours or less. The event serves for the Scrum Team and the stakeholders to inspect the Increment, the overall progress and strategic changes in order to allow the Product Owner to update the Product Backlog.
  • Stakeholder: a person external to the Scrum Team with a specific interest in or knowledge of a product that is required for the further incremental evolution of the product.
  • Time-box: a container in time of a maximum duration, potentially a fixed duration. In Scrum all events have a maximum duration only, except for the Sprint itself which has a fixed duration.
  • Velocity: popular indication of the average amount of Product Backlog turned into an Increment of releasable product during a Sprint by a specific (composition of a) Scrum Team. Serves as an aid for the Development Team of the Scrum Team to forecast future Sprints.

I look forward to the Italian version seeing the light of day in 2018. I translated my book (2013) to Dutch in 2016 as “Scrum Wegwijzer“. It was published in German as “Scrum Taschenbuch” (translated by Peter Goetz and Uwe Schirmer) in 2017.

You can still find the Scrum Glossary of those editions on my blog.

The T-Shape Deception

I have never worked with a single person who mastered no more than a single skill. Every individual I worked with had the intrinsic capability to perform in more than one type of work. Every individual I worked with had the intrinsic ability to join forces with people that master other areas of expertise.

Every individual is naturally T-shaped. Ultimately, people can unite to form collectively T-shaped eco-systems, entities, often teams.

I have never worked with a single person who mastered every possible skill needed to perform any type of work that might arise when dealing with complex challenges. The demand for people to be able to do just that, is absurd. Yet, it is how the T-shape metaphor is abused. The idea that a cross-functional entity can only be composed of fully cross-functional individuals.

Every individual is naturally T-shaped. People are impeded or blocked from employing their intrinsic T-potential rather than being unwilling to do so. Common causes are function descriptions, hierarchy, systems, structures, procedures, instructions, incentives, rewards and other HR processes, enterprise career pressure.

The message that external forces need to mould people into T-shapes is an
expression of distrust and disbelief in the potential of people. People are not resources or an assembly of ‘skill’ parts. People don’t need to be deconstructed, disassembled, reconstructed or amended for any preferred shape, like parts forged to fit a pre-empted construction. Systemic impediments need to be removed that prevent people from exploring and discovering their needs and interests, from growing their talents and potential.

Rather than judging people for the expertise they (don’t) demonstrate, focus on creating a context, an environment in which people can unleash their motivation and their multi-skilled potential. An environment where people can bring in their multi-skills and expertise to leverage a cross-functional and multi-skilled entity (like contributing to T-shaping a team). In the end, problems in the Complex Novelty space go beyond any individual’s problem-solving capabilities, T-shaped or not. They need T-shaped teams and eco-systems to be an integral part of. And -ultimately- a context in which cross-fertilisation happens; people extending their skill sets through peer collaboration and peer learning.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(Principle #5 from the Agile Manifesto)

The purpose of the Scrum framework is to establish essential boundaries of such an environment of self-organization and intrinsic motivation thriving on the professional drive of people to create excellent products. Scrum Master, as a modern manager, is accountable for fostering such an environment of Scrum. A safe environment where people can demonstrate traditionally unsafe behavior, like going beyond the limitations of their function descriptions.