by Bas Vodde
This article highlights practices to avoid and alternatives to try, so you can understand where your teams stand today and identify collaborative practices worth adopting.
How do teams work together to build a product? In self-managing teams, how they work is up to the team. That doesn’t mean they have to figure it out from scratch — teams can and should learn from other teams’ earlier experiences. I’ve seen common practices emerge. This article explores some of these practices and groups them in three categories:
The more collaborative practices are encouraged but not “for collaboration’s sake.” There are reasons for preferring collaborative practices:
We’ll dive into some practices to avoid and ones to try so you can explore where your teams are now and pick some collaborative practices to try.
These practices often lead to knowledge silos, overspecialization, and high levels of work-in-progress. They often feel productive, but this is only true when just measuring individual tasks rather than system performance. Unfortunately, these practices are very common, leading people to believe that this is normal and ok.
At the beginning of the Sprint, team members choose the item they are individually going to work on. During the Sprint, they work fairly independently on their own items.
Work in progress during the Sprint is very high. Teamwork and learning are very low.
The items selected are done in a sequential, waterfall-ish way. This often follows the sequence of UX design -> Implementation -> Test. The team still has explicit roles related to these activities. Because of the work imbalance in the Sprint, this usually leads to the UX work being done before the actual Sprint starts (during a previous Sprint) and the test work being done during the next Sprint.
There is no real team, there is no real Sprint.
Work in progress during the Sprint is very high. Teamwork and learning are low. Lead time of items is typically 3 Sprints.
The team has specialized team members that stick to their specialization strictly. Common examples are front-end development, back-end development, devops. The team splits each item into tasks and each team member only picks up the tasks they are specialized in. When an item is not yet finished but the tasks left are not for the person with a particular skill, then that person just works on a different item that does require that particular skill.
Work in progress during the Sprint is high. Teamwork only happens at hand-offs between specializations and therefore learning is low.
The team works on a larger feature that takes many Sprints to complete. Instead of breaking down the feature into vertical slices that fit into Sprints, they break them down into tasks and plan for many Sprints in a row. They basically ignore the Sprints and just work on the feature as if it is a larger project. Every Sprint, they simply officially pick up the next tasks. The Sprint becomes nothing but a reporting ritual.
Work in progress is high. The product isn’t really in a shippable state at the end of a Sprint, thus the lead time is high. No opportunity for early user feedback. Usually people work individually on their part of the larger feature.
The scope of the team is small such as teams with a small product definition, or micro-services mapped to team, or “front-end team”. The items on the backlog also require work from other teams and therefore the team is often blocked. When they are blocked, they just move on to another item until the other team did their part of the work.
The scope of the team is often defined organizationally, so changing this would require a change in team structures (see “Collaborative context” below). When changing team structure is not a possibility yet, some teams make the dependency a bit easier by changing the other teams’ component code. The dependency then changes from waiting for the other team to make the change to waiting for the other team to review and approve the change.
Work in progress is high. The items are often not in a shippable state.
These internal team practices lead to shared work and a shared context between the team members, which, in turn, leads to more collaboration. These practices (1) reduce the work-in-progress leading to increased flexibility and (2) increase knowledge sharing and learning leading to reduced knowledge silos and speedier onboarding.
These practices might feel less productive as they often include having multiple people work on the same task/context but the shared context and knowledge spread leads to better system performance.
Collaborative teams usually don’t pick one of the collaborative practices but combine the practices within a Sprint based on preference, availability, existing knowledge, or item complexity.
During Sprint Planning 2, the whole team discusses the design and implementation of all of the items in detail. Through this, each team member has a thorough understanding (a shared vision) of what needs to be done for each item. They create fine-grained tasks (that can usually be completed within a few hours) that are used for dividing the work, visibility and synchronization. The team decides to work item-by-item and each team member picks tasks of the same one (or a few) item(s). The team continuously talks to each other and synchronizes their work. This works especially well with continuous integration and trunk-based development as the team needs to continuously share their work with each other (see “Collaborative context” below).
Team collaboration is high even though everyone still works alone.
Work in progress is low - multiple tasks in progress but they all belong to the same item.
The Daily is for the team to take a shared responsibility and manage their work. When a team works close together with fine-grained tasks created in Sprint Planning 2 then it is not uncommon for the team to have multiple dailies during the day. The dailies become quick sync points where everyone shares what they’ve done so far, the team looks at what is left for an item, and decides who picks up what to wrap up items and keep the WIP low.
When working closely together in a Sprint with fine-grained tasks there is often a lot of coordination going on between the team members. Sometimes this leads to the team splitting into two sub-teams working on their own items, which increases the WIP and decreases collaboration. A better alternative is for the team to start pairing. The team still does thorough Sprint Planning 2 with fine-grained tasks (usually a bit bigger now) and then pairs pick up tasks for the same item.
Work in progress is low. Team collaboration and learning tends to be higher than when everyone works alone.
The team works together on one main computer on the same task at the same time. One (or a pair) is the main driver with the others steering, thinking, discussing and providing input. The non-drivers often do use computers but mostly for research for the item at hand. There is always exactly one item in progress. Mob teams often keep Sprint Planning 2 short, or skip it, because they can do that right before the start of the item.
Mobbing might feel absurd to people who consider development mostly typing. But the heart of development is learning and problem solving, which are activities better done together with more heads.
Work in progress is always just one item. Team collaboration is extremely high as the team only works on the same task, on the same context.
The setup is similar to mob programming except that not everyone works on the same context at the same time.
The team works together on one main computer with one (or a pair) driving the item that they are working on. This person (pair) is keeping the overview of the progress in the item they are working on. The other team members are working individually (or in pairs) on tasks of the same item. The main computer is where the overview of the progress on the item is visible and small side tasks are done by the individual (or pairs) that are sitting in the same room.
Work in progress is still usually just one item. Team collaboration is high, but work is a bit more parallelized than with mob programming.
When working closely together as a team, interruptions cause the whole team to switch context. Therefore, teams that work this way often select one team member (sacrifice one team member) to deal with interruptions such as requests, urgent defects, or explanations to other people or teams. Each Sprint, a different person gets sacrificed.
These practices aim to increase the work and context sharing between different teams, thus avoiding individual team knowledge bottlenecks. When the teams’ scope, knowledge and collaboration increased then it also enables working truly in order of business value without being restrained by the individual teams’ specialization.
When working with multiple teams, ensure that teams do not decide what they’ll be doing before the multi-team Sprint Planning. When teams do ‘preselection’ of items then the multi-team Sprint Planning is not much about collaboration but about ensuring that my team can get their items. Leaving it completely open which team will work on what leads to cross-team discussions about which team can best pick up what item and how to help each other. For this to work well, the teams will need to pick items in priority order, and the priority should be determined by importance (rather than current teams’ skill or availability).
When there is no preselection, then that doesn’t mean that the teams cannot have a preference. They still can! Just in collaboration.
This practice helps to avoid teams siloing into their area and thus increases multi-team collaboration. It creates a whole-product focus.
Maximizing dependencies is when teams, in Sprint Planning, purposely select different teams for closely related items. This is opposite to the typical behavior where one team takes all similar items for themselves so that they can independently work on them. When maximizing dependencies, the teams are looking for opportunities to collaborate cross-team (for learning, for fun, to reduce knowledge bottlenecks) by distributing closely related items over multiple teams.
Cross-team collaboration increases a lot when they share the same work context. They almost become one team.
Sometimes the work is so strongly related that the teams decide to truly work as one team, and, for one Sprint, merge the two teams to one larger one. This comes with its own challenges of having a very large team. When the teams do decide to do a temp merge, this usually also involves cross-team pairing to maximize the cross-team knowledge sharing.
When teams work together across the product, it is useful to have a shared view of the product design and architecture and to know which teams will work where in the system. This is what a multi-team Sprint Planning 2 tries to achieve. All teams start the Sprint together with Sprint Planning 2 where they discuss the current architecture and where which team is going to work in the current Sprint. After this shared architectural discussion, the teams do their individual Sprint Planning 2 within a shared space so there is opportunity for quick synchronization between the teams.
When selecting items in Sprint Planning 1, it frequently happens that a team needs knowledge from people in another team. One of the easiest ways to get that is by having individuals (or sometimes the whole team) join the other team’s Sprint Planning 2. They together go through the item the team requires more knowledge about. After that, the visitors return to their own Sprint Planning 2.
Traveling means a team member joins another team full-time as a normal team member (not a consultant) for at least one Sprint and then returns to their original team. Traveling enables explicit and accidental knowledge sharing between teams which leads to closer cross-team collaboration.
When starting a new roadmap item that requires significant learning, or when having to deal with a lot of (external) communication then this responsibility could be explicitly picked up by one team over multiple Sprints. This team then becomes a leading team. They should keep an overview of the progress of the item, the learning towards the other teams, and the (external) coordination.
This practice is a double-edged sword and other solutions should be preferred. A leading team does sometimes still lead to over-specialization or to the other teams feeling disempowered as the items are not theirs. It doesn’t have to result in that, but care must be taken of these dynamics.
Collaborative practices succeed in a collaborative context and the same practice fails when the surrounding context isn’t supportive of collaboration. The topic of what makes a collaborative context would be an article, or a book, or a book series, on itself. However, there are a few aspects I’ve found especially impactful that I’d like to mention in this article. They are related to technical practices, team structure, and management behavior:
The adoption of agile engineering practices, such as continuous integration aka trunk-based development, test-driven development, and continuous refactoring are essential to enable closer collaboration in teams. These technical practices and team collaboration patterns reinforce each other. This shouldn’t come as a surprise as they have similar origins in Extreme Programming. An exploration of the relationship between technical practices and team dynamics can be found in this talk about technical practices and Scrum.
Especially the cross-team collaboration practices assume a shared context through cross-team shared code ownership. Most organizations align teams to architecture resulting in teams owning a part of the code. This is referred to as component teams. In the collaborative cross-team practices section, we assumed the adoption of end-to-end or feature teams, which share code ownership across several components. This leads to more shared context and more collaboration and learning across the teams. A basic introduction to this can be found in this talk about maximizing dependencies between teams.
Often teams receive a lot of pressure to achieve customer commitments and deadlines. Most real-life product development does have real deadlines and promises, but putting pressure on teams is not increasing the chance you’ll make these. Adding pressure leads to focus on short-term efficiency that leads to more individualistic work rather than system efficiency. Removing this deadline pressure towards teams through proper prioritization creates an environment of collaboration and learning. The dynamic of trying to maximize scope through pressure is sometimes referred to as “the contract game.”
This article explored different internal and cross-team practices that either encourage or discourage collaboration and the cross-learning that can result from that. In that, we noticed that:
Each of these practices requires an entire article to properly explain them and guide how to use them effectively. This is beyond the scope of this article. Instead, I encourage teams to understand the differences and switch their practices to more collaborative ones, leading to more learning and growth, increased organizational flexibility, and more fun at work.
RSS feed