© 2011 Don Gray

The agile training class for a newly formed team was almost complete. We’d covered values, practices, roles, the product backlog, done simulations teaching the Scrum process and I could see the end of  training. A little team building activity, and we could start tomorrow with building the backlog, story sizing, then start the first sprint.  Forging ahead, the team selected a name, came up with a list of team norms, and they became a team with me as their ScrumMaster.

Or did they?

Over  the next few weeks, I noticed cracks appearing. One member tried to find ways to avoid the daily standup. Another member only checked in code toward the end of the sprint. Yet another happily worked on what he was assigned, but never volunteered to take tasks from the task board. At times, the entire team struggled to understand how its  activities blended with and supported the activities of the other teams on the project.

There didn’t seem to be a unifying focus, something with which all the team members could identify. What could I have done differently?

Forming a Team

Over the years, I’ve seen teams formed many different ways. There’s the Five You process where the manager goes “You, you, you, you, and you. You’re now a team!”  Often, these team members were selected because they were between projects, they possessed approximately the right skills, and it was time to get a new project started.

Matrixed teams form somewhat differently. Team members get assigned by skill level to projects. The greater (or rarer) your skill, the more teams you get assigned to on a part-time basis. This way, everyone has 100 percent of his time assigned to project work. I once met a QA “resource” (which in itself says a lot about the company) assigned to three Scrum teams. For some reason, he didn’t seem to get much done but go to meetings. Matrixed team assignments guarantees all projects get delivered in the maximum amount of time possible, if at all.

In the case of the team I worked with, the developers became a team because they all worked in the same office. I believe in collocation, but being together, in itself, doesn’t provide impetus to become a team. So what might?

What Makes a Team?

In The Wisdom of Teams¹ we find the conditions needed to exist for teams to form:

• A compelling work goal
• Interdependent work
• Stable membership
• Shared history
• Five to nine members

Interestingly, a compelling work goal often gets overlooked. The team had work to do, but I don’t believe “We’re part of an project that will save the company a bunch of money” constitutes a compelling work goal. Don’t get me wrong, helping the company save money is a good thing, but does it call forth the urge to slay dragons or at remove impediments from the development process?

We did have interdependent work, both within the team and between the teams. Other than some members not checking code in regularly, a lot of thought and effort went into making sure the teams’ code didn’t break other parts of the application. The code management system and continuous integration worked quite well when developers did check in their code.

This team had sort of worked together prior to my arrival. The team members knew each other but divided the work so they had the minimum amount of interaction. So, while they had stable team membership, how they handled work created knowledge silos and prevented them from learning from each other.

Shared history initially seems to indicate the team has to work together for some time. I’ve learned since my work with this team to use experiential activities to actively start creating shared history instead of letting the shared history happen and hope for the best.

Teams generally need five members. This allows for sufficient skill, experience, and knowledge to generate good decisions and actions. When teams get more than nine members, the communications paths tend to become centralized and the larger group informally splits into two smaller groups, losing a coherent whole.

Creating a Team

Creating a team involves more than picking five to nine people then having them pick a name (although choosing a name for the team can be both fun and enlightening). Managers usually set the initial team membership and pick the project on which the team will work. This means managers need to align the team members’ skills so they can fulfill the project’s vision. If the project doesn’t have a vision statement how can the team coalesce around a compelling work goal? It doesn’t exist.

Team formation activities can range from creating a formal team charter to the Five You process. It may make sense for some teams to go through the formal process of documenting the purpose; summarizing their structure, customers, and stakeholders; listing the members; identifying roles; and defining the team’s authority—but I don’t usually see this in agile software development teams.

With the team members selected we can do specific activities to help create team identity, highlight the team’s purpose and establish ground rules.

Team Identity Activity—Design a Box

This activity lets the team define itself and create an identity to share with the rest of the organization.

Team members need to design a shrink-wrap box that represents their team.  They design the box front and back. This involves:

• Coming up with a team name
• A picture
• Three to four key bullet points on the front to “sell” the team
• A detailed feature description on the back
• Operating parameters

It also tends to be a lot of fun.

Team Purpose Activity—Team Elevator Statement

