Are flexible team structures good or bad? On the one hand, (mostly) management wants flexibility in team structures so that the right people can work on the most important issues. On the other hand, stability over time is necessary to build a high performance team. What do we do with this clash of objectives? Flexibility - Where does the need come from? The need to build teams flexibly arises precisely when the skills needed to address a topic do not match the skills of the team.

A work in progress limit helps to keep focus and deliver the desired value to customers faster, instead of working on many things in parallel over a long period of time. Figure 1 illustrates the idea (see The Illusion of Progress - Non-Productive Busyness). Figure 1: A WiP limit creates focus and leads to faster results. But what if it doesn’t work that way? What if you focus on one topic, but it still drags on for a long time, as shown in Figure 2?

What do I mean by ‘process fiddling’? Implementing ideas as they come in. You hear or read something and implement it in the company or team, sometimes with external support, without considering whether the prerequisites are actually given. For example, it makes no sense at all (in my opinion) to implement a discovery delivery process in the team if you don’t have a true cross-functional team with a certain maturity.

We’ve looked at literature on various topics on the blog before, such as legacy code or dysfunctions in teams. Team Topologies deals with organizational design and team interaction, wich are also essential for effective software teams. Now you might think this is mainly a topic for managers and organizational developers, but the underlying principles apply to all team members in software development teams. Team Topologies was released in 2019 and addresses a core problem in modern software development: how can we continuously deliver new features quickly and with high quality?

Ineffective Busyness If a team works on too many topics at the same time, employees will eventually specialize in individual topics. This has disastrous consequences for the team: Knowledge silos: If one person drops out, the topic is at a complete standstill until he or she is back and can continue working. Suboptimal solutions: If only one person is working on a topic, there is no discussion about different solutions, there is no pair programming and reviews become shallow.

A Leadership Fable — Kathryn & her Team Most of the book comes across as a fictional business novel. You may like that or not, but it helps to visualize the conflicts and issues involved in teamwork. The book deals with CEO Kathryn and her leadership team at the fictional Silicon Valley company DecisionTech, Inc. Kathryn has been freshly appointed as CEO since the company — 150 employees in size, some of the founders still on board themselves — is piling up more and more internal problems.

Matrix organizations have severe problems Usually, management structures are organized by discipline. That is, designers report to a head of UX, backend developers to a head of backend, and so on. The managers are responsible for several employees in different product teams (see Figure 1) and take on both management tasks (employee development, organization and planning, salary negotiations…) and leadership tasks (mentoring and coaching, creating vision and motivation). This setup brings some inherent challenges with it.

The Starting Point Our team had reached a size with over 20 members making it impossible to work efficiently. The usual Scrum meetings (Refinements, Estimations, Planning, Review and Retro) took longer and longer and felt incredibly dull. Many issues were discussed in detail during these meetings, but were often only relevant to a small group. Due to the size of the team and everyone’s strong desire to move quickly, a wide variety of topics had crept in, further fueling the situation.