Product Delivery Team Anti-patterns – The “Silo-ball” Anti-pattern

This was originally published on the Connected blog in 2022 by Paul Sobocinski . Connected was acquired by Thoughtworks in April 2022.

Continuing the Product Delivery Team Anti-patterns Series, Paul Sobocinski, Director of Engineering covers the silo-ball anti-pattern in this edition and reveals how a virtual Kanban board can incentivize silos within remote Scrum teams.

This blog post was originally published on Paul’s blog, Coder Spikes.

Zoom fatigue.

Most of us will have heard of the term by now. Typically, it’s described as the fatigue one feels after a day of non-stop video calls (Zoom is just one of many group video calling tools that are now available).

What causes this phenomenon? Some contend that being on camera for long periods of time can feel performative, reduce mobility, and increase cognitive load; this has led to many companies adopting camera-optional video calls.

However, consider that software engineers and other product development practitioners have been complaining about excessive meetings long before the COVID-19 pandemic and the subsequent ubiquity of remote work. In fact, I’d hazard to guess that this complaint stretches back to the start of Agile software development. Among other changes, Agile brought about radically new ways of working where software programmers began to collaborate more closely with other product development disciplines than before. To the untrained eye, this looks like an excessive amount of meetings. To high-performing Agile teams, however, this looks like an ability to co-create via collaborative and engaging working sessions.

Scrum and Kanban Boards

Indeed, one Agile methodology, in particular, has risen to the fore as the predominant one. According to the 15th Annual State of Agile report, Scrum has been adopted by 66% of organizations. Moreover, the task-tracking technique predominantly used in concert with Scrum is the Kanban board — 77% of organizations report doing so (according to the same report). Interestingly, the Scrum guide makes no mention of Kanban. As a point of fact, Scrum and Kanban are entirely distinct methodologies. Yet at the same time, Kanban boards are very effective information radiators, making them extremely popular for visualizing work on Scrum teams.

Be that as it may, use of Kanban boards with Scrum can incentivize behaviour that leads to silos forming on product delivery teams. Ultimately, these unnecessary silos lead to longer-than-necessary cycle times due to excess work-in-progress, and missed opportunities for deeper collaboration which would otherwise lead to a better product. Adding remote work to the mix only exacerbates this undesirable behaviour.

In addition to further exploring this product team anti-pattern that I’ve called “silo-ball”, I also describe approaches that counteract this. These are derived from my experience working on various teams who have encountered this anti-pattern.

What is “Silo-ball”

The term “silo-ball” illustrates the practice of “lobbing back” tickets from a downstream lane of a Kanban board to an upstream one.

For example, if a software engineer requires only a few minutes of a designer’s time to consult them on a particular UX behaviour, then moving the associated ticket back to the “design” lane undermines the team’s productivity. This is because the cycle time on the ticket has now increased by an indefinite amount — progress has stalled on the work until the designer picks the ticket up to offer their feedback. Once they do, they again move their ticket back to the “engineering” lane, where it sits for an indefinite period until a software engineer picks it back up again.

If the team gets comfortable with this practice, then team members specialize in working inside one lane only, rejecting involvement in any work outside of their lane. Collaboration plummets as the lanes harden into silos and disciplines are boxed into roles. Ultimately, this leads to a team that cannot respond to change in a rapid and effective manner, due to the rigid dependencies that form across silos and roles.

Further, as Scrum prescribes the use of sprints, there is pressure imposed on the team to push work rightward down the Kanban board. Consequently, any leftwards “kickbacks” are dealt with hastily, discouraging deep collaboration. For example, the “kickback kicker” will create a laundry list of items to address (such as comments on a JIRA ticket or a Figma mockup), while the “kickback receiver” will dutifully go through the provided list as quickly as possible. Asking questions and digging deeper is discouraged not by any individual, but by the process — a kickback is already moving in the wrong direction on the Kanban board.

Counteracting the Anti-pattern

Preventing silos from forming on product delivery teams starts with earnest curiosity about what our teammates do; this includes a deep understanding and appreciation of their expertise in their respective disciplines. It also means recognizing that the product delivery team that we’re a part of is a highly dynamic and closely interdependent system. In other words, we cannot measure success or even progress based on looking at our own individual actions alone. And especially, we cannot trick ourselves into thinking that we can work effectively in isolation.

Cross-disciplinary pairing

Instead of berating your teammate with a laundry list of items they missed, be curious. Why may they have missed these items? How does your teammate go about addressing them??

Adopting an attitude of openness and curiosity, consider jumping on a call with them for an impromptu cross-disciplinary pairing session. Given the knowledge asymmetry due to differing disciplines, strong-style pairing is recommended for such a scenario. While interrupting your teammate with a call may seem disruptive, consider that Agile teams ruthlessly and sustainably minimize cycle times while embracing interruptions and context-switching in the service of that aim. Indeed, lower cycle times directly contribute to improving the first three of the four key metrics — a well-established means of measuring software delivery performance.

