Agile was designed to help software teams deliver better, but some will argue that you can use it effectively in any context. But is this really true?
I’ve worked for so long with teams that provide the DevOps flavored services you’re familiar with. You might call them DevOps, Infrastructure, Platform Engineering, System Engineering, Site Reliability Engineering, Build and Release Engineering, or any other common name for these teams. What ever you call them, Agile does not bolt-on directly.
If you’re on one of these teams and you’ve tried Agile but are finding it frustrating, this article was written for you. If you’re an Agile practitioner and think I’m wrong, I hope you also keep reading. These frustrations are real and they are due to the fact that there are major contradictions that will arise from an “out of the box” Agile implementation on teams like these. However, there are ways to make Agile work for you without totally revolutionizing your team and without mutating Agile into something totally unrecognizable.
Agile does offer techniques that any team can implement which will boost their productivity. However, for the whole package to work for your Shared Services team, it won‘t be as simple as having another retrospective, more Agile coaching, or flipping to Kanban.
Silos are bad, right?
Organizationally, having specialized teams that work in an assembly line style of production is something Agile sought to challenge. This assembly line method goes by another name you’ve heard before: the waterfall. Silos in an organization are bad in Agile, so why does it happen?
When companies reach a certain size, Agile coaches may advocate for specialized Shared Services teams that Product teams can defer some responsibilities to. This is an acknowledgement that at a certain point, there are too many things involved in running software for a small team of 5-9 people to do it all effectively and even if they can, there are other really good reasons to go down this path. For one thing, this allows for standards to be implemented. Teams also don’t need to reinvent wheels that other teams have already made. Furthermore, it’s not ideal for long term sustainability of your software if no one in the company outside of your small group is capable of supporting it.
At the same time, an Agile team needs to be empowered to deliver and a huge part of that is having control over their own destiny, or their sprint goals will be at risk.
This contradiction introduces tension between these teams, and it is usually the Shared Services team that takes blame when Product teams don’t deliver.
The other problem is there are often silos within the Shared Services team which hinders opportunities for pair programming and swarming. Remember, not only do they support numerous Product teams, but they also support the shared platforms and services they all use. It’s common to have situations where knowledge about a specific platform or Product team’s software resides with one engineer.
Misaligned by design.
Agile requires members of a team to be aligned on a clear mission, because focus is a really key component to improving delivery. This usually isn’t the case for a Shared Services team because of their broad range of responsibilities.
When a Product team starts their sprint, the sprint backlog will be focused on features and bug fixes for that product they manage. It might have different components to it, but it’s all usually a tightly integrated architecture. Imagine if they had five different products that had little or nothing to do with each other, and that also use different technologies. That’s what Shared Services teams deal with.
Various and differing skills are often required of a Shared Services team, and this naturally leads to focus fragmentation. As we stated above with regards to silos, engineers may specialize in supporting specific Product teams, or a specific platform. It’s simply not reasonable to expect everyone to share the same responsibilities when those responsibilities are so diverse.
Responding to everyone else's changes.
A core tenet of Agile is that teams should respond to change instead of follow the plan. That’s a great concept, especially in the context of getting a product to market quickly. The issue is the downstream impact this has. If you have five Product teams frequently shifting their priorities and requirements, this will have an impact on the Shared Services team that is trying to fulfill all of their requests.
Too many responsibilities on top of shifting priorities will lead to excessive context switching. This is the reason work gets started and paused multiple times before being completed or abandoned. This is also why Shared Services teams often give up trying to do fixed sprints because it sucks missing half your goals every time.
How can you be Agile without a Product Owner?
Product Owners are the people that meet with and understand the customers, groom and prioritize the backlog, and review the quality of work being delivered. This critical role is often unfulfilled on Shared Services teams and without this person, the whole Agile concept falls apart.
These are common symptoms of these responsibilities being neglected:
- Your backlog is a perpetual mess.
- Priorities aren’t clear.
- Work that’s delivered often requires rework.
If you’re thinking the answer is to hire a Product Owner for your Shared Services team, it’s not that simple.
A Product team exists to build and support their software. That software has a specific context within the company it’s used in, and this specificity helps the team have a clear mission. This is a major point of differentiation between a Product team and a Shared Services team. The mission of a Shared Services team is usually something along the lines of being a reliable service provider to Product teams.
It might sound like the services this team provides can be conceptualized like products and managed the same way, but Infrastructure services are mostly SaaS tools, open source projects, or bought off the shelf, so knowing how to implement and manage them is what’s required. Even for internally developed infrastructure tooling, it’s often too technical for most Product Owners to add value. The bottom line is you’re just not going to find many companies that are willing to hire someone to be a Product Owner for things like this.
Adapting to these realities.
I want you to know that as a consultant, I have never personally experienced “Agile Nirvana.” Even in the most ideal of circumstances, there are always trade-offs and the bottom line is this: the quality of the people you have on your team is more important than the framework you use.
So how do we make Agile work?
Break down silos using the rule of 2.
Silos are bad but almost unavoidable. It isn’t usually practical for every team member on a Shared Services team to be able to cover for each other. However, a place to start is to evaluate everywhere that you have silos on your team, and try to prioritize which silos you want to fix first. The fix can be as simple as having just one other engineer be able to be a backup to the primary engineer.
Don’t waste your time if the person you’re trying to develop as a backup engineer isn’t going to be involved at all with the work any time soon. Make it real and assign them work in the specific area periodically, because those skills are perishable. Documentation is another great investment, but it’s not trivial to keep it updated. Having two engineers familiar with the subject matter will make documentation easier to keep up with.
You need structure to stay aligned.
We established that focus is an issue for Shared Services teams, and a big cause of this inability to focus is the misalignment that can occur with Product teams. Even though you don’t have a Product Owner to help drive this alignment, you’re not doomed without one.
Here’s a short list of things that can help you solve this problem.
- It’s required that these teams have recurring ceremonies to plan their work together and stay aligned (“Scrum of Scrums”).
- There should be things like Steering Committees and value streams that set higher level priorities for all teams.
- The Product teams should own as much as they can that’s relevant to their software.
- Shared Services teams should constantly invest in “self service” to get them out of the critical path.
Backlog grooming doesn't have to be all or nothing.
If your backlog is a mess, it might be overwhelming at first, but start by setting a realistic goal. Try to get enough work groomed that the team can pull from for the next couple of weeks, and build from there.
Also, don’t depend on this grooming to happen asynchronously. Prioritize one or two hours a week of dedicated time to this and don’t cancel it because another meeting came up. It should be the TPM’s responsibility to schedule the meeting and to stay on top of open questions about priority or implementation and it should be the manager’s responsibility to champion attendance and participation. If you don’t groom your work, you won’t be successful, so keep moving the ball forward every week.
Before you know it, you’ll have made a lot of progress and it won’t be so daunting.
Your work matters too.
When you’re backlog grooming and figuring out priorities, you need to be able to represent the work that your team needs to do that your customers won’t necessarily care about, but could be impacted by.
This is all of the work that keeps your platforms and services well maintained. “Keeping The Lights On” isn’t free, and if you defer it for too long, you end up with technical debt. If you have the work groomed, you can assess what impact it will have on your team’s capacity so you can plan better with your customers.
The key takeaway here is that you shouldn’t defer the work you know your team needs to be doing. The interest on that technical debt will reach critical mass at some point, so pay off that balance every now and then.
Finish what you start.
If your team is sticking to a consistent grooming process, another thing you can do to help with both focus and quality of outputs is implement a policy to not start work that hasn’t been groomed. This lends itself nicely to tracking as a KPI. Know that if you achieve 80%, that’s pretty exceptional given how much interrupt work can occur.
Something to keep in mind when grooming is to strive for smaller tasks over larger ones. The trade off is more overhead, but it’s worth it because smaller items can go through your workflow more easily and are less subject to scope creep.
I like imposing the “no more than one task in progress per engineer at a time” policy. If you don’t finish a task before starting the next one, it’s helpful to set it to a status that represents this. You might think of this status as blocked or paused, but I prefer these to be separate. Your TPM can look at the blocked column and know that work can’t proceed because it is out of the team’s control, whereas the paused work is work that can be finished. Impose WIP limits on work that’s paused too as this will help control context switching.
Accept it for what it is.
If you’re in the Shared Services game, you know it’s always going to be a faster paced, hurry up and wait, many pots on the stove kind of world. There is no silver bullet framework. Whether it’s Kanban, Scrum, Scrumban, or something else, these problems will persist on a Shared Services team if you don’t have the right people and if you’re not spending time doing these things we described above.
If you have great people on your team and are doing all these things, your environment is going to be manageable.