Reading Time: 15 minutes

The Scrum-Land Survival Guide — How To Survive In Scrum-Land

Main Takeaways
Reading Time: 15 minutes Scrum-Land is a harsh and barren habitat to live in. It is difficult to enter Scrum-Land. And if we stay in Scrum-Land, we always have to inspect, how to make our living more comfortable and easier. However, there are some guidelines to make life easier.

 

For more than 10 years I work with teams or executives of SMEs up to Fortune 500 companies to adopt or move towards Agile. Every engagement was different and challenging. But all had in common, that after a certain time, the only one crucial question all asked: "Why should we follow Scrum, we did better in our old way of working?" — "WTF, we get no big picture, why we should work in this shitting new mode?" — "What's the benefit of doing Scrum?" — "To make it short: Scrum doesn't work for us." – (Verwijs 2014)

Over time, to answer my teams and executives all these questions, I developed a playbook I present in this post: the Scrum-Land Survival Guide. In this article, I describe the Scrum-Land Survival Guide and share my personal experiences and learnings I made to answer all the aforementioned questions.

In this post, I try to answer the question of all the questions: "Why should a company adopt the agile way of working?"

Allow me to phrase it in a metaphor: we live on the mainland currently. For more than 40 decades, we achieved with tedious work a comfortable living. But suddenly now we are confronted with a hostile environment characterized as VUCA. In this world, decisions are volatile, uncertain, complex, and ambiguous.

 

The Scrum-Land Survival Guide

Scrum-Land is a harsh and barren habitat to live in. It is difficult to enter Scrum-Land. And if we stay in Scrum-Land, we always have to inspect, how to make our living more comfortable and easier.

The Scrum-Land Survival Guide consists of 4 parts. First, I show you the criteria for whether to stay in our beloved, used (working, living) environment or to move off to new, foreign, and unknown strands. In the second part, I show you good arguments to leave your old habitat and move to the foreign island called Scrum-Land. The third part argues whether to stay or leave Scrum-Land. And finally, if you decide to stay in Scrum-Land, the fourth part gives you tips and tricks to survive and to make your living in Scrum-Land easier.

  1. Identify the Decision-making System you live in.
  2. When To Enter Scrum-Land.
  3. When To Leave Scrum-Land.
  4. Staying in Scrum-Land: Describe Your Product Properly – Keep Your Focus – Keep Your Goals! – Plan as Team Daily and Stick to it – Find Better Solutions

 

1. Identify the Decision-Making System you live in

For more than 20 years the corporate world is changing. The business models are changing. We have companies running their business with strong hierarchies run more than 40 years in a command-n-control style. We have enterprises trying to flatten the hierarchy, empowering individuals, and letting them take ownership, and we have lean startups, increasing the time to market time. And we have the hybrid way: long-established, hierarchical companies running flatten, empowered, lean satellites (incubators).

And the markets are changing as well. Established markets vanished, and new markets emerge. Seventy years ago the big leading companies made their fortune in creating and selling physical goods: oil, cars, kitchen machines, washing powder, etc.
End of the last century physical goods became more and more electronic devices: computers, mobile phones, PDAs, and iPods. In 2007 Steve Jobs released the first iPhone. By the end of 2009, iPhone models had been released in all major markets.
Starting in 2000 the market was dominated by tech companies that made their fortunes on digital assets, such as online marketplaces, streaming platforms, search engines and social media. And today, in 2022 the big tech companies and the digital market are struggling.

Hand in hand with the changes in the business world our way of working changed as well. From assembling physical parts into physical products it became more and more knowledge working: creating content and digital assets. In many fields, the working environment becomes volatile, uncertain, complex, and ambiguous. In the mid of the Nineties last century, we entered the VUCA world (volatile, uncertain, complex, and ambiguous) definitely.

To decide which business model fits us depends on answering the following questions.

  • "How stable is our working/living environment?"
  • "How secure is it?"
  • "How volatile is it?"
  • "How uncertain is it?"
  • "How fast do we have to react on opportunities and threats?"
  • ...

 

Rumsfeld-Matrix

 