This activity focuses on the “compelling work.”It aligns the team’s actions with the product vision and corporate mission statement. It’s the team’s reason d’être.

Using the “elevator speech” format helps the team succinctly pull these ideas into a sentence they can share with others.

For [target customers]who wants/needs [solution to a problem] <your team> provides <what compelling reason to buy>. Unlike <competitors/other teams> <the team key differentiator>.

Working Agreements

Working agreements specify the team’s operating parameters. They list expectations between the team members. They serve as guide rails as the team builds its shared history. They might include meeting information, team norms, a definition of done, and other pertinent items.

When working with the team to create its working agreements, I use the expand-then-collapse facilitation process. After explaining the goal for the working agreements, I solicit suggestions from the team members about what they feel will be important to them. I use stickies for this. Then we post the stickies, having a conversation about what the words mean. After we have everyone’s input, we look for duplicates, suggestions that form part of another suggestion. We aim for seven to nine agreements. Anything more results in a list no one can remember.

I’d be lying if I told you these activities automatically create great teams. Nothing can automatically create great teams. But, by focusing on your team’s purpose, identity, and working agreements you can help team members answer the question “Why am I here?” and set the team up for success.

¹ The Wisdom of Teams, Katzenbach and Smith, Harper 2003, ISBN 978-0060522001 pp 43-64.