Collective Ownership

Is a real-time interaction needed every time we encounter something unexpected in the product development process? Of course not. Even in cases when it isn’t, however, members of a cross-disciplinary product delivery team can find themselves so trapped in their respective silos that they refuse to make any contributions outside of their silo, no matter how straightforward.

For example, if a designer notices a colour mismatch due to a typo in a hex code, or a QA engineer notices a missing unit test case, then they should be empowered to issue a Pull Request (PR) for the change themselves. While it may be “just a small tweak”, they are improving cycle time by not handing the issue off to another team member (we also avoid an interruption and context-rebuild in this case). The same approach applies to product backlog items such as user stories which are oftentimes written with missing or even erroneous information (the existing process should notify the relevant stakeholders of updates to such artifacts).

Some team members will react to this by pointing out: “we don’t own that, they do.” Effective product delivery teams work against this attitude by adopting a collective ownership mindset. This means that any team member can contribute to any part of the product delivery process, especially the code itself. It also means that all team members possess the same level and sense of ownership of the codebase and its related artifacts (documentation, design mockups, work items, etc.)

Removing silo-protecting constraints

A tell-tale sign that product delivery teams operate in silos is the constraints that they impose on their teammates. Only software engineers being able to create PRs is one example of engineering “protecting its silo”. Another example of silo-protecting behaviour is for only designers to have edit access to the design mockups, or for only product managers to have edit access to work items such as user stories.

Indeed, the thought of any member of the team editing any artifact, including the one which specifies the work to be done, seems like it would lead to a chaotic free-for-all. Here’s how the conversation often goes:

Anika: What if the software engineer makes a change to a mockup that wasn’t approved by a designer??

Beth: Why would approval be necessary?

Anika: Because the software engineer doesn’t know about design.

Beth: Even if it’s an obvious error (e.g. margin sizes off by one pixel from the standard)?

Anika: Sure, but sometimes it’s not obvious.

Beth: In that case, they would jump on a call with the designer?

Anika: How will the software engineer know when to do that?

Beth: Apply their judgement, which they develop over time as they work more closely with their teammates?

Anika: Fair enough. Could we at least ensure that designers are notified when their designs change?

Beth: Don’t you mean the team’s designs?

Anika: Ah, yes. Of course. Still, they should be kept in the loop.

Beth: Absolutely. I’m pretty sure there’s a way we could automate those notifications, too!

It’s not hard to see how a curious team open to experimentation can be convinced to remove such self-imposed constraints.

While the removal of these silo-protecting constraints may not reduce the number of total interruptions, it does eliminate the need for unnecessary interruptions. For example: getting approval from a designer for a one-pixel margin change. Consequently, cross-disciplinary collaboration becomes deeper and more meaningful.

Adding cycle-time-reducing constraints

Once the team has cultivated a culture of curiosity, appreciation, and respect for the diverse disciplines on the team, practised meaningful collaboration and synchronous co-creation, and removed silo-protecting constraints, it is ready to look at how to reduce cycle times in a sustainable manner by adding constraints.

Firstly, this can be done simply by restricting or blocking any backwards movement of tickets on the Kanban board. Not only does it reduce the number of hand-offs, but it also constrains the current ticket-holder to pull in expertise that can resolve the ticket at that moment, as opposed to placing it on someone else’s queue and moving on to a new ticket, thus increasing the team’s WIP.

Further, the team can adopt another practice from the Kanban methodology: WIP limits per lane. Doing so ensures that the team focuses on its delivery bottleneck as soon as it appears. For example, if the QA lane has reached its WIP limit, the entire team focuses its efforts on working on the tickets in the QA lane.?

I have seen product delivery teams jump to WIP limits before fully embracing a collective ownership mindset to the work and its outputs. This results in the team being overly constrained, so there is no room for any progress to occur whatsoever. To get back to a sense of progress, the team then removes the most recently-applied constraint: WIP limits. This sense of progress is misguided, however. Simply keeping every teammate busy does not guarantee value for the customer. It also, counterintuitively, leads to increased cycle times.

Final Thoughts

It’s easy to forget what it means to be Agile because it requires us to work against certain ingrained tendencies. Namely, we have a desire to stay heads-down and focused. There’s nothing wrong with that, as long as we don’t lose sight of the fact that we’re part of a larger whole: an Agile product delivery team. Some may be surprised to learn that such a team’s fitness is not achieved by minimizing interruptions or context switches experienced by its individuals, but by minimizing cycle times while delivering customer value sustainably. This can only be accomplished in the long run through effective and skilled collaboration, and by avoiding anti-patterns such as the ones we’ve discussed so far.

Silo-ball is a symptom of a deeper issue arising from the prevalence of remote work: a fixation with working asynchronously at all costs. In my last post of the series, I will explore this final anti-pattern of product delivery teams.

The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.