We spent a good portion of 2011 helping the IT department within a Fortune 500 company understand how it could collaborate more effectively at a global level. In order to do that, we decided to try to understand what they were already doing right by identifying and studying a wildly successful project. The project we chose was unique in that it was the first project within the department that had officially chosen an Agile methodology to develop its software.
Most of our team was not familiar with Agile software development (or any kind of software development, for that matter), and so I thought it would be useful to have someone give us a primer. As it turned out, our data analyst for this project, Oz Basarir, was the perfect person to give us this primer, because he was a programmer on one of the original Agile development projects.
Oz spent an afternoon walking us through a wonderful introduction to a complex topic, leading us through a variety of experiential exercises. My favorite was an exercise called Bosses and Workers. First, he had us pair up, with one person as the boss and the other as the worker. The boss was to instruct the worker when and where to walk, with the goal of walking a total of 60 paces. Here’s what happened:
Next, Oz had us repeat the exercise, but he changed up the roles. He eliminated bosses, and made everyone workers. Here’s what happened:
Maybe the results seem obvious, but the reality is that most groups — whether they’re developing software or doing some other type of complex knowledge work — operate as Bosses and Workers rather than as just Workers. They often do it under the guise of “quality control,” but this is a myth.
Most group processes are based on the premise of mistrust and a fear of failure. These types of processes may work for small teams working on tame problems, but as soon as you add layers of complexity, the problem quickly outgrows the processes. This is particularly true with large-scale networks, where the notion of individual “control” is often an illusion, but it applies to every group.
If you want to be high-performance, you have to learn to let go, to share control, to sacrifice safety for forward movement, to accept failure as a requirement for learning, which is a requirement for success.