This article originally published on Project Management (http://manage.techwell.com) March 09, 2011

What Does Trust Mean?

I like to use the following four beliefs I learned from Esther Derby to define trust in the workplace.

1. I believe you have the ability to do the things you say you’ll do.
2. I believe you will do the things you agree to do  – or let me know when you need to renegotiate.
3. I believe you have good intentions towards me.
4. I believe that if you have an issue with me, you’ll bring it up directly with me, not talk behind my back.

Following these points makes trust building somewhat straight forward. I do what I say I’m going to do. If something happens and it looks like I won’t be able to meet my commitment, I say so. I’ll talk with you instead of talking with others about you.

Is It Always That Simple?

It can be that simple. Sometimes things get complicated when actions and information get interpreted differently. These complications often happen when we’re tired, in a hurry, don’t take time to process what’s happening here and now and resort to a “then and there” responses. “Then and there” responses come from our past and at some level remind us of the current situation. We not only respond as if the current situation exactly resembles the prior situation (it doesn’t) we can get the meta-response of “not this again!”

Here’s some ideas what to do:

1. Count to 10. This allows you a chance to focus on a breath or two and replay  what just happened.
2. Consider how your intake preferences might be influencing what you’re feeling.
3. Remember we’re all different.
   • I’ve had discussions where it turned out we both argued for the same point, but we used different words.
   • Different values motivate us. (see the Why Not Ask Why? sidebar )
   • We have different work styles.
   • We have different capabilities.
4. Allow for generous interpretations. Seek to understand the other person’s view point.

Having a shared history with your team members helps generate trust. You know their capabilities and how they’ve performed so far. If a team member hasn’t performed according to their commitments people remember and judge this commitment accordingly.

If the team has recently formed, take every opportunity to learn more about your new team mates, their similarities and differences. This can happen as part of both formal  (pair programming, lunch and learns) and informal (coffee breaks etc) activities.

Like safety, trust can come and go based on the context and what’s happening. You can unilaterally decide to trust a teammate. How their response fits the four beliefs determines how much you continue to trust them.

It all started with a tweet I posted:

“Why” questions trigger feelings bypassing data input and thinking. #dontdothat

As this got retweeted, interesting questions started coming my way:

• What about the Five Whys?
• Do you have data?
• What is your context?

All good questions.

“Why” questions have the ability to both gather data and to probe for underlying thoughts and decisions that lead to action. Other interrogatives (what, when, where, how) provide a better way to gather data since they focus on physical items or actions.

So when do “Why” questions work well? How might “Why” questions lead to unexpected results? What can we do about that?

Solving Problems: Toyota and the Five Whys

I was writing process control code for a living when I first heard about the Five Whys. It made sense for finding a problem’s root cause. The example went something like this:

1. Why did the line stop? Because the conveyor gear reduction box froze.
2. Why did the gear reduction box freeze? Because it didn’t get lubricated during the last preventive maintenance.
3. Why didn’t it get lubricated during the last maintenance? It’s a new piece of equipment and wasn’t on the preventive maintenance check list.
4. Why didn’t it get added to the maintenance check list when it was installed? Because we don’t have a standard way of adding items to the check list.
5. How can we create a standard way of adding items to the check list so this won’t happen again?

Asking why uncovers another layer of information that eventually leads to the problem’s root cause and allows us to craft a solution to (hopefully) prevent the problem. Since we’re starting with observable data, asking why works well here.

Gathering Data: Five-year-old Whys

Anyone who has spent time around children has probably experienced a period of incessant whys.

Why is the sky blue? Because air molecules scatter light from the sun.

Why do the air molecules scatter the light? Because they get in the way of the sun’s rays.

Why do they get in the way?

(And so on.)

Often, the question-and-answer process ends with “Because I said so, that’s why.”

Asking why provides children with new information, and data expands their knowledge, so why works well here—at least until “Because I said so.”

When Why Might Not Work Well

Your teammates, managers, and coworkers are neither mechanical processes, which don’t care if we talk about them, nor five-year-olds attempting to gather more information about their world. They come complete with experiences you don’t know about and ideas about how things should work. As such, your why questions may trigger in others an emotional response that catches you unaware. What might generate such a response?

An Interaction Model

The Satir Interaction Model [1] provides a framework for understanding how interactions proceed, as shown in figure 1.

Figure 1

Take Tony, for example. You’ve noticed the build server has been sending emails announcing that the build broke, and Tony usually makes the commit that occurred just before the build that broke. Wanting to be helpful, you head to Tony’s cube and ask, “Why do you keep breaking the build?” You’re looking for information. The message has been spoken and becomes the input.

Based on how Tony feels and his background, he can infer several different meanings. He may think you’re picking on him. He may think you mean “Tony, you’re incompetent.” He may interpret the question as a request for information.

The meaning Tony chooses determines his feelings about your message. If he thinks you’re picking on him, perhaps he will feel afraid or threatened. If he believes you think he’s incompetent, he might become defensive, or he might be relieved that you might help with the problems he’s having.

Tony also will have feelings about those feelings based on his background. Perhaps his father taught him not to back down when threatened, or to prove you’re right when challenged, or even that accepting help shows weakness. Tony may feel ashamed, angry, confused, or relieved.

Based on Tony’s life experiences, he may defend himself by:

• Blaming—“The stupid formatting rules take too long to check. If IT would buy us better computers, this would not happen.”
• Placating—“I’m so stupid. I should do better.”
• Being super-reasonable—“Has anyone checked the rules on the build server to make sure they agree with how the builds work on my workstation?”
• Feigning irrelevance—“It’s almost lunch. Where should I go today?”

After these steps, Tony will work on his response. What can he safely say? What do his family, social, and corporate cultures say about what he can say? Some comments can be career limiting. Does he have an “always be agreeable” rule? These commenting rules affect his verbal response.

Everything between the Intake and Response steps happen internally for Tony, but you can guess what happens based on his response. If Tony replies in a way congruent with your intention—“I’m having problems with formatting. Can you help me figure out what’s happening?”—the request for information succeeded. If Tony becomes bellicose, belligerent, or his answer bewilders you, the question triggered a meaning and feeling not related to your request for information.

The Interaction Model and Temperaments

Figure 2

In Congruent Action [2] Gerald M. (Jerry) Weinberg collapses the steps from Feelings through Defenses into a single step, which he calls Significance, and correlates how Keirsey’s Temperaments [3] (see the sidebar) tend to work through the Interaction Model:

• SJs stay in Intake mode too long.
• NTs tend to go instantly to Meaning.
• NFs tend to jump immediately to Significance.
• SPs go so fast it looks to others as if they jump instantly to Response.

More than half of IT professionals implicitly skip the Intake step based on their personality preference. You want to know “why” to collect data—41.6 percent will look for the meaning behind your question and another 12.1 percent think about how the question makes them feel.

Jerry offers the following suggestions:

• For NTs/NFs, ask, “What did you see or hear that led you to that conclusion?”
• For SJs, ask, “What can we conclude from the data we have so far?”
• For SPs, appeal to their desire to be clever and ask them to teach you how they did it.

Use Data Questions to Gather Data

Questions that start with other interrogative words, such as when, what, where, and how, help people focus on the data aspect of the question.

If we ask Tony a different question, we can help him focus on the data we would like to know—for example, “What steps do you take prior to committing to the build server?” or “How do you decide it’s time to commit your code?” Tony still traverses the Interaction Model, but we’ve explicitly asked for data.

Over the years, I’ve had some why questions bounce back to me with responses that left me wondering how what I said triggered that response. Using the Satir Interaction Model, I’ve learned to unravel the responses. I’ve also learned that if I want data, I should use data-oriented questions that start with how, what, when, and where, and use why as a last choice.

On the other hand, if you want practice unraveling communications, start with why as often as possible.

[SIDEBAR]

Temperaments

“There are two types of people: people who divide people into two types and those who don’t.” –Barth’s Distinction

Dividing people into groups is a time-honored tradition. Circa 340 BC, Plato divided people into four groups: Artisans, Guardians, Idealists, and Rationals. Since then, many others, including Aristotle, Galen, Paracelsus, Fromm, and Myers, have found ways to divide people into four groups.

In 1978, David Keirsey and Marilyn Bates “developed and described” the temperaments “in modern form.” They “found that selectively combining [N with T/F and S with J/P] produced a descriptive personality system similar to the four temperaments … described centuries earlier.” [4]

“When the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” –Abraham Maslow

I like to remind clients that temperaments represent one way of understanding people and how they interact.

References

1. The Satir Model: Family Therapy and Beyond, 1991, Science & Behavior Books, Inc., pp 121-129
2. Quality Software Management, Volume 3, Congruent Action, 1994, Gerald M. Weinberg, pp 108-109
3. Please Understand Me II, 1998, Prometheus Nemesis Book Company
4. MBTI Manual: A Guide to the Development and Use of the Myers-Briggs Type Indicator, 2003, Isabel Briggs Myers and Mary H. McCaulley
5. From What Type Am I? Discover Who You Really Are, 1998, Renee Baron
6. From the Myers-Briggs Type Indicator Atlas of Type Tables, Macdaid, McCaulley, and Kainz, CAPT, 1985

This article was originally posted on StickyMinds.com on January 28, 2011

• Physical sensations – information coming into us from “the real world”.
• Beliefs and Values – concepts and things important to us
• Feelings – both physical and self-esteem
• Data/facts – information I “know”
• Thoughts – What we do with the data/facts
• Intuition – Hunches based on experience without supporting data (at this time)
• Concerns/Fears
• Desires/Requests – What I want to have happen

If we stopped and consciously processed each step all the time, civilization would screech to a halt. How can we create a safe environment and still create value for our clients?

Beliefs and Values – The Invisible Elephant

We don’t walk around the office starting conversations with “Well, I believe that …” or “Given my values …”, yet our beliefs and values form the seed for our behavior.

We get some of our values and beliefs from our environment. The culture and family we’re part of greatly influence us. Strong hierarchical relationships make sense in some cultures but seem stifling and ill-informed in cultures that value independence. Another source involves our experience. Behavior that resulted in positive outcomes get reinforced and converted into beliefs about how we should behave. Having been part of a lot a decisions I have a belief that including everyones ideas about the decision helps create a better decision.

With a list of values and beliefs we can know what is important to our team, but this list doesn’t tell us how to behave.

Team Norms – The Team’s Guard Rails

Moving one step closer to safety brings us to team norms. Team norms tell us what behavior we expect from the group. Team norms for getting everyone’s ideas might include:

• Respect each others views.
• Let everyone have a say.
• Don’t interrupt while someone is talking.

With this list team members can compare behavior with how the team expects its members to behave.

I’ve seen these lists referred to working agreements, norms, ground rules. As guard rails they serve to keep behavior in some range and allow team members to point out when a member is not staying within the range of acceptable behavior.

Simple rules – Generating Patterns of Behavior

Like team norms, we create simple rules based on the team’s beliefs and values. Simple rules provide guidance for decisions and action when situations are less than predictable. Simple rules can generalize to fit most situations eliminating the need for an exhaustive list of acceptable / unacceptable behavior.
A simple rule for the getting everyones ideas might be:

• Seek first to understand, then be understood.

Some guidelines for simple rules include:

• Keep rules to “minimum specifications”.
• Rules should be both generalizable and scalable.
• Each rule should begin with an action verb and be stated in the positive.
• The list should be short, seven to nine as a maximum. The list should include at least one rule for these general areas:
  • who we are as a group
  • how the team will deal with differences
  • how the team will exchange ideas and information both within the team and with the organization.

Creating simple rules allows team members to act accordingly and know the team will support them.

What techniques/models do you use for creating team behavior? Leave a comment …

Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

“Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

The Tangled Web

It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

We can see in the following diagram that Engelbert had at least three options available to him. He could:

• Respond negatively, looking for reasons, usually blaming someone else) for the results.
• Decide no difference exists by ignoring the results and do nothing.
• Respond constructively, learning from what happened and improving at getting the results we desire.

Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a “success”) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