Unknown unknowns

 

"There are unknown unknowns“ is a phrase from a response United States Secretary of Defense Donald Rumsfeld gave to a question at a U.S. Department of Defense (DoD) news briefing on February 12, 2002, about the lack of evidence linking the government of Iraq with the supply of weapons of mass destruction to terrorist groups.

When analysing Donald Rumsfeld's speech in detail, we identify four different topics:

  1. Known knows — issues we are aware of.
  2. Known unknowns — (expected or foreseeable conditions), which can be reasonably anticipated but not quantified based on past experience.
    Known unknowns result from recognized but poorly understood phenomena.
  3. Unknown unknowns — phenomena which cannot be expected because there has been no prior experience or theoretical basis for expecting the phenomena.
  4. Unknown knowns — Donald Rumsfeld potentially didn't intend this point, but it was depicted by Slavoj Žižek, a Slovenian philosopher, cultural theorist and public intellectual.
    Unknown knowns are topics we intentionally refuse to acknowledge that one knows. Unknown knowns we do not like to know. The Unknown knowns are situations or experiences we want to push to the back of our minds. —

 

Stacey-Matrix

Stacey-Matrix

Ralph Douglas Stacey, professor of management theory at Hertfordshire Business School, UK, invented the so-called Stacey-Matrix. In its original form, the Stacey-Matrix deals with decision-making in complex organizations. Today, the Stacey-Matrix is often combined with the Cynefin framework.
The matrix depicts on the vertical axis WHAT a project should achieve (the requirements). On the horizontal axis, the matrix shows HOW the goal could be achieved — by which technology, methods, frameworks, etc. In more detail, the WHAT axis spans from clear requirements to unclear, ambiguous ones. The horizontal HOW axis spans from known to unknown technologies.

If the WHAT is clear and also the way to get there (the HOW), then the project is classified as "simple". Few surprises are to be expected in the project, experience and routines can be drawn upon, and the process is known or easily predictable. In a simple environment, we should "look, classify, deduce, react" (or "simply do it").

The Stacey-Matrix classifies a project or enterprise as "complicated" the more unclear the HOW and/or the WHAT becomes. The number of variables increases to the point that they are no longer easily manageable. However, the project is still easily predictable because the variables follow a linear causality. In a complicated environment, we should react best in an inspect-analyze-respond mode.

With increasing uncertainty of the HOW and WHAT the enterprise shifts from complicated to "complex". In this case, there are very many risks, requirements are not known at all or not down to the last detail, and they interact with each other. It is also not certain with which methods and techniques the project goal can best be achieved. We cannot be predicted what exactly will happen. In a complex environment, we should react best in an agile, iterative mode in a probe-inspect-react way.

The Stacey-Matrix calls situations where as well the goals, requirements and possible solutions are unclear, "chaotic". Chaotic environments have a high risk of failure since they show no recognizable patterns.

 

Cynefin Framework

The Cynefin Framework, created by David Snowden in 1999, is a framework for sensemaking when making decisions. It draws on research into systems theory, Complexity theory, network theory and learning theories. It helps to identify how we perceive situations and make sense of our own and other people's behaviour.

In Cynefin there are four reaction schemes

Cynefin Framework

Cynefin Framework

  1. Clear: sense – categorize – respond
  2. Complicated: sense – analyze – respond
  3. Complex: probe – sense – respond
  4. Chaotic: act – sense – respond

Cynefin Framework – Clear

The Clear domain is characterized by stability, rules in place (or best practices), and cause-and-effect relationships clear to everyone. The right answer is self-evident.  It represents the "Known knowns".
To react in such a situation is to "sense – categorize – respond"

 

Cynefin Framework – Complicated

The Complicated domain may contain multiple right answers. Although there is a clear cause-and-effect relationship, not everyone can see it. This is the field of “Known unknowns”. The cause-and-effect relationship requires analysis or expertise; there is a range of right answers.
To react in such a situation is "sense – analyze – respond".

 

Cynefin Framework – Complex

The Complex domain represents the "Unknown unknowns". Cause and effect can only be deduced in retrospection, and there are no right answers.

