When a man suffered a cardiac arrest on a ski slope, a medley of medical personnel from different countries and backgrounds mustered together to take charge of the man's health. Despite language barriers, they were successful in stabilizing the man. While this incident may seem to have little to do with software development, Clarke Ching sees that the makeshift emergency team shared specific characteristics found in all strong software development teams. In this column, he details these characteristics and how applying them can turn your team into a more successful team no matter how dissimilar individual teammates may be.
At the end of a long day of skiing at a European resort, a respiratory doctor was about to leave the slopes when a friend rushed up to her and said breathlessly, "A man has collapsed." She quickly followed her friend to find a man lying down on the slope who was receiving mouth-to-mouth resuscitation. He had suffered a cardiac arrest. The doctor and her friend were soon joined by several other medical workers: two German nurses, one British pediatric nurse, one French dentist, and a British nursing student. Together they formed an ad hoc cardiac arrest team. The respiratory doctor, being the most experienced member of the team, took charge.
The team administered chest compressions for eight minutes before an emergency helicopter arrived. Yet it took another forty-five minutes to stabilize the patient before he could be flown to a local hospital. So what has this story got to do with software development? Not much at first glance, but bear with me. This story intrigues me because it demonstrates many of the characteristics of strong software development projects: a clear goal, use of common standard practices when applicable, and all are managed with a "light touch."
Strong Projects Share a Clear Goal
After a brief diagnosis of the collapsed man, the team agreed on a clear goal: They would perform resuscitation until the patient could be flown to the hospital or until the efforts had clearly failed. Starting with a clear goal allowed them to focus and prioritize throughout the resuscitation procedure.
Strong software development projects have clear goals as well. But unlike a ski slope emergency where a clear goal can easily and quickly be established, a goal in a software project usually isn't as obvious. Strong development teams work hard to understand their customer's concerns and then negotiate a clear common goal that the customer and team understand and agree with.
Some teams express a goal as a project charter; others prepare a metaphor. One well-known Internet company has its development teams write goals out in a press release. What is important is that the team and the customer both have a clear view of what success should look like.
On the other hand, weak projects dive into development and pay scant attention to the customer's underlying concerns. Keen to show progress, these projects forego the necessary conversations with their customers and end up (efficiently) solving the wrong problem. Weak projects often commit to more than they can deliver, by not taking into account their capabilities and capacity. Weak teams often bear too much of the project's risk. The ad-hoc medical team on the ski slope promised to do its best, but didn't commit to saving the victim's life.Strong Projects Use Standards
The team from the ski story was mostly strangers who spoke three different languages between them, sharing only a few words in common. Despite these limitations they were able to quickly form a highly functional team because the resuscitation process is well known and defined, and mutually agreed upon.
Strong IT projects are delivered by teams who use standard tools and processes when they can. One reason is that it saves the team from having to invent the tools and processes from scratch. (Imagine if you had to write your own compiler for each project.) Another reason is that standardizations help you work faster. It is typically far easier to form new teams and for new members to join existing teams in organizations that use standard programming languages—such as Java or COBOL—and standard project management approaches—say, Prince 2 or Scrum, than it is in organizations that don't.
But, again, we've got to be careful with the ski slope analogy; the language barrier was overcome easily because the resuscitation procedure needs a common process more than it needs a common language. Many would argue that software projects have enough difficulties when using just one spoken language. A friend recently worked on an off-shored project where the local team spoke English, all of the offshore developers spoke Mandarin, and their local representatives, who spoke English and Mandarin, translated between the two camps. He told me that the decision to use standard UML diagrams that every developer understood overcame many of the spoken language difficulties. He was adamant, though, that it would have been far more productive if everyone spoke the same language.
Strong Projects Have A Sense of Urgency
The ski slope team immediately organized itself into roles without needing orders. The respiratory doctor was the most senior medic and had the most relevant experience so she naturally took the leadership role. She and the nurses delivered chest compressions, the dentist helped with mouth-to-mouth ventilation, and the student nurse searched for help and a defibrillator.
Have you noticed how well-managed emergencies bring out the best in people? My first taste of management came when I was asked to temporarily manage the recovery of a project that had gone off the rails. The project was finished following an aggressive schedule and without overtime. The project was handed to me with built-in urgency and a clear goal—to save our bacon. Just like the ski slope team, we quickly organized around the goal, with people voluntarily picking up tasks that needed to be done even when they were outside their specialties. Each of us on that team performed way above the normal expectations, purely because the exceptional circumstances required us to.
The good news, if you are a manager, is that you don't need wait for an emergency to create a sense of urgency. Instead, if work with your staff to establish clear, concrete medium-term goals, give them good tools and then manage them with a light touch, then your people will often create their own sense of urgency.Strong Projects Build Relationships
Finally, there is one huge difference between the ski story and strong software development projects. Once the helicopter left the ski slope, the ad hoc team parted, with the individuals unlikely to meet again or even to meet the man whose life they saved. Good software projects concentrate not just on the software output by the project but also on the quality of the relationships established during the project. As individuals, the project becomes a single line on a resume, but it's the quality of the relationships with which you leave the project that sets you up for successful future projects.