Let the Game Begin

Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

Blame affects organizations on multiple levels creating different problems.

• Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
• If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
• Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
• Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.

So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

An Ounce of Prevention

The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

• Observe what’s actually happening. Are people doing what they say they’re doing?
• Listen to the language people use. Do you hear blaming?
• Does it feel like there’s an elephant in the room that no one acknowledges?

No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like “It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

Multi-level Blame

Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

What’s A Girl To Do?

At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

Engelbert frowned, trying to understand why Pamela had been acting strangely. Her programming skills were among the best in the company. She had a way of getting things completed. That’s why he made her project lead for Uberdenke’s next UDCRM product release.

With only two weeks left until the ship date, Pamela’s personality had shifted. Normally calm and composed, she had been seen crying after meetings. Occasionally he could hear her screaming at the programmers working for her. Something had to be done. He was going to have to figure out what was wrong with Pamela. And fix it.

Engelbert’s decision casts Pamela as an “Identified Patient.” The Identified Patient becomes the focal point for the Engelbert’s intervention work to “solve the problem”. When Pamela is “cured”, Engelbert thinks, he can return to his normal schedule. Until then, he has more important work to do.

What happens when Engelbert becomes involved with the Identified Patient Pattern? And is Pamela’s behavior change really the problem? Could there be a fundamental problem that Engelbert is overlooking? What effect does Pamela’s behavior have on the project?

