What Can Developers Learn from their Surgeon?

I recently read a story that the World Health Organization (W.H.O.) issued a new safety checklist for surgical teams. Checklists sound great and frankly it was kind of surprising they weren’t already in practice. Here at our company we go through a number of checklists, and I can only assume you do as well. There are testing checklists to determine what test coverage exists, process checklists when products are about to ship, and integration points themselves could be considered a checklist of activities that need to occur for success.

What I found particularly interesting were the topics covered in the checklist. There are fundamental items like marking the location of the surgery, but I found the following to be the most topical:

*    Confirm that all team members have introduced themselves both by name and by their role on the surgical team.

*   The surgeon, anesthesia professional, and nurse should verbally confirm the patient’s identity, surgical site, and procedure to be performed.

*    Anticipated critical events to be reviewed by the surgeon are any critical or unexpected steps, estimated operative duration, and anticipated blood loss.

Keep it High-Level

Blood loss aside, what I find interesting about these items is how high level they are. You have team members participating as a team, identifying the areas of focus and activities. Staff executing risk analysis. Providing estimates. This is great.

SCRUM

We’ve been using Scrum. This means we have a 15 minute meeting once a day to go over our activities. We talk about what we did yesterday, what we are doing now, how long it should take and any risks to success. Sound familiar?

SCRUM HURDLES to HURDLE

Although Agile has been going well here for a while, there may be a number of initial hurdles to watch out for if you make this kind of change. Having to coordinate a day and time for all team members, then trying to keep the meeting to 15 minutes can be a challenge. It’s far too easy for development staff to lapse into traditional practices. When we first went to Scrum some of us would begin to discuss specific issues during the meeting (a Scrum no-no), and people would obviously start tuning out. This then translates into not knowing the more high-level team goals and activities.

Our first attempt to fix this, having everyone send a daily status email, at first just went to the team lead. The team lead knew what was going on, but it still didn’t solve the larger goal of having people be aware of their role and its impact on the team. We then tried to fix this, by group consensus, by everyone emailing the group with their daily status. This had the advantage of getting the format of the data consistent amongst the team, and getting information to everybody in the team. But it doesn’t get people to read the email. I now have a filter that automatically drops these into a directory that makes them easier to find, open, and read, or scan depending on my level of caffeine.

NOT LOSING SIGHT OF THE GOAL

So what I see as part of the goal, as well as what the W.H.O. was trying to achieve could be lost. Without the physical meeting everyone remains caught up in their own particular goals.

These personal goals are necessary, but they are not always conducive to team productivity.

Here we use Continuous Integration. We’ve been progressively converting more of our attended tests to unattended, increasing our product coverage and productivity. At the same time, staff members have been changing the test infrastructure to allow us to test varying configurations. Both are great goals, but in the beginning they ended up in conflict. One engineer was making more configuration settings required while another staffer was trying to make more of the configuration settings dynamic for portablity. The newly unattended tests were hanging or exiting early because configuration items unexpectedly became required.

Without a common goal, or at the least an understanding of everyones goals we run into conflict.

What else can be done?

When developers are used to being siloed, and their work feels isolated, they are more likely to tune out as to what is being done around them. But integration has to happen. And it has to work. Integration should no longer be thought of as somebody else’s problem, or as something that happens after the fact. Yes I was one of the people who didn’t like yet another meeting. I was one of the people who sometimes drifted into the mundane details of my work that I thought others would want to know, eating up meeting time. Now I champion the 15 minute meeting and keep people quick and to the point. And if everyone can start feeling like integration is the goal, then people will start thinking about how their work impacts others. Sharing that information in a timely manner will smooth out the bumps, and ultimately get us more focused on the larger goals. This isn’t “brain surgery”…or is it??