Scrum Guide 2020, waterfall strikes back?

The new Scrum Guide has been released this week and I felt obliged to share my review of this document with you.

Link to the scrum guide here.

Changes between 2017 and 2020 Scrum Guides

They are 7 major changes:

  1. Less prescriptive …. which I challenge and disagree because of the wording
  2. One team, one Product is a good reminder
  3. Product Goal instead of Vision will lead to a lot more upfront thinking and analysis to define such a goal
  4. A Home for Sprint Goal, Definition of Done, and Product Goal: that’s a lot of goals, a lot of constraints ….I feel processes, controls here
  5. Self-Managing over Self-Organizing: that’s a very bad choice. Moves away from agile to more leanish and allows management to force reorg and developers have to comply and resiliently manage themselves through it.
  6. Three Sprint Planning Topics: this is overprocessing for me. Sprint planning is a deal, an alignment. This is helpful for Scrum Trainers and Scrum Coaches but I can’t see the value for the developers
  7. Overall Simplification of Language for a Wider Audience –> I disagree. It is about giving the keys to management and other Office´s of Methods and Tools or PMO

Deep dive in the text

Scrum Definition

“In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat “

A Product Owner orders the work for a complex problem into a Product Backlog.

Comments: The person ordering the work in the early stages of the scrum was the customer and the Product Owner was the one able to translate the needs of the customer into a vision. That vision is decomposed into Product Backlog Items (PBIs) in the Product Backlog. That made sense in an agile way of working.

In the new version of Scrum, the Product Owner becomes again the voice of the customer or is the customer: he/she orders the work. This is a roll-back to the early stages of the scrum before 2010. Here, the new Scrum Guide validates the idea that Scrum is only for the Development Team and it is no longer a Scrum Team composed with a PO as a team member in charge or functional items. 

Interpretation risks:

This will reinforce the position of bad project managers patronising the development team where he/she will own the project budget and the team and scrum master are in a customer/provider relationship with he/she. I fight against this toxic behaviour for 13 years

Who will benefit from this update?

The impact of Scrum per se has been reduced at an operational level only. Sutherland has Scrum at Scale, Schwaber has Nexus to cover the organizational aspects of scrum. 2020 Scrum Guide is giving more space for the scaling methodologies and will help mostly the training providers and the methodology coaches by giving them an unnecessary credit. It mostly deserves all the scrum teams who find their way in an agile working model as a complex adaptive behaviour: self-organised and without authority in the scrum team. 

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

With little operational experience, every agile team are producing value during a sprint while using team dynamics.

The wording is explicit, the scrum team is a productive system. It is no longer an experimenting team. We can play with words and balance between knowledge value and business value. The complex-systems-like approach that we had in the earlier versions where we avoided to have goals and enforced the idea of forecasting is skipped away.

The new scrum guide is embracing linearity in a very Lean manner. 

This is an argument that scrum is no longer Agile.

The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

It looks similar that the earlier version but “adapt” has been replaced by “adjust”.

Adapt gave the idea of embracing change: “you adapt something to an emerging context”. 

Adjust has a different meaning: “the plan remains unchanged and you proceed to adjustments to ensure alignment”. Adjustment is an action when you discover variability in the system and you action countermeasures to recover the initial system. When a product line stops becomes of a defect you adjust the tool and relaunch the line. When the production line has to respond to customer demand or different solutions, you adapt the tool.

Repeat “

… and you repeat the process

The change in the scrum definition is not innocent. The big picture for non-native English speakers hasn’t changed. The chosen words will mostly help the traditional management by relegating scrum as an operational tool for development teams only.

Scrum Theory

“Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”

Here comes “lean thinking”. Even if the word Scrum was strongly inspired by Takeuchi and Nonaka, Scrum has strong relations with Kaizen (Japan) and a bit with Lean (USA).

Lean thinking has a feeling of noblesse and most of the MBA classes have an L6S program for their future managers. Unfortunately, in 1995, the Lean Institute designed the evolution of Lean Manufacturing called Agile Manufacturing. 25 years ago, the Lean Institute raised the point that linearity doesn’t work any longer in a global and connected future. That connected future is non-linear and it is called the complex adaptive system the people like Snowden, Kruse and Niedschmidt clearly described as the future of work.

Scrum practitioners (those doing the real work and not observing or talking about) have understood that the future is agile and not lean.

Mentioning “lean thinking” as the foundation is rude and has been added since the latest version.


“work must be visible to those performing the work as well as those receiving the work” is interesting for “those receiving the work”. I preferred the old form. 

“perceived state” is not a good choice. I would prefer something like “decisions are made on real data”.

“Inspection without transparency is misleading and wasteful”. This is for those who didn’t understand that scrum is lean now. “Wasteful” wasn’t necessary and not relevant in that context.


“The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.

Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.”

In red, the words, terms that I find a bit aggressive or process-oriented. With all due respect, I don’t believe that this document has been written by Sutherland and Schwaber. It looks that the ghostwriter has a six sigma background. I’m sorry, the scrum was engaging and even words like “Controler” or “supervisor” has been used before, the way it has been written was more open.


“If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”

Again n red, the words, terms that I find a bit aggressive or process-oriented. I like the last sentence, it is up to the Scrum Team to adapt. A long long time ago, all the stakeholders of a scrum system have to adapt like in the Review Meeting, the inspect and adapt of the stakeholders.

Scrum Values

Successful use of Scrum depends on people becoming more proficient in living five values:

Commitment, Focus, Openness, Respect, and Courage

“The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. “

Commitment and goals are back.

Scrum Team

“The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

No sub-teams are clear, but I expected a clear statement that people might be members of a single team and not multiple teams like we usually see. I miss also the mention that a Product Owner and the Scrum Master are dedicated to a single team and not to a collection of teams.

On the other hand, the notion of no-hierarchy makes sense but it is contradictory with the notion of “ordering work… into the Product Backlog”. The verb “to order” inherits a notion of authority I.e. hierarchy. This will lead to a couple of unnecessary debates in the organizations in the coming weeks.

“The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. “ Ten is quite large for a Scrum Team.

“In general, we have found that smaller teams communicate better and are more productive.”. Here I’m a bit confused. Does this mean that the Scrum Team is now self-organised again?

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” This is also confusing. If I read it well, if a team becomes too large they have to split into different teams sharing the same goal, the same product backlog and the same product owner. It this is in the opposition with what has been mentioned before, This allows the creation of some kind of Feature teams with a lot of dependencies between them. It will also support the inefficient idea of proxy-Product Owners for the sub-team, even it has been mentioned before that they are no sub-teams. How weird is that?

“The Scrum Team is responsible for all product-related activities …” Mentioning “Product” is not helping Scrum Teams working on Services, Data or non-Product-related activities like one of my Board-of-Directors Scrum team. The word “Product” will cluster Scrum as a Product Development only framework and that makes me sad.

“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.” It is a positive enhancement. The shared accountability of the Scrum Team including the Scrum Master is something that was missed. It will help to position the Scrum Master as an active member of the value creation process and not an outstanding “process Controler”.


“Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” 

“ï Creating a plan for the Sprint, the Sprint Backlog;

ï Instilling quality by adhering to a Definition of Done;

ï Adapting their plan each day toward the Sprint Goal; and,

ï Holding each other accountable as professionals.”

Planning over following a plan is in the DNA of Agile and was a key differentiator of Scrum as a scaffolding of Agile. Using the word “plan” is emphasising the idea that the Developers are doing professional work. The intention was maybe to enforce that idea but it supports a waterfall principle that patterns (plan) precede data (outcome). It is a bad idea to use a plan instead of planning.

Product Owner

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