"In a complex context, right answers can’t be ferreted out at all; rather, instructive patterns emerge if the leader conducts experiments that can safely fail. This is the realm of “unknown unknowns,” where much of contemporary business operates. Leaders in this context need to probe first, then sense, and then respond.”

— Snowden, David J., Boone, Mary E. (2007)

To react in a complex context we need to "probe first – then sense – then respond".

 

Cynefin Framework – Chaotic

In the Chaotic domain, cause and effect are unclear. It is the realm of the "Unknowable". And it is futile to search for the right answers. The relationships between cause and effect are impossible to determine because they shift constantly and no manageable patterns exist. Action — any action — is the first and only way to respond appropriately. In this context, we should apply the pattern: "act–sense–respond".

 

Cynefin Framework – Confusion

The Confusion domain in the centre represents situations where there is no clarity about which of the other domains apply.  In earlier versions of the framework, this domain was called disordered. By definition, it is hard to see when we do not know which domain we should apply. To react in this context is to break the situation into its constituent parts and assign each to one of the other four realms.

 

Communicate Your Reaction Scheme

In our private and business life we often are faced with new situations we have to make critical decisions or plans on how to handle them. In systems thinking terms, we have to deal with systems, systems of systems and often with adaptive systems yet. With these frameworks, we can derive four types of possible responses in case of these unexpected events.

  1. In the area of simStacey Reaction Schemeple events are Known knowns. The best reaction pattern is routine and sensing, categorising, and then responding to the event.
  2. In the area of complicated events are Unknown knowns and Known unknowns. This is the domain for experts. After sensing the event, they analyze it and then react.
  3. In the area of complex events are Unknown knowns. In this domain, we do not have any previous experience with new upcoming events. The best reaction to new situations is experimenting and probing for a reaction, and then responding to the reaction.
  4. In the area of chaotic events are Unkownables. Here we can not perceive any recognizable patterns. The best reaction scheme is doing anything, sensing the corresponding system's reaction, and then responding to it.

In the case of simple and complicated systems, we can perceive recognizable patterns and causal relationships. We can understand them, and we can create plans and decisions to follow up. In complex or chaotic systems we can not observe unique causal relationships. Instead, we are faced with stochastic environments where we can count on probabilities only. In these environments, we can only run experiments to challenge system reactions which we can perceive and react to. The most pushing area is the chaotic one. Here we even can not plan experiments thoroughly. The most important is to do something immediately and observe what happens next.

For our decision making it is crucial to identify the reaction scheme, we are working with. Only by communicating this as fast as possible and suitable, we can manage our and our stakeholders' expectations properly.

 

2. When To Enter Scrum-Land

Tessa, CTO of DataCorp, Inc. rushed into the team room and slammed the door. It was a sunny, warm day in May. The team, Paul, Ann, Sriram, Huw and Sarah knew immediately there was trouble.
Everyone looked at Tessa. Tessa slowly calmed down, took a deep breath, and said, "We have serious problems."
"What happened?" asked Huw. "I got the latest figures from sales and controlling" replied Tessa. "Realy, that bad?" asked Ann.
"Worse," said Tessa, "After all, we knew our product was 2 months late to market. On top of that, our intended target audience is not adopting the core features. Sales are 30% behind the forecast."

"Shit," Paul whispered softly.

"Okay, why were we so wrong?" asked Tessa.
"The customer kept changing the requirements!" exclaimed Ann. "And the competitors reacted incredibly fast!" shouted Paul. Huw exclaimed, "Always unclear was to me what kind of problem we were supposed to solve." Sarah asked, "Did we all always know who we were working and developing for, who is our customer/user?"
"Who were our actual competitors, and what features were they developing?" exclaimed Paul, "Yes, and how did the market behave?" added Siram.

"But why were we always lagging behind the competition?" asked Tessa.
"Because I always have to wait so long for our tests," said Paul. "It always takes forever for a pull request to go through," replied Sarah.
"What's about this VUCA buzzword?" asked Paul. "You mean this thing of volatility, uncertainty, complexity, and ambiguity?" Tessa asked. "Yup," Paul replied.