Identified Patient Dynamics

Trying to answer these questions requires considering several
points. As Pamela’s behavior becomes more pronounced:

• People become distracted.
• Extra work gets created (trying to “cure” Pamela) and time gets spent doing non-productive tasks (appeasing Pamela, hiding, gossiping).
• The less useful work gets done.

This seems straight forward enough. But how do these relate to each other? Using a diagram of effects we can visually represent the process as

Figure 1 – Identified Patient Activity

This diagram shows the downstream effects these actions cause. Eventually these actions adversely impact Remaining Work, which increases Deadline Pressure, which increases Identified Patient Activity Level. And the dynamic starts over again with amplification due to the prior looping. The loops are all negative feedback loops. This means once Pamela (or anyone) becomes the Identified Patient, the system starts down hill, and continues until it hits a natural limit and stabilizes or collapses.

Without knowing it, Engelbert and the UDCRM team become embroiled in activities that add more pressure to system, thereby creating more Identified Patient Activity Level on Pamela’s part. By trying to “cure” Pamela, Engelbert engages in treating the symptom, not fixing the problem. In this case, Deadline Pressure continues to build, creating more stress and exacerbating the Identified Patient Activity Level.

All Stressed Up and No Where to Go

What does Pamela’s worldview look like? She’s the project lead for the next release of UDCRM. The project started with a bad release date (see “The Liar’s Contest”). Engelbert knows this (“No Exit). The project team can look at the remaining work and see they won’t make the ship date.

Uberdenke has to two intertwined systems: the formal hierarchical system with nice boxes and lines, and the informal “shadow” system formed by acquaintances, friends, antagonists, history, and working relationships. The intertwined systems can be congruent or incongruent. When the systems are incongruent, the informal system struggles to compensate–not always effectively–as long as possible. When the informal system can no longer compensate, it doesn’t degrade slowly, it collapses.