Here “Vision” has been replaced by “Product goal” and this is a very bad idea. In the early ages of Scrum, we had the Vision and the Sprint Goal. Sprint Goal has been removed to allow empiricism and Vision were the Northstar or the Purpose of team´s engagement. A Product Goal is very explicit and tells the team that they are here for that specific goal only. Business Analyst has now a green card to transform their requirement “catalogue” into a Sprint Goal and Developers have to execute all necessary activities to reach that goal without challenging it.

If you have still a doubt that Scrum is back to Product Development, please check the red words :

“The Product Owner is also accountable for effective Product Backlog management, which includes:

ï Developing and explicitly communicating the Product Goal;

ï Creating and clearly communicating Product Backlog items;

ï Ordering Product Backlog items; and,

ï Ensuring that the Product Backlog is transparent, visible and understood.”

It is a mantra!

Scrum Master

“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. 

He/she is no longer ensuring that the agile values are respected and understood.

They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.”

Who are they? If the order is respected “theory and practice”, Scrum masters are shifting from Team coaching to PMO.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”

This is interesting too. What kind of true leaders are they? Do we have now a PO that orders the Product Backlog, the Scrum Master leading the team in a Scrum manner, and the Developers to execute those orders? Sounds bad and intrinsic motivators have been forgotten for the sake of the Product. Seriously?

The Scrum Master is a servant-leader and that word should replace the word “true leader”. A true leader cannot be a coach, it is a conflict of interest. A servant leader on the other hand can coach.

Scrum Events

I will make this short even the wording is very bad and hurts my brain and guts all the time.

Here are my biggest concerns:

ï “No changes are made that would endanger the Sprint Goal;” Here comes Sprint Goal!

“Scope may be clarified and renegotiated with the Product Owner as more is learned.” I understand the idea behind but I cannot accept that in the Scrum Guide. The Dev Team doesn’t negotiate the scope with the Product Owner (he/she works in the team), it is the product owner, as the voice of the scrum team, who negotiates the scope with the customer.

“Each Sprint may be considered a short project.” This is very risky. This will be used as an argument for sprint contracts. From a project management perspective, mentioning it isn’t that bad. But you have to consider how the market is behaving and how poor project management knowledge is in companies.

Sprint Planning

Topic One: Why is this Sprint valuable?

Topic Two: What can be Done this Sprint?

Topic Three: How will the chosen work get done?

There is a third topic: what is the purpose of the sprint. 

Sprint Retrospective

“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”

It is a very bad introduction of the meaning of a Sprint Retrospective. It is again a good opportunity for a 5Ws. I’m kidding.

The retrospective is the event where the scrum team reflects on their way-of-working and it’s not limited to quality and effectiveness. The scrum team is also composed of humans having “real” intelligence. Quality and effectiveness it’s not a goal. I never saw teams gathering to make things worse and be idler.

Scrum Artifacts

“Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

ï For the Product Backlog it is the Product Goal.

ï For the Sprint Backlog it is the Sprint Goal.

ï For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.”

The words, again are weakening the general idea of Scrum. The Artefacts are ensuring alignment of all stakeholders involved in the development of the solution, or to solve the identified problem.

Product Goal, Sprint Goal has almost been part of the Definition of Done. It has been called the levels of done: done for the product, done for the sprint, done for development, etc… I can’t see any value here to split it.

Product Backlog

“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.”

The Product is an ordered list of what is need to improve the product means that the Product already exists. If yes, who creates the Product? And, is the Scrum team some kind of development support team? I guess it doesn’t unless the incoherence was intentional. The Product Backlog is a list of all functional items need to create a solution to address customer´s needs and business requirements. That list evolves over time to maximise the impact of customer´s needs.

It is not the single source of work undertaken by the Scrum Team, the Sprint Backlog, including functional and non-functional items, is the second source of work.

Commitment: Product Goal

Nothing more to add, just a very bad idea.

Sprint Backlog

“The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).”

Now you have to create a ticket in your Jira or AzureDevOps with Sprint Goal in it. Sorry, the sprint goal is helping you to create a sprint backlog, it is maybe the Definition of Done of your Sprint I.e. the headers of your Kanban board, but it has nothing to do with the Sprint Backlog.

My conclusion:

I don’t who wrote that document but I have serious doubts that Sutherland and Schwaber did.

In the community, people are repeating the intention of that new version like making scrum more accessible to a larger community. I have to say, they failed.

It is a confusing document and it will create more conflicts in running scrum teams that it will solve problems.

If that document, and I hope from all my heart that it doesn’t, represents the new scrum, it will be the most important fall back in centuries. It moves Scrum away from agile to become a lean six sigma process-oriented normative approach.

Now I’m sick and sad.


Word count

Sometimes you find interesting documents in the recruiting process: agile coaching requirements

I’m the first to complain when companies are trying to hire agile coaches for the wrong reasons like:

  • you have to a software engineer
  • you have to be an SAP expert
  • you have to use MS AzureDevops or any other tools

These are the wrong approaches and gives the feeling for the candidate that the company don’t know anything about Agile.

And, sometimes, you got a great list. Here is the list I got last week and I wanted to share it with you:

Your requirements*****Comments
•Creation of a cross-cluster transformation plan and further development of the control model in scaling systems*****Transformation Backlog owned by the Agile Transformation team consolidating data from the front line and the strategical requirements from leadership. Transformation is handled as an agile project with all agile coaches and scrum masters as team members.
• Support and advice for the cluster in the agile transformation, especially the Agility Masters, among others in the appropriate agile methods*****Support is performed from different manner: pair-coaching, team member support and supervision.
• Conveying agile values and principles in scaling systems*****“What kind of Agile is your Agile?” Approach ensuring alignment of values and principles through the whole organization. WKOAIYA is evolving through assimilation and not colonization.
• Support in identifying and removing organizational obstacles and organization-wide blockades*****Balance between organizational chart and sociogram. Use of Viable System Model and AO techniques.
• Contribution of experiences and ideas to the cluster and the agility instructor community as well as evaluation criteria for effectiveness*****Very creative and great adaptability, lateral thinking and adapting existing tools in context
• Conception of scalable training and workshop formats*****15 years of experience. Every workout is different. 8 years of experience in the conception of virtual trainings and virtual facilitation
• Support of dysfunctional teams / units / cluster structures through coaching or a suitable one*****
• Conflict resolution (in the sense of a mediative attitude and ideally systemic coaching)*****Systemic Coaching, ACC, CAC, Clean Language Practitioner, NLP, and NVC
• Support and advice / coaching of the teams / units of the cluster over several months until the teams have internalized the agile methods and mindset in their actions and optimally align their work with the company’s value chains*****
• Methodical support of the cluster team of teams on the way through the transformation process including passing through the quality gates*****
• Methodological support of several unit teams of teams on their way through the transformation process including passing through the quality gates*****
• Systemic support for processes and formats that are critical to success at cluster and unit level*****
• Enabling the cluster AM as well as several unit AM in your role as a transformation companion for teams or teams-of-teams – this applies in particular to the topics:***** – Mentoring & Supervision
• Creation of optimal working environments*****From “work-from-anywhere” to interior design and facility design consulting
• Development of self-organization*****
• Exercise of E2E responsibility*****
• Enabling working methods*****And help in finding the right method for aligning the system
• Optimization of KPI processes*****Finance and Management Background.
• Enabling the PO cluster as well as several unit POs to agile work and separation of “what” and “how”,*****Service Design, UX, Business Analysis and BPM.
• Creation of business strategy, product visions, roadmaps, business cases and budget responsibility*****Prince 2, Discipline Agility Advisor and Portfolio Manager in Ventures Background
• The aim is to develop the entire cluster structure into fully self-organized and independently acting teams and teams-of-teams (units, clusters).*****
Must requirements:
• Min. 5 years of extensive practical and theoretical knowledge as a business coach on agile methods such as Scrum, Kanban, DesignThinking and Lean Startup as well as agile control models such as flight level models and OKRs*****13 years Agile + Scrum, 10 years Kanban, 20 years Design Thinking, 8 years Lean Startup, AgileEVM (control model) Practitioner for 12 years, OKRs (2 years)
• Min. 5 years of experience in the transformation / organizational development of large companies into self-organizing, scaled organizations (leading into self-organization) verifiable through two corresponding project references in large corporations and representation of one’s own success share (e.g. number of transformed employees)*****BNPParibas Group (10 000 p)SAP SE Global Finance Administration (4000 p)SAP SE Global Finance IT (200 p)ArcelorMittal (200 p)CNHi (Fiat Group) (200 p)
• At least 3 years of experience in the professional application of agile methods and self-organization, ideally in the role of product owner in a group or medium-sized company*****100% Agile method and techniques for the last 10 years. Adaptation of waterfall practices such as SOX Audit, ACTIVATE, Focus Build, Flow, Hermes in an agile context. Roles: Agile Coach, Scrum Master and Product Owner.
• Experience in the successful transformation of large corporations: experience> = 5 years*****SAP, BCG DV, Wego, ArcelorMittal, Euroclear…
• Experience in the professional application of agile methods and self-organization: experience> = 5 years*****13 Years.
• Experience in OKRs, flight-level models, verifiable through references****4 stars for flight models like Hoshin or other decision-making methods, 1 star for OKRs
Target requirements:*****
•Extensive knowledge of scaling systems such as SAFe, LeSS or similar models. Verifiable through references and two experience reports to show your own success share*****Extensive knowledge of SAFe, LeSS, Scrum at Scale, Nexus, Disciplined Agile, AO, ITIL, and TPS. References will be shared after interview. But you can see it already on my LinkedIn profile:
• Support of the transformation by visualizing the methodical approaches using suitable work materials. Extract of working materials / aids to visualize the methods*****,also in the virtual area

