Are Your Agile Teams Suffering From Tech Silos?

How To Solve Common Problems In Agile Scrum Teams

Is This You?

“My company cannot create a roadmap for our initiatives, accurately forecast current or future deliverables, appropriately allocate or plan resources, and understand or manage our cross-functional dependencies.”

If so, you may have technical silos.

What Is A Tech Silo?

Tech silos are funnels of work that do not communicate with each other. These silos are unplanned and pop up due to a lack of structural definition within a team or department. Siloed teams have many dependencies due to the lack of ownership, integration points, workstream definition, and division within the silo.

What Causes Tech Silos?

Tech silos form when using component-based resources, where individuals are shared based on expertise across multiple teams rather than an initiative or persistent deliverable, which creates an interruptive workflow and cross-functional dependency for every participating resource. A component team is constructed of individuals with varying technical expertise who do not share knowledge or tasks, limiting other members’ visibility to work in progress. In this instance, work is divided by skillset, isolating unparticipating members from any information relevant to those tasks. This model creates the most amount of cross-functional dependencies and is the root cause of many bottlenecks discovered in software engineering teams’ ability to deliver on time.

Issues such as lacking division and ownership of responsibilities (particularly with intake, scoping, and prioritization) impact one’s ability to understand their team’s purpose in contrast to other teams with the same or similar capabilities.

Are All Silos Bad?

There is a common misconception that you do not want silos, because most silos occur unplanned and pose as a barrier to your workflows. You’ll often hear the phrase ‘break down the silos’, but that solution only works for certain instances. Silos with well-defined purpose and integration points are called systems, and they are typically very successful in certain software development environments. Systems are also referred to as ‘feature teams’.

Should you break down your silos or create systems? Let’s dive into both options below.

Your goal is to reduce your dependencies to eliminate bottlenecks and ‘blockers’ within your teams, and to create a solid foundation that scales.

What Are Some Risks With KEEPING Tech Silos?

1. Aside from the issues mentioned above, you never want your work or knowledge to fall solely on one member of your team. Tech silos often rely on one person who handles all aspects of a tool, topic, or department. Just because this person ‘can’ do it all, doesn’t always mean they should. We’re all human — sometimes people will be out of office unexpectedly, go on vacation or short-term leave, or just quit altogether. Although more convenient — some could say, the ‘low-lying fruit’ of resourcing, especially for smaller teams, (as knowledge sharing and cross-training takes time and potentially more hires) you are far more at-risk by burning out one person.
2. You are still sharing resources across teams. If you’re looking to run in an agile environment, you’re completely contradicting the purpose of the agile framework: to empower the team. If you’re constantly sharing or borrowing resources from other teams, it will be difficult to understand YOUR team’s specific metrics. This impacts the team’s ability to commit to and deliver work appropriately, as their velocity has not been clearly measured.
3. Component-based teams can be harder to scale. If someone in a certain area of expertise is unavailable, all other work in that area is put on hold. It’s okay to favor certain engineers for specific work — you do not need to eliminate this altogether. The issue within tech silos is the lack of visibility between the ‘experts’ and the other engineers. This may also make it harder to determine which resources are needed in terms of future hires, as work is not being divided efficiently, and the engineering need may vary as the company grows and adapts.
4. You will also need to consider prioritization. For example, if Team A is at capacity with high-priority deliverables, but a large, low priority, dependent item is holding up the release of an entire initiative for Team B, what takes precedent? This is just one example of the dependencies or ‘blockers’ tech silos can cause.

What Is A System or ‘Feature Team’?

A feature team is a full-stack team that can tackle its work end-to-end with the least amount of cross-functional dependencies. A successful model of this would be a team that does not share resources or deliverables with other teams in order to deliver their piece of a potentially shippable product.

How Can I Create My Feature Team?

Feature teams allow you to complete projects on a per-team basis rather than spanning across multiple teams. This model also allows you to have more persistent ownership of teams, and for each team to have more definitive work streams.

This structure would be very defined and look to eliminate silos within each feature team (such as component-based resources) as well as focus on knowledge sharing and cross-training as needed, which can help increase your teams’ capacities. Additionally, it can help you identify where and why you have dependent work, and how you foresee your engineering teams growing, merging, separating, or adapting. This will make it easier to plan quarterly goals, as you should have a better understanding of which teams own each part of a larger initiatives, and you will have pre-defined communication plans and integration points if overlap is required.

