Systems Thinking, Episode #2: Complex Adaptive Systems

In my previous episodes of this series on Systems Thinking, I elaborated on what systems Thinking is and on the Wicked Problems Systems Thinking is trying to solve. In this episode, I want to explore Complex Adaptive Systems (CAS).

In Systems Thinking, we observe different types of systems.  There are static systems like cars and complex systems like people for instance. Opposed to static systems, complex systems behave differently under different stimuli. A car’s emergent behaviour Continue reading

How to facilitate multi-team Product Backlog Refinements

Before and during the Sprint, effort needs to be put into coordination to ensure the Scrum teams deliver a working integrated product. This situation can be improved with Multi-team Product Backlog Refinement sessions. This practice increases flexibility and speed in product development. Use this article as a cookbook to get familiar with this practice yourself. Continue reading

Six ingredients of agile organizational design

Agile businessIn this article, I want to clarify the need for agility in modern businesses and what agility in organisational design is.

Today’s mainstream organisation structures are systems we inherited from the industrial era when employees were illiterate and the leaders were educated, market-entry criteria were high and markets were predictable. We see that the future of many established businesses has become uncertain. Businesses need to exceed customer expectations in buyer-driven markets. Customisation is the norm and copying a competitive advantage has never been easier. Innovations and changes supersede at an increasingly high pace. For example, in the financial sector, many disruptors enter the market. These newcomers do not carry the burden of legacy IT systems and can offer new services at the flick of a switch. They put pressure on the existing businesses. Continue reading

Systems Thinking, Episode #1 What are Wicked Problems and why should I care?

In a series of blog posts, I want to share how you can use Systems Thinking to resolve complex problems. Systems Thinking aims at understanding and possibly solving complex problems. In this episode, I will focus on complex adaptive problems, also known as “Wicked Problems”.

Wicked problems are very difficult problems that don’t seem to have a simple solution. They’re like an inextricable knot. When you’ve unraveled one thread of the problem, new problems keep popping up.  Continue reading

Hiring the Right SM or PO: Outcome based job interviews

A customer I was working with asked me to help out with the intake process for recruiting a new Scrum Master and a new Product Owner. I asked them what they had so far. They provided a clear job description describing what they wanted to see from the candidates. They also had a great business storyline describing their goals and ambitions and in what way these impact the people applying for the new roles. They planned two interview sessions and wondered what else could be done to increase the chances of finding the right person for the job. Continue reading

Iterating Towards Professional Scrum: Full Lecture (Agile Week Riga)

This video is a presentation from Agile Week Riga titled, Iterating Toward Professional Scrum. The 2019 Scrum Master Trends Report by and the State of Agile 2018 shows numbers that provide insight in the maturity of agile adoptions. More than 80% of the companies claim to be in or below a ‘still maturing’ level. With Scrum being the industry standard (at least in western Europe it is), these numbers are surprising. In this overview of iterations towards Scrum maturity, I describe the characteristics and main challenges to overcome in each maturity stage. Continue reading

How you can accelerate knowledge-transfer with cross-location MOB-programming

In a LeSS adoption the teams self-organised some time ago into end-to-end feature teams. Some of these teams need to find ways to share knowledge on a tool called PEGA. One of the PEGA experts approached us with the question on how to do this. We suggested to facilitate a session to introduce them to MOB-programming. After the session they should be able to do more mobbing by themselves if they think it was valuable. Continue reading

To fix your Scrum you need to fix your agreements.

In many organisations, I see Scrum not producing its anticipated value. The concept of value varies across organisations. But there also is a universal anticipated value of Scrum. The Scrum Guide says about Scrum’s purpose:

“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”


“Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.”

In summary: Scrum intends to deliver “Done” valuable products and provides continuous improvement.

Ask yourself how successful your Scrum in reaching those two objectives. Take a moment. I encourage you to do it now before reading on.

How successful is your Scrum?

Now that you made a judgement; Your “successful” is based on what? I see Scrum excel in fulfilling its promise everywhere. In many cases, Scrum is delivering on a promise that was not anticipated when adopting Scrum. People might expect Scrum to deliver twice the value in half the time. To their surprise, they experience Scrum as a framework that is difficult to implement and causing problems everywhere. Many organisations are not ready to cope with this harsh reality and cannot value the revealed problems as opportunities for learning and improving. Blaming Scrum for not working and creating workarounds for complex systemic problems instead of solving them is a realistic option to many. By consequence, teams will ultimately abandon Scrum in such environments.