AO on InfoQ: “Q&A on The Book AO, Concepts and Patterns of 21-st Century Agile Organizations”

Key Takeaways

  • Agile has evolved from a set of tools and methods to become more agile to a specific organizational setup, allowing great interactions of individuals.
  • AO cannot be considered a method or a process; it is a set of tools guiding the change from a rigid top-down structure to an organic and empirical organization. A continuous organization becomes a bottom-up key.
  • Clarity on where to go and what Agile is helps leaders and coaches to move away from a theoretical perspective and focus on what matters and solve problems.
  • There is a big misunderstanding on the concept of scaling. Scaling means applying the same plan all over the world. Scaling, in agile words, is waterfall applied to organizations. 
  • At scale is maybe the best response. At scale means embracing diversity and growth by assimilation. That assimilation is a two-way process if you believe in adult-adult relationships.

The book AO, concepts and patterns of 21-st century agile organizations by Pierre Neis explores the concept of designing systems to allow for agile behaviour. It provides patterns to establish agile organizations that are able to respond to 21-st century challenges.

InfoQ readers can download a free copy of the book AO – offer valid until the end of December 2020.

InfoQ interviewed Pierre Neis about agile organizations, sociograms, Cynefin, new paradigms, agile transformations, intrapreneurship, scaling agile, managing projects, and becoming agile.

InfoQ: What made you decide to write this book?

Pierre Neis: The decision process took me ten years. I was waiting for the right moment to publish it. Ten years ago, most of the concepts were designed and tested. I gave a conference and got positive feedback and someone in the audience asked me about the book. At that moment in time, the idea of a book was far from my mind.

After my work with SAP and several bank and insurance companies, I felt legitimate enough to share my vision of Agile.

The format was also a big challenge. In all these years, I had collected a lot of data and documented all my work. Deciding what to keep and what to remove in order to be more inspirational rather than prescriptive was the hard part.

To summarize, the real decision to write this book is an acknowledgement of the work achieved by all the teams, organizations, and people trusting me during the last fifteen years and the will to handover the relay stick.

InfoQ: For whom is this book intended?

Neis: There are several levels of lecture possible. The book is intended first for agile coaches and organizational developers. The book is a theoretical catalogue allowing you to focus on what matters.

Leaders and executives are the second audience. They will understand what challenges they will face and where to go from there. It will help to design the alliance between management, business and operations. The five experience bases metrics are an outcome of strategic planning with executives.

HR people are also interested in this book. Through the agile4hr project, I had the opportunity to interact with plenty of HR people. The great takeaway for them was Agile Systems Dynamics.

These are the target audiences that I already know at this moment in time.

InfoQ: How would you define agile? And agile organization?

Neis: I put my definition of Agile in the book. Agile, capital A as a noun, is for me the nature of how people are interacting together in a system called team or organization. It is the “individual and their interactions” part of the Manifesto. Agile as an adjective is still accurate, but for tools and techniques. I can be agile as an individual, but this doesn’t necessarily change the system in which I’m evolving. The opposite is true: you can have an agile system without agile people.

My definition of an agile organization is a system designed for engaging people; a system based on negotiation where win/win/win is the driver: win for management, win for business and win for operations. An agile organization is for me a collection of swarms and hives with a simple design, full of designers rearranging themselves from one deal to another.

InfoQ: How can a sociogram help to get insight into our organization?

Neis: The sociogram is considered as the “real structure”. It highlights the real networks in your company and not the virtual one. Considering that Agile is a sensemaking system with the ability to situate a network, we should consider that network seriously. The sociogram is a way to make this network explicit.

As an example, in Scrum, you care a lot about impediments. One of the biggest impediments is not engineering; it is any distraction- distraction coming from other managers or because you can’t focus to solve one problem at the time, but you have to switch between different projects. If you use it to draw the interaction of each of your team members, you will discover an insane spider web. The bigger the network the greater the risk.

In the book, I use the Apple Tree example. The Appletree is a retrospective to reorganize ourselves based on the activities and distractions we have. Here you find also the idea of emergent design. In the end, the sociogram will show concentrated interactions mostly around the team and their stakeholders. 

A sociogram is a tool that you use all the time because your teams are evolving all the time and don´t stand forever. The “forever” is in the Enterprise Experience layer; the Organizational Experience is in constant evolution to allow work to flow into teams, and not individuals.

InfoQ: In the book, you described how you use Cynefin in a dynamic way. How does this work?

Neis: Well, I always dynamically saw Cynefin and I was confused when people were considering it as static. My model is based on the Cynefin learning curve and the “linking the dots” part. I felt sad and lonely seeing it like that.

If you consider Cynefin as static, you are analyzing a situation at a particular moment in time from a single perspective.

From a dynamic way, things are a bit different. 

Let’s consider our COVID-19 times. People are no longer collocated, and they are working from home. From a Cynefin perspective, we can say that the organization design is CHAOS: a collection of decoupled individuals. The very nature of management is COMPLICATED with the idea that tasks are SIMPLE. Unfortunately, management is working from home office, by extension also in CHAOS. The consequence is a freeze of organization, and management is applying best practices such as cost-cutting, firing people and increasing controls. As a side effect, this results in more disengagement, fear and DISORDER.

What to do? This is an unknown-unknown situation where analysis doesn’t matter. What matters is to start moving forward again, but maybe not at full speed. You know that you have to get options to experiment. You start with a shared goal, a crystal clear vision or intention. You start SIMPLE; everyone agrees and knows the WHAT. 

Then, you move into CHAOS. CHAOS is the brainstorming part of the problem-solving process. It is the personal commitment, engagement through the creation of individual ideas. 

Then rapidly, based on these ideas, you ask people to gather into teams. Then at the team level, let them build something else on the top of each other’s idea. Now you are in COMPLEX where innovation occurs. 

