© 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.

• 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.

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 …

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.

• diminishing returns. The more improved a process becomes the less room for improvement exists. Eventually the process will be as good as possible.
• over adaptation. The development process becomes highly adapted to the existing system leading to problems when the environment shifts.

I say if you want to improve your process, improve your people. It’s impossible to provide specific advice but try for improvements in three basic areas:

1. What they know. Use seasoned developers to help mentor newer developers. Both learn in the process.
2. What they don’t know. Software development extends beyond the code editor and compiler. Requirements, scheduling, and testing all play a part in the process.
3. How they work with others. With very few exceptions, software development requires a team effort and interfacing with other people in and out of the organization. More effective interactions lead to better software.

The Second Law of Consulting states:
“No matter how it looks at first, it’s always a people problem.”

Inverted the Second Law becomes:
“No matter how it looks at first, people are always the solution.”

So if you want your software better, faster, cheaper, improve your process by improving your people.

The hardware & integration project to produce that client was much-delayed, under pressure, and more than a little out of control. I didn’t need a PM. They already had more “help” doing that the normal way than anyone could stand. What I needed was a kind of “un-PM” to coordinate and focus what the execution team was doing, mostly by filtering out the noise from above and across, and maybe injecting somber reality checks into what we said was happening. I needed someone with perspective on the technologies & manufacturing, a grasp of project execution, and a delicate touch with people. I needed someone honest, fearless and gentle about both without losing the need for real data, for he and I to respond to. Taking the culture and history into account, I needed some magic in “just in time” coaching and OD-on-the-sly, to help these people grow into the jobs they were supposed to be doing, without making too big a deal about it. I needed to help these people loosen up while staying focused on the job at hand.

Don has the gift of retaining the child-like quality of enjoying what he does despite decades’ experience with technology development, and a butt-load of training in OD and human systems. He’s serious where need be, but never solemn. With his other skills and gifts, he was perfect.

Don slid-in, and within a week we were tracking to reality of what was done and he’d cleared the underbrush so we could see what remained all without making anyone’s head explode. The product went beta the day I had predicted a couple months earlier, received all certifications and approvals, and worked as advertised. One of the crustier software engineers said: “It’s the best hardware we’ve ever shipped.”

So, what did Don contribute, beyond his background in hardware development, software development, and projects?

• Gentle leadership.
• Sense of fun.
• Just enough Command & Control which was mostly less in detail than there had been, and more in direction
• As a bonus, Don was able sometimes to explain to the more interested members of the staff what I was doing with the organization and how. That conversation is a complicated one to have when you are the boss, as I was.
• And Don engaged in some just in time coaching and almost mini-workshops on tools and techniques of working well together, general systems in particular.

Don and I have since threatened to offer a workshop on general systems applied to development work. I’ve been the slacker on this. But, if we pull it off one day, it should be a riot. I’d like to do that because the one regret I have about working with Don at Padcom is that I didn’t get to spend as much time with him as I’d have liked to.

Jim Bullock – February, 2007, Seattle Washington

I talked with a friend today who regaled me with the problems they’re currently experiencing at work … teams being assembled, and then reassembled, departmental barriers, resistance and unwillingness to collaborate. It sure looked like they had a lot of problems at the team level.

Then I heard about the management. Words like control freak, micro-manager, feels comfortable yelling at managers in front their peers, doesn’t recognize people.

I don’t know enough about the situation yet, but it looks to me like the leaders (who have the gold) have defined the problem to be the team’s problem. That way they don’t consider what they may be doing to contribute to the problem.