Why are people showing this evasive behaviour? There are lots of reasons, but at the core I see a forgotten requirement for Scrum (or agility in general) standing out:

The agreement to work with Scrum

In many cases, I see agile transitions are inflicted on the people using command and control by management. People are told to work in Scrum teams and told to have their ceremonies by inexperienced Scrum Masters and ignorant management. It makes sense that organisations introduce change using practices they are accustomed to. But in the case of agility, this approach is destructive in the long run because enforced change never works.

Voluntary change always works

Everybody changes all the time in their personal lives. We might want to change cars, houses, jobs, and what not (spouses?). Voluntary changes never feel bad because we want them intrinsically and so we agree to them. But when someone tells you you will be transferred to a branch on the other side of the world, or to another team, it might no longer be fun because it was not your voluntary choice. What is more important: you did not agree to it. Change that is imposed upon us is not sustainable. Mandatory change never works. Craig Larman formulates this as “owning versus renting”: with involuntary change we do not own the change, we rent it.

Voluntary change is rooted in agreement

When we help people to reveal the dynamics of their system and then guide them to explore unknown territory to decide how to deal with these issues, the change will come from within and will be built upon the agreement that a change is needed. Using the same principles we can come to an agreement we should adopt Scrum. With this approach, people will own their change towards Scrum instead of renting it.

In situations where you will be scaling Scrum (which is the default), we should not forget the importance of the initial underlying agreement to the Scrum adoption. The first team that started a Scrum experiment had a strong conviction and team agreement to apply a new way of working. The people who will later be introduced to a new way of working need to voluntarily participate and share the underlying agreement for Scrum to make it work. With LeSS adoptions, voluntary participation is one of the framework’s three adoption principles. When you want to scale Scrum successfully, you also need to scale its agreement, or else your attempt to scale will fail, regardless of the scaling approach you choose.

Scaling Scrum requires scaling the agreement to work with Scrum

When we agree to adopt the Scrum framework, we agree to a large number of explicit and implicit agreements. Each and every one of these agreements is required to make scrum work. Understanding which agreement is not met and in what way it impacts you can help you to fix your Scrum.

Agreeing to work with Scrum means:

We agree to the Agile manifesto and its twelve principles.

The Agile manifesto is fundamental to Scrum. It should be known by all and understood by everybody in the team and in the whole organisation. Not understanding or knowing the Agile manifesto will allow for opposing beliefs and will create an environment where Scrum cannot be successful.

We agree that reality is too complex to be captured in a fixed set of requirements.

A complex environment cannot be captured in a finite list of requirements but needs adaptation to change to be incorporated. Not agreeing with this will lead to wasteful meetings trying to optimise and capture reality in endless designs, user stories, etc.

We agree we need to adopt empirical process control to deal with complexity.

We need to probe, assess and respond to be able to adapt to change. If we do not embrace empirical process control, we cannot use empirical data to pivot and refocus on the newly discovered reality. Reality cannot be captured in a finite list of requirements.

We agree to adapt as soon as possible.

As soon as we detect a problem, we fix it to minimise the possible damage. Postponing the change will allow for more waste to be produced. This is not in line with key Lean principles, being at the foundation of Scrum.

We agree on a common language referring to the process.

We need to use the correct wording for the roles, events and artefacts to be able to communicate effectively about our process. By doing so, incorrect language can be detected, by which incorrect beliefs and mental models can be detected. This is key to aligning everybody to adhere and understand our shared goal, values and vision.

We agree to honour commitment, courage, focus, openness and respect.

The Scrum values are key to create an environment where empiricism can be applied. Without living according to these values, we will not be able to transparently inspect and adapt:

  • If we are not courageous, no change will ever happen. If we are too courageous, we will not be respectful.
  • If we are not respectful, we will lose direction. If we are too respectful we do not challenge the status quo.
  • When we are not committed to Scrum empirical process control will fail. If we are too committed, we get tunnel vision and lose flexibility.
  • When we do not have a focus, we cannot finish things and share no goal. If there is too much focus we lose flexibility.
  • If we are not open, we cannot be transparent. If we are too open we will lose focus on what is important and create confusion.