1. Outline your company’s current and upcoming initiatives in priority order, grouping any by common theme or type (ie. new features, specific client requests, maintenance, etc.)
2. Define which projects are ‘One-Off’: one-and-done, with no continuous maintenance work, ‘Build and Maintain’: create and/or implement new feature, with continuous maintenance work, and ‘Perpetual’: constant iterations and implementations needed throughout the foreseeable future.
3. List which resources are needed per initiative. Note: this should be very generalized! Avoid naming specific individuals or teams, and keep it high-level, such as front-end, back-end, design, etc.
4. From here, you can begin to redesign your teams based on persistent resourcing themes, and see where knowledge sharing, cross-training, or hiring is required.
5. Establish dedicated managers, such as product owners and scrum masters, to ensure proper alignment of responsibilities from the beginning of the software development lifecycle. For example, when new work comes in, decide who is responsible for managing requirements and the preparation of work with the business, versus seeing it through execution and delivery with engineering.

What Are Some ‘Quick Fixes’?

If you’re not ready to ‘shock and awe’ restructure your teams, or perhaps can’t hire to fill gaps quite yet — don’t sweat it! There are still a few things you can do to begin creating clarity and transparency among your teams.

1. Ensure all teams are operating exactly the same. This includes workflows, statuses, sprint cycles, story points, etc., otherwise it will be impossible to track and forecast dependencies or timelines for cross-functional deliverables. You can always alter these features in the future — for now, pick whatever works best, and run with it.
2. Have daily stand-ups, and a combined scrum of scrums. Touch base regularly with your team, as well as any overlapping teams to make sure the correct pieces are moving. Ensure visibility from all angles — this includes all stakeholders, managers, and engineers involved in the project. Neither of these meeting should be more than fifteen minutes each — max. If you’re having trouble timeboxing, we can help! Reach out to us here: service@mediatriton.com for personalized advice.
3. Include your engineers in planning meetings. Some product owners are hesitant to break away from the traditional cadence of assigning work to developers, however, if you’re working cross-functionally, including them on planning calls can help bring visibility to their capacity, priorities, and deadlines.

Breaking Down Silos

You should only consider breaking down your silos if you fall into either of these two categories:

1. Your team is too small to actually be divided into smaller separate teams.
2. You want to restructure your teams and need to start from scratch in order to identify your divisions.

If you align with either of the above, start by creating your master backlog, and add work for all members, tabling previous team-specific work until it can be re-allocated accordingly. Establish a new sense of ‘team’ with dedicated agile ceremonies inclusive of all participating resources. Be clear with the expectations for migrating work to the newly-shared backlog, changes to current in-flight work or upcoming priorities, as well as hierarchy alterations for escalation or questions if applicable.

Master vs Multiple Backlogs

A master backlog is a list of all in-flight and upcoming work for your team or company. Your master backlog can be your only list, or a compilation of lists from all teams for shared visibility and tracking. This list would include each initiative and corresponding deliverables, priorities and/or deadlines, and any other relevant information needed before work can begin, such as acceptance criteria and solution description. In this model, one person owns intake, scoping, prioritization, and planning (for every team utilizing the master backlog) as the voice of the business, and can collaborate with other product owners as needed. The upside to this model is the ability to clearly see priorities for all teams and team members. Ensure your teams are operating synchronously in order for your master backlog to be accurate. Having one master backlog is a great option if you’re looking to break down your silos and create one single scrum team.

One consideration includes issues when your teams are over a dozen people in size. Your master backlog can quickly get out of control with hundreds of tasks and dozens of members, so try to keep it as small as possible. If you’re too large for the master backlog approach, you may not be well positioned to break down your silos. If your teams also have other backlogs where work is created and assigned, the master backlog approach may not consider that team-specific work before assigning a large, cross-functional initiative, which could result in inaccurate resourcing.

No master backlog, ie. having multiple, separate backlogs for each team (while working with component-based/cross-functional resources) is the number one way to create an unplanned tech silo, as this immediately limits visibility between teams. It is best to avoid separate backlogs unless your teams do not need to overlap, and are operating as independent, full-stack feature teams.

If you have both combined and separate backlogs for your teams, you may have multiple tech silos, and will need to choose to break down your silos or create systems to solve the issue.

If you have multiple backlogs, pre-planned coordination is mandatory for cross-functional work or shared resources by identifying solid integration points and communication plans regardless of whether your team is component or feature based. Multiple backlogs or ‘silos’ of work with pre-defined integration points for required cross-functional alignment can be very successful, and is key for creating a solid, scalable system.

Next Steps

If you’re ready to turn your chaos into clarity, start here. Comment below for personalized advice from our experts!