In this case the formal system won’t acknowledge the inevitable until it’s too late. The project team (informal system) knows they can’t meet the date, but for a variety of reasons don’t feel able to update the formal system with their reality. The incongruence between the formal and informal system takes a mental and physical toll on the employees by creating stress. To protect the others from blame, one of the people may actively (but perhaps not consciously) adopt the role of Identified Patient by “acting out” in bizarre ways. This behavior serves to distract management’s attention from the other people, but at the same time distracts them from the true, underlying problems. In the short run, then, Pamela is rewarded for her bizarre behavior, and reinforced to continue “protecting others.”

As project lead Pamela embodies the stress and manifests it via her behavior. As her stress level goes up, her behavior becomes more erratic. As her behavior becomes more erratic, the less remaining work gets finished (see above figure), which increases the project tension and so on.

When Engelbert starts trying to “cure” Pamela, two problems occur. First, the Identified Patient dynamic starts, engaging the negative feedback loops. Second, Engelbert’s attention becomes focused on Pamela, and misses the opportunity to look for a fundamental problem. Trying to “cure” Pamela may momentarily reduce pain, but–because the real problems are not being addressed–this ultimately leads to system collapse and much more pain.

Combining Pamela’s stress and Engelbert’s actions results in the following diagram.

Figure 2 -Triangulation

Once again we see two negative self-reinforcing loops:

• Pamela’s Tension/Stress/Patient Loop
• Engelbert’s Tension/Stress/Patient/Responsiveness Loop

Both loops keep on keeping on, resulting in more of what we already have. This results from the Identified Patient’s second order nature. Second order nature doesn’t mean the tension and stress aren’t real. It means some other problem causes this problem. Trying to cure an Identified Patient is like scratching athlete’s foot. You’re doing something that feels good, but when you quit scratching you still have athlete’s foot, and wounds from the scratching, which has also spread the fungus more widely.

To improve the situation, Engelbert needs to move from the negative reinforcing loop to the Tension/Stress/Awareness/Responsiveness balancing loop.

What You See isn’t What You Get

To “cure” Pamela, Engelbert needs to determine what’s making Pamela act out. Difficulties with this include:

• Something in the formal system doesn’t want to know what the informal system knows.
• Pamela’s behavior masks the real problem.
• Engelbert may not have the interpersonal skills needed for this.

Management acknowledging the delivery slip would relieve the deadline pressure and stress wouldn’t build. Unfortunately managers promote what they want to hear with such comments as:

• I don’t want to hear problems, I want hear solutions.
• Our competitor can do this, why can’t we?
• You’ll just have to work smarter.
• If you can’t do this, I’ll find someone who can.

Comments like these ensure that managers only hear good news, until there’s no possible way to hide the bad news. Then they ask, “Why didn’t they tell me sooner?”

Pamela’s behavior indicates a problem exists, but doesn’t give a clue what it might be. Pamela could be acting out because of:

• Work stress (our example).
• Triangulation (compensating and covering for a fellow employee).
• Problems at home.
• Substance abuse.
• Sexual harassment at work.
• Some other unresolved problem.

Most software development managers made it there by having great technical skills, not great people skills. If Engelbert discovers the problem isn’t work related, he’ll need help. Dealing with personal problems in a work environment can be a legal minefield, and is best left to people trained to do it.

In the extreme case, Engelbert may choose to blame Pamela for the project’s problems. While incongruent and counterproductive in the long term, this tack appears to have short-term benefits. Pamela becomes the scapegoat, and hopefully the problems will leave when she does. In the mean time, a new delivery date will be set (while in panic mode). This temporarily relieves the Deadline Pressure. This dynamic may execute several times, until eventually some new delivery date finally provides the time necessary to complete the project. Or, the project collapses under all this extra effort and emotion.

Dealing with an Identified Patient

