Are there drawbacks to Swarming?
Regular readers of my articles will likely have read a number of pieces discussing the practice of Swarming — a term used to describe the partial or complete replacement of a traditional “tiered” support structure with a less rigid, more dynamic collaborative approach.
It will also be obvious to those regular readers that I am a big advocate of Swarming. You can read a detailed introduction to the concept (in the context of aligning DevOps to enterprise support channels) here. I’ve discussed examples of real-world Swarming practice in articles such as this one, and have explored Swarming as a means to harness the principles of the Cynefin framework here. These articles have, I hope, played a part in moving Swarming further onto the conversational agenda in both the ITSM and DevOps communities.
Where I have seen it implemented, Swarming has generally been considered a success. However, having promoted it so enthusiastically, it feels fair that I should share and explore some of the negative experiences and concerns that I have observed in, and discussed with, practitioners and advocates of Swarming.
The Executive Leadership Challenge
“A bounded management mentality of ‘my team’ and ‘our work’, or creating contests or competition between teams, is death to a collaboration model”
Intelligent Swarming: A Framework for Collaboration (2019) — Consortium for Service Innovation
Swarming only works with significant executive support. It requires the loosening of rules which are often entrenched in practices, metrics and incentives. It requires managers to step away from a cybernetic, process driven model, in which they pull the levers, to enable a more adaptive culture of self-reliance amongst their staff.
Technical support has, over a long period, evolved numerous social constructions which are varyingly incompatible with a transition to a more collaborative Swarming environment (I recommend Peter Johnson’s “Making Light Work” for its detailed exploration of IT management’s issues). Team-specific operational level agreements, for instance, discourage cross-team collaboration. Management hierarchies are an issue: groups may be stakeholders in the same issue, but if they report through different vertical lines in the management hierarchy, they may have conflicting objectives which create a disincentive to collaboration.
The result of these challenges is that Swarming can be perceived as risky and complex, and might be seen as something that is not readily implementable without difficult and perhaps expensive organisational changes. Where a Swarming initiative is started, these problems can severely curtail its growth and effectiveness.
The Financial Challenge
A very frequently expressed concern from enterprises exploring Swarming is the perceived impact on costs.
In a tiered support environment, it is generally assumed that front-line staff in the 1st tier will be less expensive than the more experienced, more specialised technical staff in the 3rd tier. There is often a perception that a Swarming model brings expensive staff into the process for longer periods of time, more frequently, in comparison to the traditional tiered model, and hence the average cost of dealing with each issue will be higher.
This viewpoint might be difficult to challenge, because it is quite conceivable that this effect will show up in financial reporting on a per-issue basis… at least initially.
An effective counter-argument relies on Swarming delivering a longer-term benefit, either in overall reduction of support work through improved service reliability, or through better long-term enablement of the support front-line to handle future occurrences of issues, without the need to engage more specialist teams. This can be difficult to prove.
The Performance Measurement Challenge
When support is organised around point-to-point reassignments, timestamps for key events (such as the receipt and subsequent handoff of the piece of work) can be aggregated and averaged to give a consistent, comparative measurement of responsiveness.
The effectiveness of these metrics is nullified by Swarming. Swarming is a conversation, rather than an exercise in passing-the-parcel.
This issue impacts measurement of individual and teams, but also of third-parties such as service providers and contractors. It is not as straightforward simple to evaluate the contribution of any specific individual or team in a more loosely arranged conversational model.
For many organisations, this is more than just a measurement challenge — it is a financial one. Service contracts frequently contain incentives, bonuses and penalties underpinned by those traditional process measures. In environments in which such metrics are entrenched, a shift to a new work practice requires more than just a cultural change: it necessitates the complex unwinding and replacement of existing contract arrangements and standard service offerings.
This is, increasingly, as relevant to DevOps teams as it is to “traditional” IT functions: many modern services are underpinned by multiple cloud service agreements which provide essential building blocks — ranging from infrastructure through to application functions — to modern distributed systems. Those service providers are often set up to work in a particular way, often through traditional assignments. Changing that system, and engaging those providers’ people into a Swarming support structure, may not be easy.
One counterpoint here is that the conversations which Swarming brings will frequently have been happening anyway, albeit not acknowledged or measured by the incumbent process. It is common, for instance, to see Servicedesk agents participating in “off the record" side-channel conversations using chat tools, while teams in the DevOps community commonly use Slack and other collaboration tools in similar ways.
The “Who do I work with?” Challenge
In a complex organisation, it can be very difficult to know who is who. An individual attempting to convene a swarm typically needs to seek input from multiple subject matter domains. The productivity benefits of swarming are reduced if individuals have spend a lot of time simply discovering who might be able to help them.
The Consortium for Service Innovation addresses this challenge through its blueprint for Intelligent Swarming. This concept relies on people profiles and “reputation” models. Profiles, in this model, contain information on each individual’s skills, whether technical or “soft”. Reputation is established over time by monitoring and measuring the value that was added by individuals in previous work in relevant subject areas.
However, I have seen a few organisations in which swarming advocates are somewhat bearish about this approach. Particularly problematic, according to multiple conversations I have had, is the concept of cultivating personal skills profiles. This is variously seen as a privacy headache, a morale reducer, and a significant logistical challenge.
Another commonly expressed concern is the risk of overburdening highly effective individuals with excessive invitations to swarms: it is difficult to balance the desire to achieve optimal results through selection of the best people, with the risk of burning those people out through over-reliance on them.
The Consortium acknowledges that reputation and profiling is an area of ongoing development. We may also see other approaches emerge, perhaps driven by the increased availability and versatility of cognitive and machine learning. For now, it is reasonable to argue that the “who do I work with?” issue is not fully solved.
Other Human Challenges
Swarming may not be a positive experience for all individuals. One commonly cited challenge, when talking to organisations who have adopted swarming, is that some people tend to dominate conversations, just as they might in any other group interaction. As well as having a negative impact on outcomes, this can cause harm to other individuals, reducing their ability to bring value becuase their contribution is diluted in a way that it would not be in an individual assignment model.
One other interesting issue that Swarming has brought in my own organisation is the sudden exposure of some technical support people to the customer. This is an outcome of some of our own swarming practices, in which customers may be brought into the early “dispatch swarm” process, if further input from them is felt to be necessary. Prior to the adoption of these swarms, such interactions were the domain of our Level 1 support teams, but a dispatch swarm can include technical specialists who would traditionally sit at tier 2 or 3. For some, this required a little guidance and mentoring.
Conclusion
This is not an exhaustive list of challenges, nor is there anything here that should be seen as a complete “showstopper” for Swarming. However, this does highlight that despite the hugely positive impact of Swarming at many companies (including my own), and the enthusiastic discussion of the subject across the DevOps and ITSM communities, there is no “free lunch” here. We need to remain aware that Swarming, like any other new idea, has challenges as well as benefits.
