I’ve been flipping through my agile books looking for discussions about teams and safety. Many of the general books such as “Succeeding with Agile” by Mike Cohn and “Agile Software Development: The Cooperative Game” by Alistair Cockburn have sections on teams that contain very good information. But not a word about safety, at least by that word, “safety”. Maybe I don’t have the right books.

Somewhat confused by how important it is, and how little I can find, I’ve decided to explore the topic based on the suggestions from the participants at the AYE session.  One question I forgot to ask was “What does safety mean?”

The Wheelbarrow Test

The dictionary definition for safety (noun):
the condition of being protected from or unlikely to cause danger, risk, or injury

Since I can’t put a pound of safety in a wheelbarrow, this definition needs work to reduce the level of abstraction to something that can be measured. Most software development workplaces don’t involve danger or injury but we encounter risk, the possibility that something unpleasant or unwelcome will happen. For example …

Long ago my manager and I decided it was time to defragment the RA81 on the production Vax 11/750. At that time, the process involved making a tape back up, reformatting the disk, and restoring from the tape back up. The operators had the tape backups, so I just needed to wait until production completed for the day, reformat the drive, initialize the drive, and let the operator restore from tape. Things went to plan, until the operator told me, “Don, we don’t have a restore option available to us.” Suddenly, I realized the risk involved.

More recently a team I worked with needed to restructure a class that most of the application used. This required studying how the other 5 teams had used the class, refactoring the class and then testing the result to verify the application worked as expected. Certainty didn’t exist it could be done, or we should be the team to do the work, but if we didn’t deal with the risk now, it was going to grow and become more difficult to deal with in the future.

Safety – Take two

How about: 
Safety means people can take risks and their coworkers/management will support them, especially if setbacks occur.

The above examples had happy endings. Other than me losing a lot of sleep that night, the disk was restored and functional when production started the next morning. The team successfully refactored the classes and met their sprint goal. Not all risks have happy endings, and that’s when we need support.

Extending the thought that we can take risks means we can express our opinions. Esther Derby talks about this in Workplace Safety (and We’re Not Talking OSHA). There she defines safety “as the ability to speak your truth without fear of ridicule, rejection, or retribution.”

Combining the two we arrive at:
Safety means people can take risks and speak their truth without fear of ridicule, rejection, or retribution.

Safety doesn’t automatically happen. It requires support, practice, and patience. Having a common definition for safety with examples provides a starting point.

What does safety mean where you work? Leave a comment …

Your diagram is interesting, at least two ways.

First, when you’re not doing email (or phone) there are more “channels” than simply “language”. Indeed, in your example you two were operating with a particularly thin communication mechanism. One of the countermeasures, I think, is having a pile of communication channels going on at once, then you can compare between.

I suspect that the “Satir interaction model” is actually hanging out attached to at least “Experience of Experience” and “Sensory Experience.” We have attachments at these levels of experience as well, and make meaning that we can sometimes verbalize, but is pre-verbal in the meaning. “Bad thing” as an emotional, visceral response does, indeed exist in a way that the words “bad thing” don’t necessarily capture, and the words are after the fact, in addition to the words and word processes generating experience.

I suspect that having the additional processes going on has a an effect similar to the family of flight control systems in a space shuttle – richer, and thus more robust, and more interesting in what it generates.

Comments? Send me a note.

He called recently wondering why the software we’d developed quit working, and now wouldn’t compile. We spent a half hour discussing this line, that line, adding lines, commenting lines, and getting no where. Since my code compiled, I finally suggested he send me HIS copy of the code. The problem turned out to be a cross communication involving 4 lines of code (located in two different modules).

Somehow, for some reason, as we looked at the code, neither of us put the descriptions of what we saw together with the results Albert described. It wasn’t until I had his code that I found the difficulty. And why was that?

We were congruently communicating. We both wanted the same goal, but the longer we talked about the problem, the more frustrating it became. The Satir Interaction Model wasn’t helping. It turned out that the problem didn’t exist at the language level. It existed in the process of GETTING TO the language level.

Yet Another Model (YAM)

Here’s a model that shows one way of getting from the REAL WORLD, to the language level. I lifted this from Maps, Models, and the Structure of Reality.

Modeling Levels

Like all models, this model deletes, generalizes, and distorts information. I’ll probably blog more about this someday.

The real question we need to consider is: “Does this model provide a useful map of the territory?” To me it does. It shows (some of the) transforms we make between the “World Out There”, finally ending in language. Just so you’re not surprised, each logical level involves its own model, and moving from one logical level to the next one or more processes.

When we add the bi-directional (simplified) Satir Interaction Model, we get a more complete understanding of the problem Albert and I experienced.

Communicaton Model

In our case, the World At Large differed. When moving from his World At Large, Albert deleted information (and we all do). Even though I tried, I couldn’t “language” down his modeling path to understand his World At Large. Once I could see his World At Large, finding the compile problem became much easier. Our worlds were the same.

So the next time you’re talking with someone, and you see the conversation isn’t working, remember:

Even though you’re talking the same language, how you got to the language makes the meaning of the language.

Recently I spent two weeks in Berkeley CA helping a client upgrade one of their control systems. I wasn’t involved in creating the original system, but I do have experience with the software. We reverse engineered and re-created the system. Testing went well until the fateful day we hit the wall.

The task is simple enough. The operator makes a selection, which sets a boolean value TRUE. The control computer detects the FALSE-to-TRUE transition, and sets a local variable to TRUE. Six seconds later, the operator’s value gets set to FALSE. The value in the control computer remains TRUE until other events occur that set the variable to FALSE.

This was the map I used until things didn’t work. The communication between the two computers wasn’t happening like it did with the original system. The original communication protocol worked synchronously. The new communication protocol works asynchronously. This didn’t matter for most actions, but did create problems with this particular code section. And while we could bend, fold, and mutilate everything on the operator’s computer, we couldn’t make any changes on the control computer. To make matters more interesting, the interface logic occasionally worked. So my map was sometimes correct, and sometimes wrong!

After a day of testing, re-coding, and testing again, we finally resolved the issue so the interface reliably worked. The actual code changes were simple. We spent the majority of the day deciding if the map was correct and the territory wrong, or the territory was correct and the map needed changing.

Maps make it easier for us to work with the real world (whatever that may be). Some detailed information gets removed, but if the structure is similar to the territory, the map is useful. The problem is deciding when and how to change maps.