Identified Patients exist everywhere. The tip-off comes when you hear or think, “Things would be better if this person would just leave.” In reality, that person leaving won’t change the underlying system, and someone else will take on the role. The key to success starts with understanding the Identified Patient functions like a canary in a mine. They provide an early indication something is wrong and needs to be dealt with, but replacing the dead canary will not clean the toxins out of the air. Unfortunately, unlike the canary whose death tells the miners that the air is probably poisonous, the Identified Patient doesn’t indicate what problem exists. One thing for Engelbert to consider: the closer he gets to finding the real problem, the more Pamela may act out. One of Engelbert’s options involves getting the UDCRM team to focus on the remaining work, thereby reducing the attention given to the Identified Patient Activity Level. This becomes an exercise in active support and barrier removal, not platitudes and posters about success through working harder. If the Identified Patient Activity Level gets even larger, this indicates that something else is going on.

If Engelbert can remove Pamela from the system, it might allow the problem to show. Of course removing Pamela might cause other problems which would again mask the original problem provoking Pamela’s behavior. Another person becoming the Identified Patient would indicate underlying system problems. If the Identified Patient Activity Level prevents any useful work from being accomplished, this may be the first action to take. Hopefully, Engelbert will be able to find and fix the problem that created the IP. Engelbert needs to be aware some fixes actually exacerbate the symptomatic problem. Common fixes that fit this dynamic include:

• Adding tools leads to the “worse before better” dynamic as productivity drops while people get used to the new tools.
• Splitting tasks leads to the communications/interface dynamic where information needs to flow through more paths and permutes while doing so.
• Splitting people between tasks leads to context swapping overhead, that period of time it takes to remember where you were and get back into the flow.
• Adding new people to the project basically incorporates all the above dynamics.

Stress Reduction

Engelbert has several options available to relieve the Deadline Pressure causing Pamela’s behavior. He can use any one of three project leverage points to change the amount of Deadline Pressure:

• Features – If the number of features decreases, the Remaining Work decreases, which decreases Deadline Pressure.
• Quality Goal – If the acceptable quality is reduced, the Remaining Work reduces, which reduces Deadline Pressure.
• Desired Ship Date – As the Desired Ship Date gets bigger (more days to ship), Deadline Pressure goes down.

This looks like:

Figure 3 – Intervention Points

At this level we now have balancing feedback loops that help stabilize the system. Selecting the best leverage point or combination involves determining how the Uberdenke clients can best be served.

What to do if you’re the IP

Identified Patient behavior has several possible causes. These include:

• Boredom – which results in irrelevant behavior
• Triangulation – based on placating behavior. Could be caused by
  • Incongruent formal/informal systems
  • Compensating for other people in the system.
• Really bad managers using blame to cope with bad results from poor decisions.

Identified Patient behavior is a symptom, not a cause. If management does recognize the behavior, they’ll most likely try to fix you, not the cause. Unless you want to be “fixed”, it’s important to recognize the source of your incongruent behavior. This enables you to work on becoming more congruent and changing the source of the Identified Patient behavior.

“If what you’re doing isn’t working, try something else.” Marvin’s First Law¹

If you’re bored, change yourself. Try and find a more challenging position in the company. Take up a hobby that will provide the challenge you’re looking for. If necessary, consider changing companies. Get interested in solving some real problem that’s hindering others.

Triangulating due to incongruent systems doesn’t accomplish anything. The systems eventually align when the informal system collapses and the formal system has no choice. This usually happens too late to do meaningful risk management and damage control. Much pain accompanies the collapse. Trying to alert the formal system to impending doom may get you labeled as “Nay-sayer”, “Not a team player” and such. If this happens, consider changing companies.

While a nice concept for those taught to “play nice with the other kids”, triangulating by covering for other people boomerangs at two levels. You’re not going to be able to do the work for two people, the amount of remaining work will go up, leading to deadline stress, and the incongruent systems dynamic comes into play. Along the way, you’ll become exhausted and your health, both mentally and physically will deteriorate. This reduces your ability to produce and the cycle starts over again. It’s OK to occasionally help other people. But if helping other people gets in the way of getting your job done, learn to say no, or find another company to work for. Whatever you do, do it directly. There’s enough confusion without adding triangles to the mix.

Lastly, if you can’t change the system, and changing companies isn’t an option (and sometimes it isn’t), recognizing the dynamics that create the Identified Patient behavior can help you cope as congruently as possible.

And in conclusion

Identified Patients indicate something is wrong. Trying to “cure” Identified Patients seems important, but lowers the amount of useful work accomplished. Locating and correcting the fundamental problem is the best way to “cure” the Identified Patient. Engelbert needs to remember that correcting the fundamental problem may temporarily cause other problems.

¹ Weinberg, G.M., The Secrets of Consulting. 1986, New York: Dorset House Publishing

Throughout the day we will feel differently about the risks we’re willing to take and what we might say. I’ve seen conversations spin on a dime when a senior manager stuck his head in the conference room.

How can we measure safety in the workplace? What does it mean to productivity?

The Safety Check

The Safety Check activity provides an understanding of how safe people in a group feel. The group may be an interdependent team, peer managers problem solving, or perhaps a status meeting containing the team, its manager and their director. Each scenario presents different dynamics and you may want to investigate how safety shifts between them.

The Safety Check

1. Introduction – Set the stage for the activity. You’ll probably use a slightly different description for a team brain-storming session than a multi-level status meeting. Briefly explain the process.
2. Prior to the meeting create a flip chart that contains 5 safety levels. The levels range from completely safe, to completely unsafe. This might look like:

Put the flip chart on a wall and share the descriptions for the 4 − 0 values.

Be sure to change the descriptions to fit your context.
3. Handout ballot – some indistinguishable piece of paper.
4. Ask the participants put their safety level on the ballot and fold the ballot in half. Tell them you’ll collect the ballots, create a chart, and you personally will dispose of the ballots.
5. Collect the ballots in a hat or other container
6. Create a histogram that shows the ballots – it might look something like this:

7. Keep the ballots in your pocket or somewhere and dispose of them after the meeting. I usually do so at a different location.
8. Debrief the findings in light of the data and meeting purpose.

The Safety Check measures our truth, our safety. We all have different values for “what makes me feel safe”. Your values apply to you. My values apply to me. As we build the histogram we get a view of how safe we feel. This leads to an understanding of how much risk we’re willing to take and how likely we are to share our truth. Doing the Safety Check first tells us how safe the team feels and if we need to continue with secret ballots.

Knowing how safe people feel starts the data collection.

What Put the Number Where it is?

What has happened that put your safety number where it is? Does your manager yell at you when she doesn’t get the results she’s hoping to? Possibly new to the team and not sure how to work with the others? A team member runs to the manager when things don’t go their way? Arguing and verbal fisticuffs during planning sessions? The examples I offer seem negative. They could have as easily been positive examples.

By gathering this data, team members and managers discover the behaviors that hinder or help with safety.

What Does Low Safety Cost?

A technique I learned from Esther Derby sheds light on how low safety affects performance and innovation. To do this activity  ask people to fill in the blanks in these sentences:

“When I feel safe, I can_____________.”
“When I don’t feel safe, I _________.”

The answers generate very interesting results and make the costs associated with unsafe environments visible.

What Would It Take?

By now we know how safe the team feels, how it got that way, and what costs associate with that environment. Technically this next question becomes part of the solutions focus.

“What would it take to raise your number 1 level? If you number is a 1, what would it take to get you to a 2?” Having a list of possible changes provides a path to improved safety.

Do you have another method for determining safety? If so please leave a comment …

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 …

Thank you again to Jeff Barschaw, the other agile-RTP organizers, and agile-RTP members!

• “What did we do well?”
• “What could we do better?”
• “What one thing would we like to work on during the next sprint”

Is your team starting to push back on taking the time for their retrospective?

If so …

Increase your team’s effectiveness by facilitating better retrospectives. We will demonstrate and teach:

• How to establish a retrospective’s goal.
• What constitutes an effective retrospective.
• Which activities generate information and which help make decisions.
• Common traps, pitfalls and mistakes.

By improving your retrospective facilitation you can help your team continuously improve their methods, teamwork, and organizational relationships.

Audience: Agile coaches, ScrumMasters, team leads and team members who wish to improve their retrospective facilitation skills.

Workshop Duration: One day

Workshop Outline:

1. Greetings & Introductions.
2. Class project and retrospective.
3. Analysis of the retrospective.
4. Practice designing a retrospective.
5. Group design review.
6. Wrap-up.

This class is limited to 20 participants.

Workshop Facilitators: Esther Derby and Don Gray