Scaling Collaboration not Process is the Key to Enterprise Agility.
Agile methods have been found to be extremely effective when used correctly. A reasonable reaction to witnessing any great performance in an organization is to demand more of it. So a tremendous amount of time, effort and resources have been expended over the last few years on scaling agile for the enterprise with all the new processes and models that can go along with that.
I admire a lot of the work done to scale agile methods in the attempt to replicate the success of the initial `golden-teams` to all groups in an organization. Unfortunately these roll out attempts largely result in disappointment or failure because the investment and effort has been applied in the wrong place. It is not process we need to scale and duplicate, it is the art of collaboration.
Agile methods are successful when they equip motivated subject matter experts to collaborate in an effective way with minimal process overhead. In attempting to make agile methods scalable, it is tempting to add more process to assist larger scale coordination. However that is the last thing we should do. Not that we don’t add more process, just that we add it last, not first, after you have replicated and established collaboration models. Adding process first kills collaboration and then even the best intentioned and resourced development environment is doomed.
This phenomenon of process stifling smart behaviour was identified by Dee Hock, former CEO of Visa who said: `Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behaviour.` The real path to scaling agile successfully is not choosing a scaled framework to implement, but focussing on replicating good teamwork and collaboration models and then adding minimal process.
The trouble is process and tools get all the press because they are more tangible and easier to describe. Plus vendors can promote and sell frameworks more easily than teamwork advice since they are proprietary and more marketable. So, a bit like diet pills and fitness gimmicks, we see more coverage of quick fixes that don’t really work than good (but less flashy) basic nutrition / teamwork advice that actually does work.
So much so, that even the basics of good teamwork are not widely understood. Richard Hackman, in his book `Collaborative Intelligence. Using Teams to Solve hard Problems`, dispels 6 Misconceptions About Teamwork.
1) Team Harmony Helps – Actually: Conflict when controlled helps build well vetted solutions with strong group buy-in. This is better than conflict-free feigned agreement seen in teams that fear conflict.
2) It is good to mix it up – Try a few new people and ideas. Actually: The longer members stay together as an intact group the better they do. Whether a baseball team or a string quartet, teams that stay together play better together. Reaching the `Performing` stage in the Tuckman (Forming, Norming Storming and Performing) takes time and changes set the group back to the Norming stage again.
3) Bigger is better – large groups have more resources and domain experience to draw from to solve problems, right? Actually: large size is the most common impediment to effective collaboration. Free-Riding (or Social Loafing) are more likely in large groups. Small groups are more efficient and less frustrating.
In experiments where small and large teams are asked to pull on a rope it has been found that people slack off when there are lots of people present. Basically efforts diminish as group sizes grow. This is known as the Ringelmann effect after the original researcher.
4) Face-to-face is antiquated – now we have video conferencing and virtual offices we don’t need tiring, inefficient to get face-to-face workmates. Actually: remote teams are at a distinct disadvantage according to performance research.
5) It all depends on the leader – trying to distinguish between good teams and bad ones? Did it come down to the personality, behaviour, or leadership style of the leader? Probably not, research shows Condition-creating (setting up the work environment) accounts for 60% of the variation of how well a team eventually performs. 30 % on how well it was launched and 10% on the ongoing coaching. So focus on the environment and kick off.
6) Teamwork is Magical – Just get a bunch of smart people and tell them in general terms what needs doing and they will figure out the rest. Actually, it takes a lot of preparation to stack the deck for success. The best leaders provide a clear statement of what is required and then provide support and resources with all the political manoeuvring that is required to get it.
Chris Hadfield, author of `An Astronaut's Guide to Life on Earth` talks about projects being like expeditions into the unknown for a team. He says that people need Expeditionary Skills, skills that help them and their colleagues on this journey.
Hadfield argues that you really do not need to be a superhero to be a valuable member of a team – empathy and a sense of humour are often more important. He also suggests that searching for ways to lighten the mood is never a waste of time, because it encourages expeditionary spirit – everyone pulling together to collectively accomplish a shared goal. Conversely, though while sharing common gripes can create a bond between team mates, excessive whining is corrosive and the antithesis of expeditionary behaviour.
This may seem strange from the hyper-competitive world of NASA, but Hadfield argues that promoting colleagues’ interests helps you stay competitive and you have a vested interest in your colleagues’ success – the better they are, the more they can help you succeed.
My final piece of advice for companies looking to scale agile methods to more and more teams would be to read Jean Tabaka`s excellent `Collaboration Explained` book. It contains patterns for effective teamwork and collaboration along with easy to understand explanations of why we should do things that way. Process and tools may be fun to play with, but people and teams are where we get the biggest results.
(This article first appeared in ProjectManagement.com here)