We agree to trust each other.

Trust means safety. We need this to be able to start experiments and make mistakes so we can learn. Being open to making mistakes can only occur when we trust each other. The absence of trust will stop people from truly experimenting. They will entrench in defence mechanisms to prevent from being punished.

We agree to be transparent.

Without transparency, our adaptations will not be the right ones. We risk applying changes that will not contribute to delivering more value.

We agree to inspect frequently.

We inspect the people, the work, the process and the product continuously. If we do not agree to inspect, we can no longer empirically control our process.

We agree to improve continuously.

Kaizen needs to become a way of life. Without it, we will no longer adapt to our ever changing surrounding.

We agree to deliver a working product every sprint.

Scrum’s primary goal is to deliver a done increment every sprint. If we do not agree to pursue this goal, we lose the opportunity for inspection and adaptation and we introduce the risk of building the wrong thing.

We agree on the product definition and vision.

The product owner formulates and communicates a product definition and a product vision so that the Team members and the stakeholders understand it. The Scrum team also needs to support this vision and purpose. When development team members do not agree to the Product Owners vision, they do not respect the responsibilities adhered to that role. This will lead to wasteful discussions and will withhold the development team member from taking decisions autonomously.

We agree on a definition of done.

The primary purpose of Scrum is to deliver done every Sprint. Team members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team.

We agree to honour all time-boxes.

Parkinson’s law is at the basis of using time-boxes. If there is more time available, the more work will emerge to fill that time. Hence, limiting the time available will increase productivity. A common myth is that time boxes are interpreted as fixed meeting lengths. This is not true. A timebox sets a maximum amount of time available for an event. If it ends earlier, in most cases that is ok. By agreeing to honour time-boxes for the scrum events, we will learn to improve to make our work fit into these timeboxes and question ourselves what is wrong if we fail to do so. By doing so, we agree to let the empirical process control mechanism to show us what we need to improve. Example: we do not add a couple of days to the sprint to meet deadlines, we let the sprint end and investigate what was not finished and why this occurred. This inspection provides learning. Adjourning the sprint does not.

We agree that we can only make decisions based on what is known.

Predictive management fails. Management based on assumptions fails. We need to stay close to real data to base our decisions for altering our course. If we source our activities based on a prediction, we are excluding change to alter our plan, we become rigid and chances of delivering value degrade.

We agree that learning comes from experience.

Knowledge can be acquired by studying books. However, we agree that experiential learning is essential to Scrum: we need to learn by doing. This is because building theories on what might happen is not delivering true value. Actioning on an experiment and verifying its outcome does. Not agreeing on this excludes the need for setting up experiments for exploring and attempting to understand complexity.

We agree that there is a need for predictability towards the stakeholders.

Although we predict the future, data from the past performance can be used to see trends and forecast releases (with reasonable inaccuracy and possible increasing accuracy over time). Failing to agree this makes us operate in isolation and fail to understand that Scrum is only a means to an end: delivering value.

We agree that an iterative, incremental approach will increase predictability to control risk.

Pushing many small changes creates a faster feedback loop than pushing larger changes at a slower rate. When people continue adhering to the need for producing large changes we will end up in having lengthy discussions on architecture and spend lots of time o producing unvalidated specifications. Such activities can be considered to be wasteful because they do not maximise the amount of work not done.

We agree to deliver reproducible quality.

In order to deliver continuously, the Scrum team needs to find ways to organise themselves so that they can reproduce at least the same quality as in each previously delivered increment.

We agree to honour the separation of responsibilities of the Scrum roles.

Scrum separates the interest of business, technology and process across three distinct roles to create a healthy tension.

We agree to respect the mandate that is attributed to each Scrum role.

Everybody in the organisation needs to play according to the rules of the game of Scrum. In this game, each role needs to receive the mandate to execute their responsibilities, an act that is impossible if the surrounding organisation does not support and honour this attribution.

We agree to collaborate in teams.

Teams are the cornerstone for doing Scrum. Team performance is more important than the individual result. However, some people do not like to or are unable to work in teams. Without the agreement to collaborate in teams, these people will sabotage your attempts to build high performing teams.

We agree with the concept of self-organising empowered teams.