Once prototypes are available, then it’s time to analyze at different levels like enterprise. This is COMPLICATED. At this stage, decisions are taken to focus on a single option or to dive deeper. That decision is collective and the outcome is SIMPLE again. 

Then you relaunch the loop.

I called this model Agile Systems Dynamics (ASD) because of the backfire I received from the Cynefin community, and I considered it as an exaptation of the initial model. ASD has also been updated from my different experimentations and enhanced with complex systems theorists like Kruse and Niedschmitt. In the initial model, management was almost at the top of the dotted triangle. The idea was to highlight the system supporting self-managed people. Cynefin was built around the opposition of structured systems (COMPLICATED, SIMPLE) and unstructured systems (CHAOS, COMPLICATED). This was a great support to emphasize that organization isn´t structure.

InfoQ: How has the nature of work changed in the 21st century? What are the new paradigms?

Neis: Let´s define the context. In the early 20th century, the work was mostly linear. You had the top of the company planning what to do and the workforce executing that work. It is called scientific management, where you have a clear distinction between Leadership, Tactics and Operations. The linear model follows the recipe of patterns preceding data to support mass production.

After WWII, the demand moved, and there was a greater need for mass customization. At the moment, our new paradigm was system thinking. Here you find models such as Kaizen, TPS and Lean. System thinking is based on information control where scientific management is on function control. System thinking is also a linear approach where patterns precede data. You still have a three-tiers management structure like Front, Middle and Back Office.

With the emergence of the internet at the end of the 20th century, a very deep evolution has occurred. Information has been widely shared and accessible. A consequence of that emergence was that the knowledge moved away from the Top and the Middle, to the Operations. Before that time, you assumed that your boss knew everything. Now, your boss knows less than you.

This new paradigm is a huge shift. We are shifting from the patterns-precede-data to data-precedes-pattern model. It means that your organization has to produce more data and the solutions are emergent. This state is called Sense-Making, and it is all about the ability to situate a network. In that paradigm, the old structured systems models don’t work and we talk about Complex Systems. Agile is a way to address complex systems.

These systems, as described in ASD, are self-managed and you can´t control them. If you control a complex system, you make it complicated and you’re stopping your innovation journey.

Another challenge is in leadership. Because you can´t control such a system, you have to learn to resonate with it. This is not linked to servant leadership; this is management related. To resonate means being a constructive-irritant. It means having the ability to understand at what moment in time you intervene to accept or reject options.

As you can see, that shift is huge. A vast majority of companies are stuck in scientific management, and sometimes in system thinking. Words like production line, business line, factory, and scaling are not considering Complex System as an opportunity, but as a thread.

In my book, I gave some patterns to move into Sense-Making or AO. And, I explain that there is a learning curve for organizations in moving from “Unknown” to “Scientific”, then to “Systemic” and to “Agile”.

InfoQ: How can organizations deal with these changes and new paradigms?

Neis: I was missing tools to start the conversation with my clients to avoid the debate about “that’s agile and that’s not”. So I created the Switch model which you can find in my book. It explains that by default, we are in Structure with different steps to reach AO as a fully agile organization. I intended to explain how the goal might be (AO), not to reach it but to design with clients their “high dreams”.

The Switch starts in Structure, where you do agile entertainment. Then the first step is Awaken, where you start your first experiments in a waterfall manner. Then, when you are ready, you move to Rubicon where you move into system thinking, using Lean techniques as examples. Then, when you feel ready you move into A-Venture, where teams are considered as profit centres and are behaving like internal startups and governance is managing a portfolio of investments. The ultimate agile organizational model is called AO. In AO, the company is working like a multi-site platform supporting transactions like Airbnb.

Having such a high level roadmap helped my clients. During our conversations, they are deciding how far they want to go. At the executive level, we are also considering what required level of agile there should be to support the strategy. It becomes OK to address support, infrastructure, finance, and shared service as linear at the beginning. It also makes visible the risks of misalignment between services.

The Switch is a timeline with five steps to move from structure (managers assigning tasks to individuals) to AO (only self-organized people), through Awaken (waterfall), Rubicon (Lean), and A-Venture (agile teams as internal startups).

The Experience Metrics are customer experience (CX), service experience (SX), people experience (PX), organizational experience (OX) and enterprise experience (EX). In agile organizations, most activities have a customer (not an internal customer). The outcome of the project is documented and may be automatized as a service (SX) consumed by customers who are not interacting with people from the company. Great CX is achieved by empowered and engaged teams (PX). The result of great PX is the constantly evolving team sizes adapting to changing purposes (OX). EX is the container allowing fail-safe experiences. It is the last necessary structure left.

With SAP as an example, we used this naming convention to highlight the portfolio of activities. After some workshops, there was common agreement to decide to improve CX from 10 to 25%, and to reduce SX from 70 to 50% in 2020 (before Corona).

Combining the Switch and the Experience Metrics has become a clear and simple language to express the strategy. For example, if the company decides that having mostly CX activities means that the company has been mostly at least in “Rubicon”, or if a company is mostly selling services through a platform, then SX is crucial, etc…

Organizations have to consider these paradigms because they involve the way you are working with your people and your partners. In a VUCA world, growth and partnership are Complex by nature. In the past, when I was a Lean coach, we imposed the methodology to people and partners. This was very colonialistic. Agile or Complex systems don’t work like this; growth and partnership are part of an assimilation process where both sides are improved. This is true whether you are global or in the Merger/Acquisition department of the company.

InfoQ: What causes agile transformations to fail? Is there a way out?

Neis: My answer will be short. Hybridization is the most common failure. Accepting to mix oil and water doesn’t work. Water always wins.

Most so-called Agile Transformations are stuck in Structure, where good willing people have no power to switch from one paradigm to another. One great measure is the Gallup report on Engagement at work. If agile transformations delivered their intentions, the level of engagement should rise exponentially. In reality, it does exactly the opposite.

I like to say that agile transformations are like the Yeti; everyone talks about it but no one has seen it.

At the end of last year I met one product owner from SAP and asked if everything was going well. She told me that once I completed my contract, senior management hired a LeSS coach, and then a SaFE coach. I asked her, “What are you doing?” She answers, “We are doing what we always do. We are following the design we created together.” At this moment in time, my purpose wasn’t to assert a brand like “AO,” but I was satisfied it being “their model”.

That’s the reason why so many transformations are failing. They are not transformations, but methodology implementation. That’s a completely different topic.

If you want to play smart, the heart of failure is to believe more in chronology than in kairology.

InfoQ: You mentioned in the book that an agile organization makes it possible for managers to become intrapreneurs. How does that work?

Neis: It is exactly how I described it in the book. You don’t touch the salary, bonuses, or position because they are structurally related. You consider the corporate strategy as a product roadmap and the SVPs as product owners or Agile coaches. That’s it.

And you can ask them what they want to do to create value for the enterprise.

Managers are just another kind of developer. You have to move them out of transaction work to value creation. This way of working has strongly resonated in the finance industry, and some impressive advances have been achieved.

This idea is not new. IBM in Belgium proceeded this way twenty years ago.

InfoQ: How can we scale agile to make it work in large organizations?

Neis: Scaling is a red-herring. It is a word related to structure. Agile is non-linear.

The difference between scaling a couple of teams and working with hundreds of teams is the pace. Fifteen teams globally distributed in Agile can be handled in six months or less. Five thousand people in finance will take maybe two years.

My customers are mostly that big and global. The biggest challenge is not in methods and structure: you can find plenty of free tools helping you. The big challenge is coherence and alignment: if the message is diluted or disturbed, you won’t be aligned.

The how is also not complicated. You always start small, look at your system and adjust collectively.

When I read about scaling, I discover new words for old concepts. You still have programs, projects and transactions. And, program management or even Hoshin Kanri are still accurate.

InfoQ: How should we manage projects in an agile organization?

