During the past weeks, I had several conversations with people and noted typical false dichotomies like a team member is either a generalist or a specialist, whether a team is either co-located or working fully remotely, and whether an organization is agile or disciplined. This thinking in extremes seems routed deeply in the mind of many people. Let’s explore those deeper.

What is a dichotomy?

A dichotomy is a partition of a whole (or a set) into two parts (subsets). In other words, this couple of parts must be jointly exhaustive: everything must belong to one part or the other, and mutually exclusive: nothing can belong simultaneously to both parts (source Wikipedia).

A false dichotomy happens when people believe that the solution is either A or B (black or white) and that there is nothing in between (like millions of levels of grey).

Example: Either I speak Finnish fluently or I don’t speak at all.

Multi-team Scrum

What is multi-team Scrum? In a multi-team Scrum setup, several teams are working together on the same customer product by using Scrum as a method. Thus they share one common Product Backlog, which is prioritized by one Product Owner, are having the same cadence, and (hopefully) produce at least one potentially shippable product increment at the end of every sprint. In order to do this, those teams need to be cross-functional, cross-components, stable, and long-lived and they can convert a Product Backlog Item into a done product increment without a dependency on another team (in terms of waiting for another team to finish their work first).

False dichotomies in organizations

The following false dichotomies appear over and over again in organizations, and I want to discuss them here at different levels:

• Individual: A team member is either a generalist or a specialist
• Team: A team is either co-located (in the same room) or all are remote
• Organization: Either an organization is agile or disciplined

Individual: A team member is either a generalist or a specialist

One of the greatest skills of humans is learning. Reflect for a short moment on what you have learned in your life already. These include basic things like reading, writing, riding a bicycle, swimming, driving a car, using a PC, using applications, and on and on. Now, what happens in many large organizations? People are denied this skill once they enter the office building. They are told you must stick to your one area of expertise.

What we need in this complex development environment are people who change from being solely programmers to becoming product developers, who understand the customer’s problem. This means that a programmer also learns e.g. analysis, testing, and maybe some other domains. Of course, the person needs to ensure not to lose his core competence, yet in a real team, we help each other in getting items done. A typical real-life case was that Front-End developers were able to work on the back-end. What was hindering them was the fact that they did not have permission. Another example would be that assuming you have manual tests, almost anybody with product knowledge can click through test cases, and furthermore, developers help the testers to automate tests. 

Learning is a natural part of life, let’s create a structure in which people can learn and have fun doing so.

Team: A team is either always co-located or multi-team Scrum is not for us.

Let’s understand first the need for co-location (co-location means the people are sitting in the same room). Assuming you want your team to become a jelled, high-performing team that is capable to do complex design, solving difficult customer problems, and outlearn your competition in the long run?

Furthermore assuming that you have the same set of people, competencies, and skills to start with, then ask yourself, is it more likely that a co-located team will learn faster, learn more effective and efficient, compared to a team structure where some team members are located elsewhere (let’s call them dispersed teams). Most likely you will agree. 

Why is this so? Because when we learn in a group, we seem to learn both faster and more compared to being alone, trying to understand the issue on hand all by ourselves. You know the sentence ”the whole is greater than the sum of its parts” – this is what you can achieve in a co-located team.

You might have good reasons why you have dispersed teams, maybe some competence is not available at the team’s current location, and learning those required skills might take far too long. Thus hiring an expert sitting somewhere else sounds feasible, however, what will this do to our idea of having high-performing teams? 

Most likely this team will work somehow. The more you have dispersed teams, the more you will need to invest in jelling this team by e.g. frequent traveling, modern infrastructure, and collaborative tools in order to move this team towards a better-performing team. In the worst case, those overhead costs will eat up the benefits you thought of originally. 

Anyway, as a part of continuous improvement, you want to have as many high-performing teams as possible, and co-location is one of the important factors to achieve that.

Organization: Either an organization is agile or disciplined

Based on my observations, the average organization has the illusion that the organization is disciplined. It appears disciplined because the discipline is enforced through hierarchy and related thinking stemming from scientific management methods by Taylor. 

Introducing multi-team Scrum requires a high degree of discipline as seen in these few examples. The Sprint length is constant, and not extended at all, not even for half a day. I have heard so many people complaining about how strict and rigid Scrum is. Once you vary the Sprint length you open the path to all sorts of sloppy behavior, and the exceptional extension becomes the norm and becomes longer and longer. 

All teams follow the same cadence so that at least at the end of a Sprint, the organization can produce a Product Increment where all teams have integrated their features. Imagine your product organization consists of 10 teams. The product integration needs to go across all those teams. This is very hard for beginners, and it requires a lot of will and a disciplined way of working to get there.

The fact that only the Product Owner will give work to the teams is often another disciplinary problem for the project- and line managers. Those managers cannot interfere with the teams and individuals as they used to.

Last but not least, one of the most difficult changes, when an organization is moving towards becoming an agile organization, is the new role of management. Instead of telling people what to do, setting KPIs, and targets, now they need to create the conditions that the teams can collaborate in their work towards a common product goal.

There certainly are many more examples to demonstrate that multi-team Scrum requires indeed a high degree of discipline if you want to become an adaptive organization. I also hope you recognize that many of us (even me, I admit) still fall trap to false dichotomies. Through continuous improvement, I am trying to become more and more aware of those traps and find ways to avoid them.