"Ok, let me summarize," said Tessa "our company is lagging behind our competitors due to overwhelming processes, and lack of customer resp. problem understanding. Therefore we can't respond quickly enough to changing customer needs and market conditions." The team agreed.
"We need a new working model" Tessa concluded. The next months were covered with many meetings.

Stacey Matrix Scrum EnterWhy do I tell this story? — If we need to check which reaction scheme we live or work in and whether it is still fit for purpose, the following questions will help:

  • "What business are we in?"
  • "How do we currently work?"
  • "What problems do we have?"
  • "What are we trying to build?"
  • "Who are we trying to build that product/service for?"
  • "How do our competitors and the market behave?"
  • "Are we in a complex, interrelated and interdependent industry?"
  • "Are we experiencing great uncertainty, volatility, complexity, and ambiguity?"
  • "Can we follow a formula for success or is each new initiative or item unknown?"
  • "Do we understand many of the variables that may impact our organization, or must we discover, even sometimes as we move along, what those variables are?"
  • "Are people required to bring their brains to work, more so than their hands?"

In addition, considering the following mental models and how they shape your decision-making is also helpful.

  • Sunk Cost Fallacy – ‘throwing good resources after bad’.
  • Loss Aversion – people are averse to losing things. Understand this bias and you’ll be able to notice when it is shaping your decision-making process.
  • Circle of Competence – what is the boundary between what you understand and what you don’t? Knowing the difference between the two is essential.
  • Hanlon’s Razor – Do not seek negative intent if you cannot be sure it exists.
  • Inversion Fallacy – struggling to work out what ‘good looks like’ – ask people what the opposite looks like and reverse the answer to ‘define good’.
  • Survivorship Bias – be sure you have a complete data set before you start making decisions based on it.

 

We should consider to adapt our working model to be Complex, if it is still being in the Single, or Complicated domain, whereas the reality we are faced with, is complex.

There is no need to change, if the product market environment is complex, but we live in a niche with quite stable parameters.

 

Stacey Matrix & Agile FrameworksThere are several Agile Frameworks to adapt our working model to different complexity domains.

 

3. When To Leave Scrum-Land

Stacey Matrix Scrum Leave

After one year in Scrum-Land the desired benefits had not materialized, and Tessa and the management board toyed with the idea of leaving Scrum-Land again. Tessa asked herself, whether there are any signals, to down-size their working model, or to move back to the Complicated and Simple one. After some investigation within the teams, Tessa came up with the following indicators of when to step back.

  • There are fewer disruptions in delivering increments due to increasing product maturity.
  • The team doesn‘t work in an explorational way anymore.
  • The “big features” are already available.
  • Reduced volatility results in an expanding planning horizon. At least, there is a temptation to plan further ahead.
  • There are growing difficulties in creating team-unifying Sprint Goals; there is a growing number of Product Backlog items that cannot be clustered under one topic.
  • Stakeholders gain more trust in the team’s capabilities.

But is downsizing a really good idea? — Not for me. Why should we do it? — We have already invested a lot of money and employee engagement to establish the new working model. There is no reason to step back. Numerous studies have shown the benefits of agile working: companies react faster to external changes, and at the same time employees are more motivated by transferring more responsibility.

However, if these benefits don't show up, it's not because of the new way of working: Scrum, Kanban, etc. Rather, it is due to its implementation. And that is no reason to demonize the new working model. Rather, we need to change implementation to achieve the benefits mentioned.
It is also of no use to replace one agile working model with another, e.g. to switch from Scrum to Kanban or vice versa, if we do not eliminate the central issues that hinder agile working.

 

4. Staying in Scrum-Land

There was a big discussion on the management board about whether to leave or stay in Scrum-Land. After a while, Tessa made her point: "Maybe the tool isn't wrong, but our implementation."  Suddenly there was a dead silence in the room. "Yeah," said Tessa and cited the Scrum Guide:

" The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. [...]

Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary."

Scrum Guide 2020

Tessa continued, "This openness allows us to bring in our own working procedures and methods. We should define guidelines to improve the new working model. And we should continuously inspect and adapt them."