Neis: In AO, projects are managed in a typical agile way: product owners are working on needs and not on requirements. They are part of the team and not an authority.

Projects are starting in Swarming. Swarming is a way to explore, test ideas and create options. 

Swarming helps also to limit the work in progress at the project portfolio by limiting the number of parallelly running projects. The outcome of a swarm can be a Proof of Concept, a prototype, or an analysis.

With defined projects where we have funding and a business case, we try to engage the customer early on, even in daily meetings. Once a part of the whole project is delivered, only then is it documented and compiled at the portfolio level.

In my book there is a chapter addressing the way projects are managed in AO.

InfoQ: What are the steps to becoming an agile organization? What’s needed to take the steps?

Neis: The story always starts the same way: we gather in a workshop. That workshop is called “design agile organizations”. In that workshop, we visualize the current state of the structure and try to highlight the interactions through a sociogram. With both visualizations, the gap is made visible.

Starting with the corporate strategy, we challenge it with the current state and sociogram. At this moment in time, you have to start and accept early adjustments.

This is a typical quarterly collective decision-making workshop. Management explains the quarterly roadmap. That roadmap is challenged and improved by the business, and then by development. Business and development are creating tactics to reach that strategy.

The outcome is an updated roadmap. Management is then allowed to challenge and likewise adapt that proposal. If no agreement is reached at that moment, you start over again another day. When all the stakeholders come to an agreement, we ask for dependencies and we adjust the roadmap to minimize the impact of such dependencies. Bearing in mind that every team has to be end-to-end, some teams have to be reconsidered in that moment. If you still have dependencies, they will be removed from the roadmap for improvement.

Now, you have a common agreement and it is time to ask the teams where they want to work.

This interview has been originally published on

Decision making in the New Normal

In these COVID-19 times, anxiety and fear are freezing our ability to respond to any threats or opportunities in our business environment. 

We are in surviving times where our reptilian brain takes over rationality. Stopping the engine instead of moving forward sounds to be the only action feasible. Brain and guts, reflection and action are disconnected. In cognitive psychology, that phenomenon is called a reverse locked-in syndrome where the brain commands to fight the fire without any possibility to start fire prevention until your company becomes an empty nutshell unable to respond to any new opportunities.

These lines intend to explain how leaders can start leading again walking slowly through the fog until they find the light for the sake of their company, their people and themselves.

MBA students have learnt how to analyze a situation and use best practices to set up an action plan for execution. This way of working is linear and applies the sense, analyze and respond approach. Usually, decision making follows a genuine process:

  1. Analyze the situation
  2. Prioritize
  3. Select option

Usually, the decision-making process is a structured linear process with clear cause and effect relationships. Tools like 4W1H, Fishbone Diagram or the Kepner Tregoe method are helpful.

The New Normal or also known as VUCA situation or complex system have a completely different manner to address Problem Solving and Decision Making. This situation is unknown, not documented and you can’t apply good practices. 

In systems thinking, we call this situation unstructured where cause and effects are decoupled and each solution is unique. In this context, you are looking for collective problem-solving. The aim is not to analyse the whole problem but it is to probe, sense and respond with tiny options to experiment. Those options allow continuing moving forward in a much slower pace. Keeping the organization moving prevents crystallisation and locked-in.

This is how the agile way of working tackled problems in the last twenty years. The idea of experimenting early, falling faster, creates a better understanding of the problem while getting sooner the necessary data.

From a team dynamics perspective, we assume that the solution is already known in the company and we have to create the conditions to test the hidden options. 


 In this context, you are making decisions on options, a collection of options. Some techniques like MosCow and WSJF are leading to prioritizing those options and are helping to rationalise instinctive decisions:

  • MoSCoW: or must have, should have, could have and won’t have prioritization
  • WSJF: or weighted shortest job first (D. Reinertsen) is based on two parameters Cost of Delay and Duration

These techniques are quite simple if you are addressing one single problem. What is happening is you have several projects, problems, multiple teams, multiple locations? You can use the same approach but at a much higher level in your corporate portfolio:


Pr. Dr Peter Kruse was an expert in complex systems theories. He explained that the very nature of complexity is in decision making. In complex systems, you will find ambivalent situations where techniques might valid all options even those being contradictory. The only known way of getting away from such confusion is to trust your limbic system or your instinct.

Trusting your instinct sounds not scientific at all but this is the way where the human being is making the difference with a machine: a human brain can take decisions even not knowing all the details of a particular situation.

To mitigate the risk of bad decision making, the Agile world is using two cognitive approaches:

  • collective decision making: the way of working is negotiation based where all the involved parts have an acceptable win.
  • And iterative decision making: the deal, result of that negotiation is valid during a limited time until the collective gathers again for a new deal. This empirical approach is helping about a stocked situation allowing pivoting or persevering.

As a conclusion, decision-making process in the New Normal is collective and collaborative. The collective is iterating shortly testing all the options until the hidden one emerges from that dynamic.

And once the storm is passed, you can roll back to a more traditional decision-making process.

In November 2020, the Requisite Agility Group and I will start a collection of workshops helping you through decision making processes in VUCA Times.

Pierre E. Neis

Author of “The New Normal: AO concepts and patterns of 21-st century agile organizations”

Our collaboration with PMI/Disciplined Agile

In July, I started a conversation with Scott Ambler about how the agile way might address Human Ressources.

This conversation leads to a collaboration where I advice on People Management and PMI will support both AO and agile4HR.

The first milestone occurred October the 8th 2020 via an online talk addressing following main questions in front of a 1100 people big audience:

  1. What is “agile HR” and why do we need it?
  2. How is HR involved in organizational transformations?
  3. How can agile HR enable agile and lean teams to execute effectively?

For PMI Members, you can hear and watch the recording on the PMI platform here.

Agile4HR and AO are part of my new initiative “The New Normal”.


Don´t be afraid about emotions

Working on several projects and facilitation, I was each time confused about how professionals are addressing emotions.

Everyone has to be happy, enthusiastic, nice and gentle. Loud people even jokers and rude people are contained. Under the umbrella of “be yourself”, that yourself sounds more and more to be “like I expect from you to behave”.

Don´t misunderstand me, I´m not writing about behaving like punks. I´m writing about not behaving like puritans.

From a systemic coaching perspective, positive behaviour is the expected outcome and not the corset of forcing fake positiveness.

Let´s take an example with children. Your child is behaving badly during the family dinner. You have options:

  • yelling
  • lecturing
  • understanding the source of that behaviour

Unfortunately, option three is missed because it is time-consuming. To avoid addressing that option, you create a lot of codes and rules that your kid doesn´t read, understand because it doesn´t solve the problem.

Sometimes, giving five to ten minutes of time to the kid to express its feelings does the job. Another example: you are coming home from a week-long business trip and the only thing you want to do is to hug your spouse. Unfortunately, as the door, your kids are jumping around you completely excited. What to do? The bad option is to ask them to calm down. The right option is to talk with them five to ten minutes before hugging your spouse.

Emotions are indicators of how people in your “system” are feeling. There is no bad and no good, we are human beings, right? As a coach or a facilitator, you have to detect these emotions and create to “empty the bucket” before these feelings are creating “bad” behaviour.

While browsing on Wikipedia looking on ethics, I came through this :

“Bad” behaviour is a cultural thing. In Mediterranean countries, social interactions are often passionate, loud with a lot of jokes that can be interpreted as offensive or inappropriate if you are an Anglo-Saxon as an example.

If you take a look at the figure above, you can identify some indications on how to build a code of conduct or a working agreement for such meetings.