The whole organisation including the management needs to support the idea of handing over decision power related to the work to the people actually doing the work, as they know best what needs to be done and what needs to change to improve. Not supporting self-organisation or self-management will slow down adaptation and will be the source of frustration.

We agree to adhere to the optimal Scrum team size.

The minimal team size of 3 is set to reduce the “Bus factor”. Too little people in a team also makes it difficult to acquire the required knowledge to deliver done and grow Done over time. The maximum size of 9 is more fluid, but take into account the exponential rate of communication lines that quickly lead to communication overhead in larger teams. Learning more skills is a more interesting investment.

We agree that development team members need to be cross-functional.

In order to deliver done, a development team needs to be able to perform different types of work autonomously as a team. This will make the team flexible and offers flexibility to the organisation. This is an agreement that many team members find very difficult to accept. People tend to be hired for a certain skill and we tend to value specialists. However, having a bunch of very deep specialists in one team makes it difficult for the team to collaborate and deliver done. For Scrum to function, ie for a team to be able to deliver Done, team members need to understand and master more than just one skill. Failing to agree with this will create teams that operate in waterfall mode and will have a hard time becoming high performant.

If one of these agreements is not supported, what is the impact on empirical process control, transparency, or the ability to deliver done?

Do you see other agreements that need to be met? Then I invite you to add them to this list.

How you can keep Scrum positive

In Scrum, we know we will make things better through empiricism: We continuously inspect and adapt. However, over time it looks like the continuous improvement Kata loses its magical powers and becomes stale. Scrum Masters try to fix things by varying their retrospectives format, by introducing games and by introducing more creative problem-solving approaches like lateral thinking (Dr. E. de Bono) to get better improvement results. Continue reading

The only Thing We Have to Fear Is Fear Itself

(Inauguration speech of Franklin D. Roosevelt, president of USA during WWII)

A short story illustrating how fear cripples estimating and how empathy can come to the rescue.

The end of the year is only two sprints away. We are in a refinement session.
“So, would it still be feasible to deliver the ‘A+flow’ by the end of the year if we do it like this?” The PO asks the team. He is standing in front of a whiteboard full of scribbles holding a marker in his hand. He just gave in on reducing the scope by slicing the functionality even further to a point where he will be having difficulties to explain to the stakeholders what the value in this slice is. He even has difficulties explaining it to himself. Continue reading

Why you need only ONE Product Owner

Scrum prescribes one person in the role of Product Owner (PO). Not multiple people, not a committee, just one person:

“The Product Owner is the sole person responsible for managing the Product Backlog.” (Scrum guide)

And when multiple teams work on a single product, the Scrum Guide says:

“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.” (Scrum guide)

I encounter many companies that fail to implement this specific Scrum guideline. Apparently, according to most companies, this is one of those things you need to tweak “to make Scrum work in your context”. Continue reading

How to facilitate an awesome Sprint Review in “Bazaar mode”

This article aims at helping Scrum Masters to conduct the *MOST AWESOME* Sprint Review they ever witnessed. (This article could have been titled: 41 tips that will make your Sprint Review awesome!)

The main purpose of the Sprint Review (SR) is to collect feedback. After seriously inspecting the product, a number of changes to the backlog or action points for solving impediments should be identified.

Continue reading

The 8 qualities of the emotional Scrum Master

The Scrum Master profession spans a wide variety of skills, knowledge and experience. Scrum Masters try to create high performing teams and drive organisational change. Although we mainly focus on the framework and the process, it’s people we work with all the time. Surprisingly our profession focuses predominantly on developing cognitive intelligence (IQ). We need to learn to appreciate the value of emotional intelligence (EQ) for becoming a great Scrum Masters. Continue reading

The Feature Team Adoption Map Explained

When talking about LeSS adoptions, the Feature Team adoption map (FTAM) is often brought up as one of its powerful tools. Although FTAM is described in the LeSS book (1), and gets a great deal of attention in most LeSS practitioner classes, it plays a less important role in LeSS and LeSS Huge adoptions than we might suspect. However, it is a valuable tool that can be used for various purposes. Continue reading

The 5 Supporting Elements of Scrum

In Scrum classes we often ask the attendees to draw a picture of the Scrum framework, in order learn what their current understanding of the framework is. In many cases people are close to remembering the three roles, three artifacts and five events. But they also bring forward many related elements that are important or even indispensable to support the Scrum framework, but are not roles, artifacts nor events.