After some sessions, brainstorming, and retrospectives with the teams, everybody agreed to the following recommendations.

  1. Describe Your Product Properly
  2. Keep Your Focus! – Keep Your Goals!
  3. Plan the Team Daily and Stick to it as Team
  4. Find Better Solutions

 

"That is nice advice. But what does it mean for my daily work?" asked Huw. And Sarah asked, "How should I implement it in my working?"
Tessa asked the teams to refine in breakout sessions this four topics into more detailed working agreements.
Here are the results of each session.

 

1. Describe Your Product Properly – Product Goal

In the Simple and Complicated domain, we work with detailed specifications — well-known as requirements. Requirements specify in detail as much as possible, how the product should be constructed to show the upfront specified behaviour. In contrast, in Scrum-Land the so-called "Product Backlog" is the only source of truth about how the product finally should look like.

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

[…] 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.”

Scrum Guide 2020

The so-called Product Goal is the source of the Product Backlog. The Product Goal describes informal the product's impact. It is a high-level agreement between the product development agency, its sponsors, stakeholders, and potential users and customers.

To survive in Scrum-Land follow these good recommendations to implement your Product Goal.

  1. Refining and Estimating is an ongoing process – continuously during the Sprint, at least in planning the next Sprint. – Identify which information you miss. Do a Spike(y), and ask others.
  2. Update Refinements & Estimates as soon as you get a better understanding of the work to be done. – Don’t waste time detailing what would be done in 3 months.
  3. Don’t oversize the Product Backlog.
    Not more items than the team can handle in 3-6 Sprints.
  4. Don’t detail and estimate EVERYTHING. Only the items going to the 1-2 next Sprints.
  5. Don’t be too UNSPECIFIC. Only Headlines or no acceptance criteria are not sufficient to understand what to do. – Update continuously, see (2 & 4).

 

Now there are numerous wolves in Scrum Land that make it difficult for us to survive.

 

2. Keep Your Focus! – Keep Your Goals!

  • Scrum Teams don‘t commit to delivering prescribed work. – They commit to creating value: “Find a way to reach the Sprint Goal best!”
  • Scrum Teams commit
    • to build the right Product (Product Backlog):           Product Goal                (Product Owner)
    • to build the Product right (Sprint, SB):                      Sprint Goal                    (PO, Developer)
    • to build the Product right (Increment):                     Definition of Done        (Developer)

 

“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).”

Scrum Guide 2020

3. Plan the Team Daily and Stick to it as Team

  1. Keep the Daily short! – The purpose of the Daily Scrum is to (a) inspect progress toward the Sprint Goal, (b)  adapt the Sprint Backlog as necessary, and (c) adjust the upcoming planned and unplanned work. – No status reporting, only yesterday’s important achievements.
  2. Define a clear goal to achieve at the end of the day and plan collaboratively as a team how to reach it.
  3. Collect during the day unplanned work popping up (new ideas, bugs, stakeholder’s dreams) only as Sprint backlog items to be discussed in the next Daily.
  4. Never, ever, start working on unplanned items without informing & discussing them with the team!
  5. Only the team change workload and prioritizes, NOT the individual!
  6. Always ask yourself: “Does this count toward the Sprint Goal?”
  7. Prioritize and potentially post-pone additional work properly. Start new work or over-engineering the Sprint Goal only if it doesn’t endanger your evening and Sprint commitment.
  8. Carry-Overs to the next Sprint
    • Is it necessary? – Is the work left-over really needed?
    • What did we learn about the work left over? – What did we learn about the initial slicing of the work?

 

“Every yes you say is a responsibility you get. And every no is a decision you make.”

James Clear, Author of “Atomic Habits”

4. Find Better Solutions

  1. Don’t take everything for granted. – Be courageous to ASK! – “Why do you need this specification/ characteristic?”
  2. Don’t deliver features showing alternatives.
  3. Always challenge the status quo.

 

 

Further Reading

: Andreas Wagner via Unsplash.com • Quotemaster.org • Wikipedia.org, .