On my personal plate, I had a couple of complaints about my behaviour for the last ten years. I´m enthusiastic, extravert with a high proportion of joking. So, even 99% of the people I worked with understand me well, I´ve got comments like buffoonery, rashness, vanity, obsequiousness and modesty. That´s a complicated picture, isn´t? Is that me? Absolutely not. It is the perception of an individual at one moment in time. Usually, the emotion leading to that comment is linked to previous experience. It is a trigger and you are receiving that emotion.

As a facilitator, it is important to identify emotions and the trick is to give the voice to everyone at least during a minute in every meeting you are running. This is the virtue of the kid’s metaphor. Sometimes, people are coming “loaded” of emotions in your meetings.

A great meeting is one where you find your space. Give space to all attendees to ensure great communicate.

Harrison Owen, the creator of Open Space Technology, came with simple rules such:

  • the law of two feet: if you have the feeling of not contributing or not learning, use your two feet
  • whoever comes is the right people
  • whenever it starts it´s the right time
  • whatever happens, is the only thing that could have
  • when it´s over, it´s over.
  • two personae: bumblebees are cross-pollinating and butterflies which are flying around

Great facilitators are creating a space, a non-judgemental space accepting also some borderline behaviours if it serves the purpose of the meeting. Brainstorming as an example is a place for excess and creativity. Decision-making meetings are more quiet and analytical.

The last point of attention, if you have introverts in your team, make the session into two parts with a break in the middle and give them the voice in the second part. (kids metaphor).


Defining C-suite agile with Requisite Agility

Requisite Agility (RA) is an evolution of Requisite Organization (RO) adapted to the complexity of a global connected world.

The common denominator of both RA and RO is the initial problem that RO tried to solve like “lack of effectiveness of bureaucracy within a stratified hierarchical organization” (Wikipedia) including specialization of function.

Function control is related to scientific management, assuming that patterns are preceding data. Agile, on the other hand, is “Sense-Making” where you are looking to situate a network and where data precedes framework.

They are several points that don’t make any sense in “Sense-Making/Agile”, like management or accountability because of the self-managing nature of that complex system.

Organizations like SAP or Daimler are looking about the Stern Steward model applied under cover of “digital transformation”. That model is appealing “Sense-Making”. They are using the multiple sides platforms model with three principal layers like platform (mid and long term programs), swarms (short term projects) and plexus (Governance).
In my eyes, there is no clear “agile” concept responding to that new challenge that companies are already testing. There is, maybe, where RA has a role to play.

Create meaning not tools

I don’t think that RA will come out with a set of processes and methodologies on RA because it is off the grid or maybe we all have our methods and processes. What matters is, like Kasmir mentioned in one of our meetings, that strategy and Northlight will be incorporated again at C level and not outsourced to a tiers. It is all about engaged C Suite and not bureaucratic management.

Why Requisite Agility is different that Requisite Organization?

I believe that RO is totally command-and-control and perfectly designed for the industries of the 1950s.

At that time, demand was more significant than the offer. People operated in a complicated Sense/Analyse/Respond relationship even if science demonstrated that that model doesn’t work for over 20 years.”Cognitive capability and social, emotional maturity of employees” is an odd sentence, but I give you hear how things happen in CAS.