Continue reading

Definition of done: the Swiss army knife of Scrum

Most of the concepts in Scrum are easy to understand but extremely difficult to master. This is due to the fact that Scrum is designed for perfect, and reality never is. The same principle applies to the Definition of Done.When we start up teams, we help them to set a Definition of Done (DoD).

Teams are taught the DoD is an instrument that will provide them transparency in two ways:

  • understanding what the effort of work is, considering all the tasks that need to be undertaken by the team before work can be marked as “done”.
  • understanding what “done” means when an item is inspected at the end of the sprint.

Continue reading

Practice your micro-skills

Micro-skills are simple intervention techniques. When using micro-skills, you will facilitate sessions and have conversations that yield more effect and value. Using the micro-skills offers support in your facilitator or leadership role.

I have developed a workshop to train a set of 18 micro-skills. In this workshop, you will learn to consciously facilitate a discussion or an interview using micro-skills.

Workshop format

Continue reading

Conway’s law

I was going over the slides of the September LeSS conference and I was struck by the deck of Kevlin Henney. He was referring to an organizational structure that I never heard of. I have seen it before, I did not know it had a name and I was not aware that all existing classical org structures are actually wrong.

You are familiar with the classical tree:

Continue reading

Getting rid of fake PO’s.

LeSS adoption prescribes one person in the role of Product Owner (PO). Not multiple people, not a committee, just one person. Companies have a hard time in accepting the idea that one person can do this complex task for the whole product. The product is too big and there are too many customers and stakeholders the PO needs to deal with. Companies refuse to redefine the PO role description and stick to having multiple Fake PO’s. Continue reading

How can you make your team cross-functional?

Tash Sultana is a 22 year old musician. She is cross functional, a multi-instrumentalist producing fully arranged tracks live on stage.

My team consists of Frontenders, Backenders, a Tech Writer and a QA. I am their scrum master. They are working as a team for a while already. It’s a team in the sense that they work on the same sprint backlog, but they are not the team as you would see described in the Agile books: They are not cross functional.

Continue reading

I will be speaking at Eastern Europe Agile Convention


The Eastern European Agile convention will take place on april 7 and 8 in Kiev, Ukraine. 2476 International guests and 195 speakers.

Headlining this episode are:

  • Dave Snowden – Founder and Chief Scientific Officer of Cognitive Edge

  • Olaf Lewitz – Certified Enterprise Coach

  • Michael Sahota- Certified Enterprise Coach (CEC)

I am very honored and pleased that I am admitted to talk about:

Remote team facilitation and Scaled Scrum: How to make it work

Near-shoring introduces complexity in scrum teams. When we scale scrum, this complexity is amplified and drastically reduces meeting efficiency. Is there a silver bullet to make remote teams high-performant in a (scaled) scrum environment?

When facilitating agile workshops, you probably experienced the difficulties of keeping the remote participants involved. And maybe you also know how hard it is to facilitate a highly interactive session with more than 50 people? Or how much harder it gets when 10 of them are connected remotely? I learned time after time participants feel left out, not listened to or find it impossible to follow discussions. Your sessions, intended to boost productivity, demotivate your remote teams.

Join this talk if you are a facilitator working with one or more near-shore teams. I will share my day-to-day experiences and insights that will help you to involve your remote teams.

I hope you will join me in Kiev!

Read more about the event:

Clarifying roles

poroleUnclear or too many roles do not produce good scrum. Use this game to verify that the separation of concerns is implemented correctly or to prove the opposite.


This game is useful when you are in a scrum environment where the separation of roles is unclear.  It might be the case that there are more roles than prescribed by scrum, or that people are unaware of the responsibilities of each role.

Unclear or too many roles do not produce good scrum. Use this game to verify that the separation of concerns is implemented correctly or to prove the opposite. Continue reading

The Airbase game (learning the benefits of failing fast)

airbaseYour team develops and launches a new product in the market. The goal is to sell a new product for 50 euros to the customer. Your team works iteratively according to Scrum. Each iteration will cost 50 euros and the total budget is limited to 200 euros. The customer has a limited budget, which also fluctuates. The team that has the highest amount of money after running three sprints, wins the game.

Continue reading