Here's a story that probably will sound familiar:
Once upon a time there was a product development team (let's call it the Acme Team) that needed the help of a Database Administrator (DBA) each time they needed to make changes to a database environment they product relied on. The database technology they used required not only specialized expertise but also (because of corporate policy) strict security credentials that restrict who can get access to do work there. The company had a relative small team of DBAs that could do this kind of work; the manager in charge of this team had decided that individual DBAs will be "fractionally assigned" to product teams, and in this case assigned one of them (let's call them Pat) to the Acme Team. Pat worked with 2 other teams, with the expectation that each would get "roughly" 30% of Pat's attention and capacity.
You can probably imagine how the story continues:
Pat often runs into calendar conflicts when meetings from various teams overlap, and is unhappy about the growing perception about lack of availability and responsiveness. Work seems to arrive at Pat's inbox from all directions, with different levels of urgency, at different rates and volumes; Pat then feels overloaded and disconnected. From Acme's side, they experience frequent delays every time their work requires DBA expertise.
In other words, these are the typical symptoms caused by a "non-instant availability" problem, all leading to stress, quality issues, and ultimately delays.
Cross-Functionality: The Oasis in the Desert
Conventional wisdom, particularly in the Agile movement, is we should be solving this (and other dependency problems) by reorganizing into cross-functional teams with full-time allocation.
I've argued in a previous edition that reorganizing for cross-functionality and "100% allocation", while strategies worthy to be considered, are not always a pragmatic solution for these kinds of problems. Sometimes, the oasis in the middle of the desert is just an optical illusion, and becoming comfortable with the notion (and effective management) of "shared services" might be a better long term fix.
This alternate approach would involve stopping the practice of "fractional allocation" of people. Instead, in the story above, we'd keep all the DBAs together and manage the incoming demand of database work so that it's balanced with the collective capability of the DBA team, and then allow the DBAs to self-organize around it. (In a sense, it is still about "100% allocation": the DBAs are fully allocated to the shared DBA team). Additionally, feedback loops between shared services and their customer teams would need to be established, to balance the whole system.
Goes without saying that this is not a trivial change in management style and other logistics. It will not only take time and effort to introduce; it will require decisions and actions that most likely are beyond the sphere of influence of team-level leaders, like Acme's delivery manager (someone with the formal position of "Scrum Master"), who was who brought up the story above and asked "what could I do?".
So, if the longer term fix is to influence upper manager and other decision makers to adopt a service oriented strategy, what can a team-level leader do in the meantime?
What would it take?
Perhaps a good place to start would be to consider what it would take (at least in theory) for the "fractional SME" strategy to work.
It seems to me that two elements would be needed for Pat to have some chance of being effective with a "30% allocation" scheme. The first includes decisions that can be made strictly within the confines of Acme's team process:
1) Non-Instant Availability countermeasures: essentially "protect" Pat from anything that will make their work ineffective and waste limited capacity and availability. This could include things like agreements on "definitions of Ready", additional quality tests and controls, or transferring some database tasks (perhaps those that require less specialized expertise or are more "clerical" in nature) to other team members; in general, any action that will increase the effectiveness of Pat's actions and lower failure demand once work gets to Pat's inbox.
Other family of actions would require to "subordinate" team activities to Pat's way of doing things. A WIP-limited buffer for DBA tasks could be an example of this; batching work before hits Pat might be another example. Early discovery of DBA dependencies in the work might be another, so that Pat can be given appropriate lead time.
Check my previous article on NIA for a more complete discussion on protection and subordination, and my agile dependencies talk for a discussion of early dependency discovery.
Many of the problems generated by the "fractional allocation" strategy come, precisely, from the fact that more than one team is involved. So, the second element that would be needed for the strategy to work has to do with how these teams behave collectively:
2) Coordination between teams sharing the SME: this would require all the teams sharing Pat to coordinate their actions, so that Pat is not overwhelmed by uncoordinated, uncorrelated streams of demand. This kind of coordination usually requires team-level leadership collaboration: managers from each team need to work with each other to come to agreements about how their teams as a whole will interact with Pat.
Making sure there's no meeting overlap might be a good first step: Pat can't be in different places at the same time, so having all the daily stand-ups at the same time in different rooms, for example, doesn't make sense. At the same time, asking Pat to attend 3 stand-ups every day may not be the best use of time, so a compromise will be needed.
But more importantly, all teams will need some mechanism to make sure there's respect for the "30% capacity allocation" that each of them have been given. That will require agreements about how that capacity will be measured and monitored, and what will happen when eventually one team has needs beyond that capacity allocation. Giving Pat a "Personal WIP Limit" could be an option, supplemented by some form of explicit capacity allocation policy.
Priority conflicts between teams will eventually happen: one team will inevitably have an urgent request that can't wait just when Pat is still busy with other team's work. A mechanism to detect these situations, and negotiate a resolution will also have to be in place.
As the preceding discussion shows, getting the "fractional SME" strategy to work requires systemic action, not just localized (team level) decisions, and in a sense defeats the purpose of keeping teams "independent" by giving them access to "their own specialist". Yes, it's true that they don't have a dependency on the whole DBA team, but instead it creates the need for additional coordination between Acme and all the other delivery teams.
Just to be clear, adopting a "shared service" strategy would still require some of these coordination mechanisms to be in place, and even some of the NIA countermeasures described above. The point here is not that "shared services" would eliminate the need for those practices, but that you will need them regardless.
OK, but until then?
If there isn't enough buy-in to move in the direction of service orientation, or you think you are not (yet) in the position to influence that, this is how I'd proceed:
1) Work with the Acme team to introduce changes in their process to incorporate NIA countermeasures like those described above. Most of these kind of changes should be within the team's sphere of influence, or negotiable with Pat.
Maybe this is as far as you can go for now, but it can be enough to stabilize the situation. It's important to understand, though, that there will be still many other sources of disruption, and to tackle those you'll have to start talking to people in other teams.
2) Initiate conversations with your peers in other teams, to address the problem together. Start by finding from Pat what the most pressing concern is when it comes to working with 3 teams simultaneously (perhaps it's overlapping meetings, or imbalance of work, or urgent requests, etc) and extend an invitation to the other delivery managers to collaborate on a process solution.
3) Slowly make the case for a move towards a shared DBA service. This will require involving the DBA manager, and making the case for interacting with the full DBA team, rather than Pat directly, through a well defined interface (work item types, classes of service, replenishment cadence) and with appropriate feedback loops (like delivery and operational reviews) to keep the system balanced. Pat and all their DBA peers can then self-organize to find the best way to share the work and deliver it.
Comments