In agile or responsive systems (CAS), you are building a system allowing emergent behaviour, and we are using “Flocking behaviour” as “process” to create the dynamics in that system. “Flocking behaviour” can also be understood by “organic growth”, it is based on Boids research and applied since the 1960s. In Flocking, you care about alignment, dynamics, avoid collision, focus and separation (

Once you understand Flocking behaviour, you see that:

  • focus or true north or North Star is key
  • alignment is the starting point
  • dynamics and collision are operational

All these governance topics have already been addressed in Kaizen and Lean Management through Hoshin Kanri ( Not the tool, the coordination process.

What is the challenge?

Agile is the challenge and not requisite. An agile organization is flat, and non-agile is a segregate monolith shaped for robustness designed a long time ago.

In our preparation meetings, we came to the point to add “O” to VUCA. We went to the idea that an organization is in continual evolution, and RA tries to address governance issues on that move.

Because my all have different ways to address that complexity, we already designed the first version of RA to link our various initiatives without interfering between our believes. During our last three meetings, we experimented what RA might be. Now we roll out to test it during the coming Unsymposium.

Join us the 5-6th of December 2019 in Heidelberg (Germany) to define together 21st-century C-suite:

More to read:

  • “Agile is in everyone´s mouth”. link
  • “Understanding 21st-century work”, link
  • “What´s agile?” link
  • “Addressing new challenges”, link
  • “Changing paradigms”, link

Introducing AO- agile organisation model in Geneva (French Version)

AO, how to build an agile organization (French), Geneva 02.05.2019

When if “agile” is nothing more than the dynamic of a system?

As an agile coach, it is completely boring to be considered as an evangelist or whatever guru. This is perhaps a mark of respect and that’s fine but when you are working daily with teams this becomes weird while trying to help, and people just see you as another “Moses” and not as a helper.

Every year new agile coaches are emerging and they are doing the same that I and some of my friends did a decade to 20 years ago. Genuinely this is okay, it is like when your 5 years old child is showing up its drawing. You are amazed by this mix of curves and stripes because you acknowledge the effort. But in fact, you have to admit that your child isn’t that great artist. That’s all to say that every years new people are coming with the same ideas, the same old ideas and even hijack the early sense of a concept without improving the early concept or worse transform very tiny subparts and develop their thoughts like a syllogism. So let´s try something new.

In 2011, I attended the seminar of Leading in Complexity by Dave Snowden in Frankfurt(Germany) and it was a blast for me. The explanation of the Cynefin framework helped me to understand how systems are behaving and how to act on it. Much later, in a very passionate conversation on LinkedIn this year, I discover that my understanding is a bit different from the average mass of Snowden´s fan, maybe I´m wrong but I want to explain how different it is.

Most of my colleagues are using Cynefin like a static measure to understand how a system is. The problem, this is an assumption, this is an observation from somebody outside of that system. You have to know that every observer is impacting the system and the only choice you have is to be part of that system.

What is happening in the system from the Cynefin perspective?


On the boarders of the Cynefin diagram, you can see links and dots. The dots are related to the agents in the system (can be a bunch of things, but in my case, it will be people). The links are representing how the interaction of those dots (people) is in a particular domain:

  • Complex: the 3 “people” on the base are interacting together and the one on the top doesn´t.
  • Complicated: all people are linked
  • Simple: only a top-down link exist
  • Chaos: none of them are linked.

Since 2011, I considered the yellow dot like the representation of leader or manager or authority, and the black ones like “team members”.

Then I translate the Cynefin model a slightly differently:

  • Complex: the “team members” are autonomously interacting together and co-create together a new “emerging” solution. Ex. building on the top of each one’s idea.
  • Complicated: all participants are interacting together to analyse something in order to collect “good practices” or to validate an outcome.
  • Simple: the information shared from the “top” is obvious for all participants in the system and doesn´t need to be discussed. Ex. Fire alarm = get out.
  • Chaos: nobody is interacting, all the people are working in their own area.
credits Dave Snowden, Cognitive Edge

This learning loop was for me a second blast even I do not fully agree on that picture. My pain point is on the crossing of “Disorder”, the black hole in the middle. “Disorder” is the unknown and is like the “0” in numbers, it helps to define “Chaos” and another form of dynamics and not as an unknown form. I don’t like it because it gives credit to take actions in a system which we have no data (unknown). A bit contradictory but I’m pretty sure there is a perfect answer on that.

Anyway, from my first interpretation and while using the Learning representation, I started to design a facilitation process called PLöRK. This model works like that:

  1. Start at Simple: The purpose of the workshop, of the learning point has to be obvious for all attendees. The invitation has to be crystal clear to ensure where do we want to go with our learning.
  2. During a couple of minutes, each attendee has to think individually what and how the purpose resonates. That´s my Chaos.
  3. After that time-box, you ask the crowd to work together to solve that learning problem. This is also time-boxed and takes the majority of the time. (Complex)
  4. Once the time is over, we all debrief together and some points are clarified, adjusted, improved (Good practice). Here comes my.
  5. As the teacher, then I validate the “Good Practice” with “Best practice” and the result might be obvious for all attendees. Back to Simple.

This sounds easy. Once I made a train-the-trainer session in an insurance company because they wanted to know more about PLöRK. The first 2 stages worked well and I brought the crowd into Complex. Then I saw that one member was answering emails on his Mobile Phone. I waited until the student was finished and told to the crowd that I have forgotten something. Pulled them out of Complex to Complicated. Explained again the goal of that exercise, ensured that all phones are moved away, and relaunch the loop with better results.

credits Pierre Neis

Here is the model. If we take a scrum as example, it looks like this:

  • scrum starts with a vision (simple) or a sprint goal. That goal is not deterministic, it is a forecast, an expected goal.
  • then during the sprint planning phase, each of the team members try to show up what is this all about. (Chaos)
  • then the teamcollectively try to design what and how the solution might be (Complex)
  • the team discuss negotiate with the Product Owner and try to make a dealon what has the highest business value and lowest complexity, or what needs to be fixed now (Complicated).
  • then the improved sprint goal is agreed (Simple) and the team starts their sprint (Chaos) until next days daily scrum where to team aligns and works together until the end of the sprint (Complex).
  • the sprint ends in a Review (Complicated) and a Retrospective(Complicated) and a potentially shippable increment is marked “done” and the working model has been improved according to good practice (deviation from the initial working model) for Simple.
  • then the loop is starting again.

So, let´s assume that you agree with my demonstration. What happens if someone ask a team member during the sprint to do something not aligned with the sprint goal? What happens if someone interrupts the sprint like a manager making an unplanned All-hands meeting? or having a visiting agile coach?

It happens like my student answering email during my class. The dynamic is broken and you have to relaunch the loop.

To ensure the adequate dynamic, the scrum master has to care about that. I say scrum master for that example, but it can be the Process Manager (in Kanban) or an Agile coach. The responsibility for those roles are huge because they have to care about the system created by the team. They are part of the team and protect the system from external threats. They can’t be an authority (yellow dot), in fact no one in the system is an authority and it is managed on its own (self management principle).

In my example, I used scrum to tell a story about agile system dynamics. I believe that scrum brings the minimal organisational setup with just enough roles to ensure a great dynamic with less “authority” impact.

At the early stages of agile, a team is on its way to complex adaptive system behaviour but cannot fulfil the expectation of a complex adaptive system due to the strong result oriented context. In parallel, R&D tracks are working in a fully complex mode with the only constraint to show up monthly their findings like below (complex-complicated-complex dynamic in fact):

credits Pierre Neis

The Cynefin model isn´t enough to understand agile systems dynamics. The core principle is to build a system allowing “agile behaviour” and that behaviour is emergent (empirical) this means that the system learns by itself while experimenting (praxis) and discovering his own abilities allowing to modify its boundaries: tight enough to see its limits, large enough to have the freedom to progress. If you know D. Snowden´s metaphor on the 8th child birthday party, here I have to consider all the birthday parties of a growing child (this is the purpose of retrospective in scrum).

credits Pierre Neis

By adding Flocking behaviour theory with the Cynefin model, then your scrum looks again a bit more different and interesting:

  • scrum starts with a vision (simple) → alignment of the agents (stakeholders, design alliance, design the system)
  • then during the sprint planning (Chaos) → self commitment
  • then the team, collectively try to design what and how the solution might be (Complex) → cohesion of the agents (stakeholders) ensures complex behaviour
  • the team discuss negotiate with the Product Owner and try to make a deal (not imposing) on what has the highest business value and lowest complexity, or what needs to be fixed now (Complicated)→ alignment.
  • then the improved sprint goal is agreed (Simple) and the team starts their sprint (Chaos) until next days daily scrum where to team aligns and works together until the end of the sprint (Complex)→ alignment + cohesion
  • the sprint ends in a Review (Complicated) and a Retrospective (Complicated) and a potentially shippable increment is marked “done” and the working model has been improved according to good practice (deviation from the initial working model) for Simple→ separation
  • then the loop is starting again.

I agree that this can be an obscure explanation but I will sum it like this:

credits Pierre Neis

Simples rules applied to scrum and agile:

  • point to the destination: goal, roadmap, true north, vision
  • avoid collision: scrum-of-scrums, impediment bashing, daily stand up
  • planning skills: planning poker, magic estimation, customer journeys, …
  • follow the line: scrum ceremonies and rules

How does scrum looks alike when applying Agile Systems Dynamics then?

You take the basic rules defined in the scrum guide and improve it with these 9 principles:

Scrum X, core principle
Scrum X, set the stage
Scrum X, everything is not an option
Scrum X, Decide
Scrum X, no never ending stories
Scrum X, human relations
Scrum X, balance is everything
Scrum X, what do you realy want?
Scrum X, set the pace

Now, you have all the tools to move on into agile and take care about:

Scrum X, from mechanic to dynamic

As conclusion, I didn’t addressed how to build a system in this post and nor what a system is. One think for you to take into account, that system works when decisions are taking into the system and not outside-in. If you are a scrum practitioner and your Product Owner isn’t part of the team. he or she is not in the system.

Heidelberg, May 1st 2019


Is agile possible in an SAP (ERP) or Business Process related context (Banks) possible?

Sitting in front on my computer and writing these lines let emerge in me an angel and devil fight. Should I push forward everything that doesn’t work or should I explain what works? What if people are feeling injured by these words? What if my customers are feeling offended by these lines? What if people are misinterpreting this post like a revolutionary manifesto? What if I lose most of my contracts?


Is it important to share my experience with fellows trying to balance with what they feel and what they feel? Usually, the feeling is that agile is feasible and the fact is that is terribly complicated… or not.

So here my humble insights coming from lots of problem-solving experiments with teams of developers, managers and leaders mostly in large banks but also with SAP S.E. I thank all these people for their trust and their passion on this challenge.

How everything usually begins?

Like everything, you start with a proposal, a first draft to explain how we might proceed:

the initial toolbox

This is an “appetizer”, this is the ideal world… when you know nothing about the context, the culture, the maturity and the “gremlins” or other “toxins”. This the picture of the CV, the certification paper that opens the door so that someone at your customer side cannot say that you don´t know your job.

Besides the toolbox and because you are a professional, you have to provide a timeline to estimate how much you will cost:

the magic roadmap

Even if in a bird view, this is about investing in a better future, most of the managers are cost killers but this is part of the game.

Even if this is mostly false because it is an assumption, I made myself a review of that roadmap (real one) two years later:

Review of the initial roadmap after 2 years

Distill Agile Mindset was “so so”, this means that you are still struggling with the simple agile ideas like self-management and prioritization. Why? There is magic here or people believing that once you have one or more agile coaches in your enterprise the job (agile mindset) is done. Hmm… It is acceptable that our clients need time to change, but I have to be honest by writing that human nature is what it is and most of the hints came from other agile coaches, or managers hiring other coaches, or “nominated” agile coaches and Head of agile without any experience of agility other than having once hired a scrum master, have watched something about agile on YouTube… Anyway, this is the part of change management that I don´t want to explain today.

Scrum was “so so”. Scrum was chosen as main framework and that’s fine. (Even if you believe in the magic of SAFe or LESS, you have to set up Scrum for the first 2 years). Framework has been considered as a “chocolate box” this means that if you are picking all the white chocolate and leave the black one, you are considering doing scrum. That’s totally wrong! It took a while to explain that scrum is a minimalistic organizational model working as a scaffolding to create agile dynamics. It´s not “by the book”, or “100%”, it is all or nothing. This point was only the pic of the iceberg, the real problem was resource allocation (this is the name to let individual working in several teams, 10% on this, 20% on that, 40% of those, etc…). You get it, agile doesn´t work in matrix organizations. So so, because it took around 2 years to understand that work flows in a team so that demand is balanced with capacity, and not collecting as much demands as possible and then chasing for people (cheap people in fact) to start the work and never achieve it. That is known by everyone in the company and all projects or programs are magically completed at the end of each year by changing its name (no sarcasm).

Continuous Integration was “what?”. This was completely skip away because Build has a budget, Run has a budget, Data has a budget, Infrastructure has a budget, Operations is mostly offshore third parties and nobody cares about Business or Service Desk. Budget means has a manager. Budget also means “manager´s power”. This is a war that you will lose.

DevOps was “so so”. Ok, more so than so in fact and that due to the previous paragraph. In reality, even in the Phoenix Project is on most managers desk, DevOps has been completely “trolled”. DevOps means now that the developers have to ensure Service level 1 and 2 (support) in the context I explained in the Scrum paragraph before.

Ok! Even this sounds a bit depressing, we have to adapt to the context and some old habits are quite complicated to change in big global organizations. And in a second hand, this also no finger pointing but just the consequence of a lack of purpose and overwhelming bureaucracy leading to reproduce obsolete processes for ever.

What is the traditional way of managing projects?

old school wrong project management lifecycle

This is the roadmap:

  1. Consulting & sales got a contract and a development agreement where both parts are trying to make a win. In reality, consulting & sales (c&r) are looking to get more in their “pipe” and expect to detect new opportunities for change (change requests) where they can charge to an higher price. (c&r) are selecting some project manager and introduce the contract to experts in order to create the first milestone of the contract: the blueprint. Ideally the blueprint consist of standard blocks. In reality, this is an opportunity to detect new “change requests” coming from experts and not from the client.
  2. Blueprint is quite interactive and usually the customer and some of its representatives are active. When blueprint ends a huge part of the project budget is consumed. In digital projects, “blueprint” is called “customer journey”, different names, same nature, same effects, same outcomes. Once the blueprint has been validated by the customer, this one is handed over to another team: the development team.
  3. Development. The development team is considered as a service provider and not a project team. The project manager hand over the blue print to the team. At this moment, all the experts and also the customer are no longer available for feedbacks. This is at this stage that usually people are remembering agile and are asking for help to ensure the delivery of what has been promised by tiers. The development team needs to understand rapidly what this is all about, usually no one is collocated, usually they are also working for one or two other project managers and some requests from different managers. After postponing the deadline one or two times, 70% of the development is ready for testing.
  4. Testing. The development team is handing over the tests (usually not written) to one or two testers in India who also working on something else. The project plan needs to be shorten because of budgeting costs reduction (another corporate department). So instead of 2 months they have 3 weeks.
  5. Delivery. The planned 3 weeks become 3 months and the project launch has again being postponed due to SOX Freeze, system unavailability. The project run over 300% of the budget, get close to one year overtime and the customer is just happy to get something done.

Note: indeed this a stereotype to explain what is coming now.

Lessons learned towards agile: agile is made for development only, that excludes the project set up, the blueprint, the testing and the delivery. That is just wrong regards project management, totally wrong regards scrum, and the only agility here is for c&s.

How should it looks like?

agile project management strategy for ERP & BPM

Contract are proceed as usual and one of the consultants might become Product Owner of that development. A scrum master is identified at the beginning and attend all the meetings to meet all stakeholders.

agile principle #1 : you plan it, you make it

The Product Owner and Scrum master are setting up the development team that is 100% dedicated to that project.

To avoid wasting time, the full Scrum team (PO+SM+Developers) are identifying with the customer and its users what the needs are:

agile principle #2: focus on customer and users

From that exercise, the team discover what the real needs are and the Product Owner is in charge to translate these needs into a vision.

agile principle #3: Product is not the voice of the customer. (S)he translates customers expectations into a vision. The customer has its own voice.

After 2 weeks, the team and they stakeholders gather during a Sprint Review and some options are shown and the customer decides what matters and choose one. The others are skipped away or destroyed.

agile principle #4: Requisite is waste

Then the team starts to develop with what they know and build on the top of it.

Every sprint end, the customer can come with change requests which be negotiated with the Product Owner ideally in front of the team.

How to work with experts?

Experts or SME are necessary but not at the project start. Due to their expertise biases, they will pull the project into the sole direction they know, their expertise. Genuinely it is not intentional.

SMEs are “floaters”, they are helping the team to gain certain knowledge. Their job is to transfer their knowledge to the team and coach it.

agile principle #5: cross-functional team members and SMEs as coach

Composition of a Scrum Team

Developing or integrating or configuring a business process has a particularity, it is addressing different customers for different purposes:

  • one customer for the end-to-end business process
  • several customers for the components addressed by that business process

The Scrum Team cannot be a Product or functional team, it is always an end-to-end process development team: that’s what needs to be developed right?

agile principle #6: all teams are end-to-end

end to end scrum team composition

One role has been added to that genuine scrum team ,the process owner.

If you are merging Product Owner and Process Owner you will lose your component customers. In this model, the Product Owner is in charge with both customers and build its development strategy based on components and process.

BPM, SAP agile delivery pace strategy

Components or features like in the figure beyond should be small enough to be completed during one sprint (max sprint length of 2 weeks) and end-to-end processes should be deliverable once a month.

End-to-end processes have to be decomposed from easy to complex so that the easiest can be release for customer testing as soon as possible. Then, like in product development, additional complexity can be added into the initial process in an incremental manner.

Product roadmap and development strategy recap

  • Sprints delivers PSI i.e. features
  • Releases delivers End-to-end processes incl. these features
  • focus is given to involve both customer and user since the beginning of the solution development.
  • Deliver standards from the easiest but most visible to the hardest.
  • Each release should be actionnable so that the users and customer can start a work around of the solution and provide feedback
  • Think about the integration of E2E processes.
  • Done means ready to deploy and fit to RUN.
  • Release phase is deliver standard and collect change and start custom

agile principle #7: The end-to-end (E2E) process is the outcome and not the input of a development process

Role of the Process Owner


  • aka member of the Scrum Team
  • as a team member, the process owner is self managed and cross-functional.


  • works with the Product Owner
  • works with the team
  • works with Process Customer


  • acceptance Test Driven Development (wikipedia)
  • think Test automation
  • perform acceptance test and/or facilitate user acceptance test workshop / Bootcamp


  • as a team mate, the Process Owner helps the team to reach the Sprint Goal also for works that are outside his/her comfort zone


  • not an authority
  • all team members have the same hierarchical level within the Scrum team, that’s the rule of the Scrum Game

Challenges for the Process Owner

  • identify the User in a end-to-end (E2E)process and create the User Stories
  • update the product roadmap with the Product Owner
  • identify the User/Customer for E2E process
  • define the persona aka User Role
  • collect User Stories from the Users
  • update the Product Backlog with the Product Owner
  • ensure or write the tests cases
  • ensure that the E2E process is INVEST (independent, negotiable, valuable, estimable, sized to fit, testable)
  • ensure the integration of E2E processes in a single process
  • update the process
  • E2E is part of Release DoD
  • create the definition of done (DoD) of the E2E process and work with the Product Owner to update the Release DoD accordingly
  • E2E has to be drawn and visible to all stakeholders
  • make the process visible from all stakeholders
  • use visual management and facilitation techniques to enhance the product backlog

Last recommendations

The challenge is to organize teams end to end and remove the illusion of expertise away. Another point is that you have always 2 different customers with different expectations: one for the process, another for the components of it.

Hope it helps.


%d bloggers like this: