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

I was flipping through an old work note book and came across the following story.

I spent three days working with a client who had adopted Scrum for project management about six months earlier. On the fourth day I attended a Sprint planning two (user stories to task with time estimates) meeting. As we talked about stories and sizes, George asked the following question. “How do we deal with work that is too big to finish in a sprint?” In all my time coaching teams, I haven’t found a user story so large that it couldn’t be done in a sprint. If there is such a story, it usually an epic that can be further divided into smaller stories.

Wanting to be helpful I said, “Well, split the story into smaller stories.” Mentally allowing that I haven’t seen all the possible user stories in the world (and there /MIGHT/ be one story so large it couldn’t be finished in a sprint, I continued … “If that doesn’t work, pull the work into the sprint and burn down as much as possible. You don’t get velocity points, but if the backlog is properly ordered you’ll have work done for the start of the next sprint.” Hoping to point to some future perfect day where the team was burning down faster than anticipated I added, “It’s just like when the sprint burns down faster than estimated. You pick the next story from the Product Backlog and start work on it.”

George replied “We’d never do that. We get graded on how well we complete our stories. If we have unfinished work it counts against us.”

The Fundamental Software Development Process

The fundamental software development process looks like:

This system dynamics drawing² varies somewhat from the Diagram of Effects (aka Causal Loop Diagram) I often use by showing the stocks (levels) and flows (rates) associated with the development process. User stories flow into the Product Backlog. The team converts the user stories into Implemented Features at some rate (Velocity). By and large it’s how everyone develops software. Steps may have different names and take more time to complete (or not) but we take what user’s want and give them software that performs those actions.

An important aspect of the Fundamental Software Development Process involves recognizing it’s an open loop system and open loop systems are inherently stable. User stories come in as they will and become part of the Product Backlog. The team works at some natural development speed based on their abilities, the story complexity, and their intrinsic motivation. The Implemented Features accumulate and eventually the software gets released to the users. Based on the Product Backlog size (in story points) and the team’s velocity (in story points) it’s possible to calculate when the next releasable set of Implemented Features will be ready to go to the users.

But what if that date isn’t soon enough?

Add Some Feedback

The conversation with George happened my last day on site and I had meetings stacked the rest of the day. But on the flight home I started wondering, “Why would someone want to ‘grade’ the teams on how well they completed the stories?” One answer is to build confidence in team’s velocity value. Another possible explanation would be a behavioral assumption that the developers tend to avoid work and a way to make sure the developers don’t shirk is to compare the sprint results with the estimates made during the sprint planning.

Whatever the reason for “grading” the sprints, the action of “grading” has created a feedback loop in the system. Adding feedback means taking a system output and sending that output (or some portion there of) back into the system input. I wrote about feedback control loops in Multi-Use Model. Feedback loops provide the opportunity for control, aiming the system at some new target such as a new delivery date. Unfortunately feedback also provokes instability in the system. Unless great care is taken, the system becomes dysfunctional at best and destructive at worst. The Fundamental Development Process now looks like:

The “split” rectangle means management has a choice at this point. They can choose to “grade” sprint results or not. If the grading happens, the rest of the reinforcing loop happens. In a nutshell:

• Team members want to look good. I don’t know if “counts against us” includes performance evaluation, but it could.
• Since the team wants to look good, they’re not likely to take risks. Not taking risks could mean:
  1. Not bringing additional work if they finish early.
  2. Inflating story points for user stories during estimating sessions.
• Since the team won’t take risks, measured velocity won’t decrease (and indeed may increase) while actual velocity (the rate of delivering implemented features) may decrease. As Robert Austin notes:

Boomerang Measurement

I confess I’m doing a certain amount of mind reading now since I didn’t have a chance to talk with the person who decided grading the sprint results would be a “good thing”. But I can’t wrap my mind around the concept that they explicitly set out to slow the development process. But they did, we have another boomerang measurement.

Truth be told, I believe the person thought they were (are?) doing the best possible actions to help the developers be more efficient. I’m serious. You can’t make up stuff like this.

For more information on how management goes astray with measurements I recommend reading Measuring and Managing Performance in Organizations by Robert Austin and Slack, Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco.

Got an example of a boomerang measurement? Drop me a note.

¹I first heard this line from Jerry (Gerald M.) Weinberg
²http://en.wikipedia.org/wiki/System_dynamics
³Measuring and Managing Performance in Organizations Dorset House Publishing, ISBN 0-932633-36-6, page 38

Why is it so?
Jerry (Gerald M.) Weinberg chose to use Brook’s Law in Quality Software Management: Vol 1. Systems Thinking to demonstrate non-linear feedback systems. Combining Fig 5-1 (page 78) and Fig 6-4 (page 93) gives us:

Brooks' Law

I describe how to read Diagram of Effects here.

In essence adding manpower affects the system by:

1. Creating more communication paths. The number of communication paths is n*(n-1) where n equals the number of team members. This says increasing from 4 to 6 members increases communication paths from 12 to 30.
2. Adding new team members creates a training load on the existing team members. This in turn reduces the productive work finished.

These problems get exacerbated when managers decide to add “extra” manpower just to be sure the project doesn’t slip any more.

Communications and Sharing Information

Tools to support software development methods have changed since Brooks’ Law was introduced. We now have information radiators for sharing information in parallel. By simply walking around your office it’s possible to learn information about the project. Additionally wikis, build systems, source code management are types of information magnets. They hold pertinent information that can be searched, sorted and reviewed.

There’s a sliding window of opportunity where manpower can be added to a project and not negatively impact the schedule. This window closes when the additional productivity achieved by adding more staff isn’t enough to offset the lost production due to training them. According to Israel Gat, BMC Software staffed the two releases with 80-95 developers compared to other companies who staffed similar sized projects with 25-35 developers. This staffing level resulted in product delivery in 4.5 – 5 months instead of over a year. This rapid delivery creates problems for the downstream organizational activities such as marketing, sales, revenue recognition and the back office. BMC Software recognizes this problem and is currently working on synchronizing the activities.

How to Beat Brooks’ Law

The state that invokes Brooks’ Law is “late”. To beat Brooks’ Law all you have to do is avoid having late projects. What are some ways to avoid late projects?

• Staffing – BMC Software avoided late project delivery by aggressively staffing when they started the project.
• Cross functional teams – This keeps the project delivery from being derailed when something happens to a “key” developer.
• Incremental and iterative development – Customers rarely need all the new functionality at once. Delivering the highest value functions sooner relieves the pressure for a “big bang” delivery. The customer can decide to stop the project early if/when their needs get met.
• Fast feedback – This naturally flows from incremental and iterative development. Every two to four weeks the customer provides information on how well the development is doing at meeting the customer’s needs.
• Continuous Improvement – At the end of each delivery cycle, set aside time to learn from the cycle’s activities and events. What went well? What could be improved? Select something from the “What could be improved” list and work on it the next delivery cycle. Be sure to ask at the end, “Did we implement the improvement?” Some things take more than a single delivery cycle to get right.

1. The AYE Conference schedule contains several sessions involving systems thinking. Two sessions, Experience the Diagram of Effects and General Systems Thinking obviously involve systems thinking. Several other sessions will include systems thinking principles, without necessarily naming them as such.

You can receive emails about the conference by signing up here

2. I recently received an email related to Force Ranking. It said … “I am currently working at [a company] for few yrs, and yes, I am suffering in the “forced ranking” system. After 1.5 yr from your article which talked about forced ranking, today is 2007- 5 – 27, our team is breaking down into a mess, ppl started to protect themselves, fighting each other rather than helping each other; poor management team : political competitions happen anytime anyday, and kissing boss’s ass will get a better position; The [company] stock price drops, always hear the rumour of [larger company in Redmond] will buy [our company]. Our so-called “innovations process” never reached the outstanding result as [a competing company], it is just a way for ppl to getting a better KPI (annual review), to avoid falling into the bottom 10%. Let’s see how/what [this company] will turn to be…u bet?

I have a pretty good idea how this is going to turn out. Maybe not soon, but if the system forces don’t change, it’s only a matter of time.

3. In Multi-use Models I mention how the feedback control loop model can be used for personal problem solving. I used the example of losing weight. It works! I’ve lost 30 pounds since I wrote the blog entry. Another 4.5 kilos and I’ll be at my goal.

Models are like kitchen utensils. You need a variety of them, and you should know when and how to use them. They should be useful for more than a single task. I recently started exploring the first explicit model I learned years ago.

The Cybernetic Model

One of my more interesting college classes was feedback control. The class was based on differential equations, Laplace transforms, and a single model that looked like this:

This model is the basis for most of the process control in the world. Basically the setpoint getscompared to the actual value. The error value goes to a controller, that then takes a corrective action. If the temperature is to hot, the corrective action might be to reduce the heat in the temperature jacket. After a while, things cool down. All processes have a time lag between the corrective action and when the change arrives at the output. I “borrowed” the “delay symbol” from Causal Loop Diagramming to show this. If it gets too cool, the controller will change the action and add more heat.

I didn’t realize at the time how powerful and versatile this diagram is.

Personal Problem Solving

With just a few word changes, the model can be used to describe how people can solve their problems.

A problem exists when a difference exists between what we want, and what we have. We can solve the problem by changing our actions, and seeing if the world at large responds with results that are closer to what we desire.

I’m trying to lose a few pounds. I can change what I eat (calories, fat, carbs, pick your favorite fad diet). I can change how often I exercise. If I continue with these changes, eventually I should lose the weight.

Project Management

Change a couple of more words, and now we have a project management tool.

In this drawing, I’ve used a dash line connection between the manager (in this case synonymous with leader) and the team. I made this distinction since managers don’t have a direct linkage to the team. Managers can ask, cajole, threaten, and perhaps fire team members who don’t perform the tasks they’ve been asked to do. But the team member always has a choice.

Loops All the Way Down

It is possible to nest the cybernetic model. Consider the Scrum sprint cycle. The generic sprint cycle looks like:

The outside loop is the sprint cycle (usually 30 days or less).  Every sprint the product owner sees new product functionality. This allows him/her to compare the current product state with the target. A subset of the remaining stories gets selected by the team and becomes the current spring backlog. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal by completing the stories in the sprint backlog.

I’ve left some feedback loops out of this drawing:

1. The team assigns stories relative weight/size/difficulties to the stories.
2. The sprint planning meeting occurs in the arrow labeled “Priority Stories”. The team uses the information from its previous sprints to determine how much they can accomplish in the next sprint.
3. The many interactions that happen each day as the team works towards the sprint goals.

I chose not to include them since I’m working from an overview position. If these areas presented difficulty for the system, I’d focus on them and leave the other loops off.

A Rose is a Rose

In Quality Software Management: Systems Thinking Jerry Weinberg presents the model in a slightly different picture (page 62).

Jerry says, “The feedback model of a software development system requires feedback of information about the system’s performance, plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 from Patterns 0, 1, and 2. It is also used by Patterns 4 and 5.”

This presentation highlights two systems aspects:

1. Randomness – All systems interact with their environment. Changes in the environment create changes in the system whether the changes are planned or not.
2. The software development system creates “other outputs” that the controller can use to improve the overall system performance.

A Good Place to Start

Like kitchen utensils, you need many different models. Here’s a list of models I’m aware I’m using.

I didn’t consciously start the list with the Cybernetic Model, but that’s where it belongs. Any time I start with a difference between what I want and have, I’ve already started using the Cybernetic Model.

Based on the domain, I may choose to use other models to help resolve the difference. If I’m involved in a conversation that doesn’t make sense, I may use the Satir Interaction model to find out why the conversation doesn’t make sense. If a co-worker’s actions don’t make sense, maybe I’ll use MBTI types to shed light on the problem.

But it all starts with the multi-use, handy-dandy, it’s everywhere, Cybernetic Model.

But as I think about what I understand involving force ranking, the logic behind it makes some sense. If I remove the lower performers (by some criteria) from my team, the overall average team performance (of that criteria) goes up. [Let me know if you'd like to see the math behind this thought.]

Here’s my idea of what a DoE looks like for force ranking

Force Ranking Dyanmics

Force ranking creates competition between individuals. As competition increases, more effort will be put into increasing (at least the appearance of) individual performance. As individual performance increases, it appears that force ranking is working, and force ranking gets used more. When this goes on long enough, the people who excelled in being force ranked get promoted and force ranking becomes institutionalized. After all, it worked for them.

But after a while, the secondary loop starts to apply pressure to the system. The competition between individuals reduces the team’s performance. This happens since time and energy spent “improving one’s self” comes at the expense of time and energy working toward the team’s goals. It probably creates conflict and tension between the team members, and quite possibly internally in the team members (not everyone enjoys competition). Since the overall team performance has gone down, we need to do more force ranking to get the performance up to where it used to be, there by invoking _Weinberg’s First Law of Bad Management_ If what you’re doing isn’t working, doing more of it won’t help.

But It Appears to Work!

For a while anyway. This happens because people will sacrifice for some period of time. This creates the delay before the secondary “team loop” starts to function. During this initial period of “working” observers notice the shiny new management technique and proceed to implement it. However …

Why does it fail?

Force ranking fails to consider (at least) three principle systems concepts: emergence, cause-effect and optimization.

It’s that old-timey synergy thing: “The whole is greater than the sum of the parts.”

Cause-effect comes into play by separating the effect (poor team performance) from the cause (force ranking) in time. When management notices that team productivity has declined, force ranking will be institutionalized, and the primary thought will be “find the low performers and move them out.” It will take a catastrophic calamity before anyone will stop to consider that force ranking may have caused the problem.

Force ranking optimizes the organization at the individual level. As each individual optimizes their outcome, the larger systems (teams, departments, and organization) will be sub-optimized due to the conflicting goals between individuals. If the original reason to force rank is to improve performance, then in the long run, force ranking is dysfunctional as it returns less value to the client than the original state.

Another way to blame?

Without actually saying it, force ranking seems to be a blaming activity. People are identified as “not as good” and removed from the team. Here’s a DoE that shows blaming’s effects.

The Blame Game

What did I miss? Send me an email.

Why I Can Agree

Jerry’s example of here-now-us related to a client’s problem. Through the magic word “snow”, one person transported themselves to “there-then-them”, and applied the emotions and feelings from the “then-there-them” to the current “here-now-us”.

Willem’s example of “there-then-them” shows that reflecting on “there-then-them” (“me“ in his example) provides insight that may allow him to change his behavior (if he wants to).

Neither example precludes or excludes the other when thinking about “there-then-them” and “here-now-us”. So what good is it?

A Useful Tool

The “there-then-them” / “here-now-us” tool can be used tactically or strategically. Tactically it helps problem solvers keep track of WHICH problem they’re trying to solve. When the solving the current problem suddenly vectors off in a surprising direction, be suspicious that someone went “there-then-them”.

Strategically, “there-then-them” can be used to reflect on how we got here, and what we might want to change.

Do you have useful tool for systems thinking? Drop me a note.

The Root Problem

I would say that the root of the problem or “cause” was the pure and simple fact, that a poor decision was made to “band aid” a poorly designed system. If the correct decision was made in February of 2004, to replace the poorly designed, inherited system, it’s unfortunate to say this but, we would not have had the opportunity to meet, as I would have had a turn key system installed. I have proven to management here, … that it was a poor decision to band aid, rather than replace. The unfortunate problem now is that the system is running just good enough that it is much harder to justify a new system. You could argue that “just good enough” means the problem is fixed, but I have showed, using our Quality data, that even though we improved from a 33 %! defect rate down to a 3% average defect rate. That 3% adds up to approx 160K per year. There is more to the equation than just coding issues, you have hardware failures that add to the defect rate, which would be eliminated with a properly designed centralized control system.

One thing to remember that it was one guy who made the decision, I.E. it was not a group decision. In fact I almost had the go ahead to do the upgrade until our friend jumped in and decided to “save” the company money. Our friend moved to other places after the damage was done about 2 months after the decision was made to band aid. Pretty convenient eh? Not to mention the multitude of other management changes that have taken place over the past 2 years, in effort to try to make RTM work. Over all things are better now than they were 2 years ago.

The Sky is Falling

I agree with George. For the last two years we’ve been adding features (complexity) and size (lines of code) to a system that should be replaced. And now he’s adding 1/3 more functionality. The logical conclusion seems that sometime, possibly in the not to distant future, the system will implode from its heritage.

Three Ways to Solve a Problem

The original quality problem had three possible solutions:

1. Solved: This solution provides the maximum possible benefit. George would have a new system properly designed to handle the process.
2. Resolved: This is the “good enough” solution. The results are satisfactory, but not maximized. George’s current reality.
3. Dissolved: By changing requirements (such as quality parameters), the problem could just “go away.” Not going to happen for George.

With my help, George now has a system that satisfices. His new problem is getting management on board to realize a change should be made before it’s too late.

Systems have several essential characteristics:

1. A system’s parts must all be present for the system to carry out its purpose optimally. If you can take components away from something without affecting its functioning and its relationships, then you have just a collection, not a system. A pile of quarters on the table would be a collection. The company for which you work is a system.
2. A system’s parts must be arranged in a specific way for the system to carry out its purpose. If the components of a collection can be combined in any random order, then they do not make up a system.
3. Systems have specific purposes within larger systems. To paraphrase, “It’s systems all the way down.” Your company, your department, your team, you, your various physical systems, and smaller the systems get until you reach the sub-cellular level.
4. Systems maintain their stability through fluctuations and adjustments. Systems achieve this stability through the interactions, feedback and adjustments that continually circulate among the system parts, and between the system and its environment. If a systems doesn’t achieve stability, it generally doesn’t last long enough to get noticed.
5. Systems have feedback. Feedback is the transmission and return of information. The most important feature of feedback is that it provides the catalyst for a change in behavior.

A system has feedback within itself. But because all systems are part of larger systems, a system also has feedback between itself and external systems.

Finally, feedback is not necessarily transmitted and returned through the same system component or even through the same system.

What would you add or change?