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.