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!

• Coaching/Facilitation
• Consulting/Giving advice
• Mentoring/Guiding
• Training/Teaching

Some Examples

I once worked with a product owner who’s team hadn’t quite jelled. Four days before the sprint end it was apparent the sprint goal would be missed and he asked me if he should abort the sprint and start a new sprint. We talked about about the options and I asked, “What would you like to have happen for the team?” He stated he wanted the team to learn from the experience. Since we both wanted the team to learn I asked the follow on question, “Do you think they will learn more by aborting the sprint, or facing the unfinished stories at the sprint end?” We continued the conversation until the product owner decided to let the sprint continue and see how the team handled the retrospective. (Coaching/Facilitation)

“What’s the best way to keep track of impediments I’ve resolved?” asked a new ScrumMaster. “Hmmm. And why would you want to do that?” “Well” he continued, “I’d like to make sure the team knows I’ve completed the effort, and look to see if there are patterns in the impediments that get mentioned.” We discussed several different possibilities and then I asked, “What is the simplest thing that could work?” “As a PMP, I’m used to keeping track of risk summaries in a spreadsheet. I could use a spreadsheet with four columns showing the impediment, when it was mentioned, when it was resolved, and how it was resolved.” “Seems reasonable to me. Why not start there, and see how it works?” (Consulting/Giving advice)

“We can develop faster if we split the QA functions into a different sprint.” the team’s alpha developer asserted. “Is that so?” I asked. He assured me it was, so we, the ScrumMaster, he and I headed into a room where we started filling the white board with sprints, code and defects. After an hour or so making sure I understood his ideas, and then extending his example, always asking “And what happens to the defects we find here?” I finally asked, “And when can you declare the code is ‘done, done, done’?” The conversation shifted to Chinese and 30 minutes later I was informed “We’ll rotate different developers to help the QA people write their automated tests.” (Mentoring/Guiding)

“Tell me more about how you pair program.” I asked. “The pair works on the same task. One writes the test and the other writes the code. We’re doing TDD.” came back to me. “And they do this from a single keyboard?” “Oh no, each developer has his own machine where he works.” I heard. This may be some sort of co-development, but it doesn’t fit with my experience of TDD (write the failing test, then the code to make it pass) or of pair programming (two developers, one keyboard). Thus started a conversation about how teams use TDD and XP to create high quality code. (Training/Teaching)

Up and Down the Org Chart

Agile coaches work at many levels. They work with individuals, teams, and others in the software development and business functions. Some coaches tend towards technical skills. Others focus more on organizational change issues and collaborative skills. I’ve learned much about being effective at these different levels and skills over the years at the AYE Conference.

Why Would You Want an Agile Coach?

My colleague Esther Derby listed Five Reasons to Hire a Coach for Agile Teams. You should go read it. I’ll wait …

I’d like to offer three reasons in addition to Esther’s.

1. Experience – Agile coaches have been through the change process before. If you don’t think moving to an agile development method involves change don’t worry, you will know it does soon enough. The Satir Change Model graphic at the bottom of Change and Stable Systems shows how people react to change. Having someone who’s “Been there, done that” has a calming effect.
2. Energy – As Esther pointed out, you’ve got a ton of other stuff you need to be doing anyway. Having an experienced person who can coach, consult, mentor and teach reduces wear and tear on you. It also shows the team that management is serious about making the change work.
3. Enthusiasm – The agile coaches with whom I associate enjoy working with development teams and organizations that want to become more effective. We can’t imagine wanting to do anything else. To that end we’re always working on improving our skills becoming more effective helping you become more effective.

These three reasons, experience, energy and enthusiasm combine to reduce the amount of time it takes for your organization and teams to become more effective, there by increasing financial returns sooner. So with sufficient good coaching, you create a increase revenue stream and create continuous improvement, for just a one time payment.

Have other ideas on why to use an agile coach? Drop me an email.

And in the beginning

“The learning of a thousand languages begins with a single keystroke.” (with apologies to the original author)

So what happens when I decide to learn a new skill? What do I have to learn? What do I have to un-learn? The answers depend on several things:

1. How close is the new skill to my existing skill set? After F77 I picked up C. Some parts of C resembled F77: functions, subroutines, variable typing. Others were pretty novel: pointers, main(), casting. Unsurprising my first C program looked a lot like an F77 program with “;” at the end of each statement.
2. Why do I want to develop the skill? As time went by, I liked C more and more, and worked on improving my coding ability and style. I wanted to do more C and less F77, so I looked for opportunities to do C programming.
3. Where will I find the time to develop the skill? Skill proficiency follows a common path from novice to expert. Learning a new skill starts by following rules (like remembering to put a “;” at the end of each statement). With enough (successful) practice and learning, I can become competent, or perhaps an expert. The journey takes time. From where will it come?

In picture form it looks like

If I have a big change, I should expect to spend a lot of time and effort on mastering the new skill. The amount of change varies based on the remaining time/effort and how much time and effort I put into learning the new skill. After awhile, my skill level should go up, and the remaining material and time/effort should go down.

As George Dinwiddie mentioned as we discussed this dynamic, it never really ends. Even experts, maybe especially experts, realize they’re still learning.

Changing Quicker

Using this picture we can look for intervention points. What can we do, add, subtract that will get me to “proficient” if not “expert” in the shortest time possible? After all, in business “time is money.”

Smaller changes should require less time. Going from Assembler to C# requires serious neural re-wiring. Java to C# not so much. Yes, there are differences between C# and Java, but it’s a smaller jump than from Assembler. Smaller changes generally don’t result in large paybacks.

Increasing the amount of time/effort will shorten the time from beginning to “proficient” as the “amount of change” will accumulate faster.

We can add training to the change effort. The training ranges from providing books/reference materials to the Brown Bag pattern to sending people to classes.

Another option would be adding a coach. XP coaches work with team members in developing skills beyond the basic language. Skills such as TDD, refactoring, maximizing the amount of code not written.

We now have a system that looks like this:

What Should You Do?

When planning a change embrace the fact that developing useful skill level takes time. If the change involves more than a single person, then everyone will progress at a different pace.

Well spent money can aid when implementing changes. Distribute books to team members. One organization I worked with offered each developer copies of Testing Extreme Programming and Agile Principles, Patterns, and Practices in C#. Send people to training and conferences.

If you’re dealing with process changes hire one or more coaches to assist the developers with the transition.

Do you know about smokejumpers? They’re brave, self-sufficient firefighters who parachute into remote areas wearing eighty pounds of gear and ready to fight a forest fire. If the jump goes well, they land safely. After extinguishing the fire, they may have a ten-mile hike out. It’s not a job for the faint of heart, slow of mind, or weak of back.

Have you considered that you may be a smokejumper? Think about it: Many of you join software projects midstream because sometimes a project needs additional contributors—some add brains, others brawn. Sometimes mentors are needed to improve project performance. Sometimes management needs an outsider’s view of the project status.

No matter why you join a project after it begins, you will encounter challenges. To be successful you must:

• Determine your role
• Build trust
• Learn the territory
• Gather information
• Do your job
• Declare victory

Determine Your Role

“If you don’t know where you are going, you’ll probably end up somewhere else.”
—Laurence J. Peter

Smokejumpers work on well-defined teams. Everyone has a job to do and knows how to do it. Before jumping into a project you should determine your role. Ask:

• What specifically is my sponsor asking me to do?
• How can I demonstrate to my sponsor that I have been successful?
• What will my relationship be with others on the project?

Knowing what my sponsor wants keeps me focused. Difficulties arise when the sponsor has trouble explaining the problem. He knows the project is late and he wants better quality, but he can’t say exactly why the project is late or what’s creating sub-standard quality. Generally, the greater the pain (lateness, poor quality), the less articulate about the problem the sponsor becomes. When this happens, I like to use the SMART acronym Johanna Rothman describes in “Release Criteria: Is This Software Done?” (STQE magazine, March/April, 2002). SMART reminds me to get a problem definition that is: specific, measurable, attainable, relevant, and trackable.

Next, I need to know what “done” means. Knowing how I’m going to demonstrate “done” gives me information on what to track so I can provide my sponsor the information needed to prove the fire is out. A good question to ask is “What will you see, hear, and feel when this problem is solved?”

I often use a simple reporting format when I check in with the people for whom I’m working. I describe what we’ve done since our last discussion, what we’re currently working on, and any barriers to progress we’re encountering.

Last, but not least, I need to know who I will be working with and in what capacity. Based on what I’m being asked to do (brawn, brains, mentor, or project review), I’m going to relate to the team in different ways. I may be a coworker, a coach, or an investigator. Knowing which role I’ll be in guides me as I work on getting a demonstrable “done.”

Currently, I’m working with a client whose staff has been trying to solve a problem for a month. In our kick-off meeting, we established that my job was to get the project “done,” and they don’t care how. On this project, “done” means all the applications have been switched to the new server and tested and the old server decommissioned. I’m going to function primarily in the brains/brawn role, as a coworker helping solve the problem. Along the way, however, I’m going to be asked, “Why couldn’t the team solve the problem?” which will put me in an investigator/reporter role.

Build Trust

“The first thing to build is trust.”
—Brad Appleton

Smokejumpers work in integrated teams to put out small fires before they spread or to provide additional manpower on larger blazes. As a project smokejumper, it’s likely you’ll be joining a pre-existing team. So when your boots hit the ground and your chute is secure, you’ll need to hook up with the team. Your success in working with this team will depend on how well you understand them and how much they trust you.

Building trust is a relatively straightforward activity. If you say you’re going to do something, do it. If you say you’re not going to do something, don’t. The team—and its management—will be looking for discrepancies between your words and your actions. Building trust is an action-based activity. When I hear “Trust me!” from someone I do not know well, that is a red flag that throws me into the “Put up or shut up” mode. So make commitments and meet them.

Keeping activities, information, and decisions visible helps build trust. It’s not always possible to achieve immediate success (however minor it may be). Keeping things in the open helps allay fears, enhances communication, and enables better decisions. On one of my jumps, a team member heard me discussing a spreadsheet I was using to keep track of assets, current status, and needed changes. He asked for a copy of the spreadsheet and later returned it to me with the names and phone numbers of the key people I should coordinate with at each plant. By sharing the information I had, I received more.

Asking questions opens the door for team members to share what they know about the fire. Listening to and understanding their answers creates rapport and builds trust. This also helps you learn the territory and gather information.

Learn the Territory

“You gotta know the territory.”
—Meredith Willson in “Rock Island” from The Music Man

“I know the territory.”
—Meat Loaf in “I’d Do Anything For Love” from Bat Out of Hell II

Smokejumpers work in an ever-changing environment where understanding the territory can be the difference between putting out the fire and not making it out alive. Their territory includes fuel types, wind direction, and the topography where they’re working. Changes in any of these can change the possible outcomes quickly.

Project smokejumpers also work in highly dynamic environments. Personality differences fuel the project flames. Some team members may be more equal than others. Who’s really in charge? Even though someone can’t help me, can he hurt my ability to succeed? Changes in any of these can quickly change the possible outcomes.

In all my years of jumping, I never have landed in a situation that lacked energy. Most situations follow the pattern of a jump I did a couple of years ago. For reasons no one could determine, a stable, proven process suddenly started generating a 25 percent defect rate. The Big Boss flew in from the home office to handle the situation personally. On Saturday, I got the call to jump. When I arrived Monday morning, I surveyed the situation, listened to the management screams and the worker apologies and decided it was a good time to be calm. I took a deep breath and started asking questions.

In her book Communication Gaps and How to Close Them, Naomi Karten lists my three favorite questions:

1. How did you happen to come here?
2. What do you expect will happen here?
3. What do you hope to accomplish here?

She also says, “Notice that the first question elicits information about events from the past; the second, the present; and the third, the future. All three questions provide a starting point to help you determine what’s important to the person or group with whom you’re trying to communicate.” These questions represent starting points for learning the territory.

The responses to the questions indicate how safe the person feels. Short, simple answers may be a tip that the person isn’t feeling safe. Perhaps there’s a blaming corporate culture and whoever’s holding the blame when the music stops gets fired. It could be personality conflict on the team. Unresolved conflicting management agendas can cause a “CYA” environment. If the environment isn’t safe for the employees, it’s not going to be safe for the smokejumper, either.

The key to success and survival hinges on the smokejumper’s ability to ferret out information about why the person doesn’t feel safe. If I haven’t created a trusting relationship, I won’t get the information I need to learn the territory. I talk to as many people as possible, which allows me to draw a more accurate map to help me navigate the territory.

Do the answers’ content and delivery style agree with each other? I remember one project manager yelling at me about how well he had done on a previous project and how this project wouldn’t fail. I wondered why he chose to do this project differently, but decided to keep my mouth shut. He was partially correct. The project didn’t fail, but he and his company (the management team) were terminated six weeks later. It took us another year of development to complete the estimated twelve week project.

Gather  Information

“As a general rule, the most successful man in life is the man who has the best information.”
—Benjamin Disraeli

Smokejumpers receive information about the fire before they board the airplane. How big is the fire? What are the weather conditions? Which way is the fire headed? Are there obstacles to overcome? Where are the safe zones? As soon as they land, their first action is to verify the information and determine if anything has changed. Project smokejumpers start gathering information during the first conversation with the client. What’s the nature of the problem? How long has it been going on? What already has been tried to solve the problem? You need to gather information about the technical fire you’ve been asked to put out.

I once jumped to solve a “three systems quit working” problem. After listening to the problem description, I thought about the symptoms and several possible cause/effect scenarios came to mind based on other successful jumps. I continued to ask questions, and one by one ruled out the possibilities. When I jumped, all I knew for sure was a problem existed. (For the curious, the software quit working because someone created separate IP subnets, and the computers couldn’t talk to each other because the inexpensive routers couldn’t bridge the subnets.)

Project smokejumpers compare this information against their past experiences. What appears to be the same? Is something new or novel? This provides the project smokejumper with an initial problem assessment. This is both good and bad.

The difficulty with this initial assessment comes when it leads us to ignore new data. Since we have an idea of what the problem is, we may believe we have the answer. As Lee Copeland points out in “Believing Is Seeing” (Better Software magazine, December 2006), the Bruner-Postman experiment shows that our experience can blind us to reality. Keeping an open mind and being willing to change conclusions go against our own biology, but both are necessary when you’re jumping into complex situations.

Try to find both positive support and negative indicators for the problem you’re trying to solve. In my career as an emergency medical technician, I was taught to evaluate data and revise my understanding using the following checklist:

• I expect to see something, and I do.
• I don’t expect to see something, and I don’t.
• I expect to see something, but I don’t.
• I don’t expect to see something, but I do.

We can use this new data to modify our problem assessment. This forces a rethink and possible restructuring of our problem assessment. It takes time but opens the door to a better assessment and solution. The other choice is to ignore the information or modify it to fit our problem assessment. This doesn’t require rethinking and restructuring our assessment. It also opens the door for high-impact learning when the information we ignore comes back to burn us.

The technical problem could be something as simple as finding that the computers are on different subnets and thus cannot communicate. Maybe it’s helping the team come to grips with the “process du jour.” Perhaps the team’s engineering practices need modification to achieve the project goals. Whatever the technical problem may be, expect that it will be difficult to solve. If the problem had been easy, the team most likely would have solved it already.

Do Your Job

“For every complex problem, there is an answer that is clear, simple, and wrong.”
—Attributed to H.L. Mencken

Smokejumpers use different tactics to extinguish fires. If the fire is small enough, they may directly confront it. For other fires, they may use an indirect approach of control lines and backfires to deprive the main fire of fuel. When the fire really gets going, they may have to wait for something to change—the type of fuel, the weather, the topography—before they resume fighting the fire.

As a project smokejumper, how you attack the problem is affected by your role in the project, your ability to build trust, your understanding of the territory, and the information you’ve gathered together with the problem’s complexity.

A brain/brawn role and a straightforward problem generally lead to direct action. This is how I dealt with a “software quit working” jump. I sat down at the computer and started checking settings, properties, and configurations. When I discovered two network cards, I started investigating more, and voilà! There were the two non-mappable subnets.

Mentoring or complex problems often require indirect approaches. I once spent three months helping a hardware team as it worked to get a hardened mobile router into beta production. Since management complained about not knowing where the team stood, I created a  burn-up chart in the engineering space so everyone could see what remained to be accomplished and when we anticipated that it would be completed. The semiweekly status meetings asked the basic Scrum questions: What have you done since our last meeting? What are you going to work on? What problems are you having? I made sure I had the necessary equipment, so if there was a question, I could go in and work with the team. We made the target date with a few days to spare.

Each style of doing things has natural consequences. If I decide to take control and work directly, I’ll miss an opportunity to let others learn through experience. If I let others learn through experience, what happens to putting the fire out? I like to use the following questions to help me understand the implications of my (mentally proposed) actions:

• What will happen if I do?
• What will happen if I don’t?
• What won’t happen if I do?
• What won’t happen if I don’t?

The process of understanding your role through doing your job goes on the entire time you’re fighting the fire. It’s a continuous refinement process as the project smokejumper learns more about the technical problem, the team, and the interactions between them. And it’s not a linear sequence. Other than starting with determining your role, the rest of the activities happen randomly, simultaneously, and continuously.

Declare Victory

“The Lone Ranger Fantasy: When the clients don’t show their appreciation, pretend that they’re stunned by your performance—but never forget that it’s your fantasy, not theirs.”
—Gerald M. Weinberg

After they ensure the fire is out, smokejumpers head back to base, clean up, and repack their gear, getting ready for the next jump.

Prior to heading out, project smokejumpers need agreement from their sponsors that the fire is out. This task combines defining a specific goal at the jump’s start and keeping progress visible. If you don’t know what you’re shooting for and when you need to hit it, you’re probably going to miss the target. Hitting the target gets you praised and paid.

Declaring victory creates the opening to review your contributions to the project. Project smokejumpers often make technical contributions on a project. These are generally obvious, and most people would agree to them. Often more important are the less-obvious personal contributions. No one but the smokejumper may ever know the many little bumps, nudges, and guidance provided during the jump.

I’ve just finished working with a sponsor who a week ago said, “Again, today, the reports did not get sent out. I guess all of our work was for nothing.” I reminded him that the problem involved two different systems, we had only corrected one, and that things would get better when we solved the problem with the second system. Today I heard the happiness in his voice as the second system came on line.

The Smokejumper’s Life

“You live and learn. Or you don’t live long.”
—Robert Heinlein

The smokejumper’s life consists of:

1. Qualify for smokejumping
2. Train
3. Go to the fire
4. Put out the fire
5. Go to 2

Over years of jumping, the training will change as the jumper becomes more practiced at current skills and learns new skills. Smokejumpers use all their skills, all the time. Being able to call on their training when they need to can mean the difference between an extinguished fire and an unhappy outcome.

Project smokejumpers follow the same pattern. Somehow, somewhere, you start solving problems, and then someone asks you to jump in to help them.

Project smokejumpers need to train continuously. Your technical skills may get you started, but it’s your people skills that help you solve the problem and keep it solved. In addition to reading magazines and books, I recommend attending experiential conferences or training courses where you’ll be able to learn new skills and practice them in a supportive environment.

Jumping isn’t for everyone. Over the years I’ve missed birthdays and anniversaries. I once left a weeklong vacation after only two days to make a jump. Fortunately, my family loves me. It occasionally gets tense, so a sense of humor works to my advantage. Being an adrenalin junkie helps too. And it’s all worth it when a client says:

“You know, Don, a couple years ago I watched you ‘join a team’ and help them work together better, when your charter was actually to get something shipped. You weren’t there to ‘fix them.’ But, you ended up helping that team and another team be better together.”

That still gives me goose bumps.

This article was originally published in Better Software, September 2007

Near the Blue Ridge Mountains in North Carolina, not far from where you think it should be, there really is a town called Mayberry.

Although the main highway bypassed the town years ago, the namesake for the popular 1960s television series is still a bustling community, and a fair amount of traffic enters Mayberry’s downtown from the north on the US Highway 52 business spur every morning. In town for a week of consulting work, we were able to observe the recent road construction along that route and watched a trio of local citizens demonstrate their own unique management styles. Let’s take a look at how these characters traffic management closely parallels common styles of software project management.

When road work just north of town closed Business 52, all the traffic entering town from the north had to take the 52 bypass around to the west side of town and enter the downtown on Key Street. Unfortunately, this meant traffic would have to make a left turn onto Key Street, crossing fairly busy east-west traffic (see Figure 1).

Figure 1

The town council feared that during the morning rush the traffic waiting to make the left turn onto Key Street would back up on the southbound off-ramp all the way to Highway 52 itself. This could cause a serious accident, since Highway 52 has a 65 mph speed limit. So the council decided to station one police officer and one or two rescue squad volunteers at the intersection to make sure that traffic on the ramp did not back up.

Three Approaches to Managing

Being a take-charge guy, the officer on duty (we’ll call him Barney) arrived at the scene Monday and quickly sized up the situation. He decided that what was needed was a traffic light at the intersection of Key Street and the ramps. Since it would take the county months to approve a light, he decided to operate as a “human traffic light,” directing traffic manually. Each direction got its turn: westbound Key (including left turns onto the southbound ramp), then eastbound Key (including right turns onto the southbound ramp), then the off-ramp (which could turn either way onto Key). Barney’s plan didn’t actually work all that well. Traffic stalled in both directions on Key Street. And there were a couple of close calls on the ramp; traffic backed up almost onto Highway 52 once when Barney let a few cars turn left onto Key Street. By the end of rush hour he was hot, tired, and a little discouraged, and he had written a fistful of citations to drivers for making unmentionably rude gestures at a law enforcement officer.

On Tuesday, one of the rescue squad volunteers (a helpful local woman known as Aunt Bea) said she knew how to take care of the situation. She figured that traffic could probably take care of itself as long as drivers didn’t have to cross each other’s paths. So she let traffic go both ways on Key Street, and let people make right turns onto and off the ramps. When somebody had to turn left, she’d stop the other lanes and let them go. Aunt Bee’s approach worked better than Barney’s (at least nobody made rude gestures at her), but there was still a lot more congestion than we expected, and by the end of rush hour Bee was glowing profusely.

On Wednesday Sheriff Andy showed up, bringing a lawn chair and a thermos of lemonade. He set up the lawn chair on a shady spot from which he could see the intersection and a fair way down the off-ramp, and sat down to sip lemonade. When traffic started to back up on the ramp, he got up, stopped Key Street traffic, and let the ramp empty; then he went back to his lemonade. Other than that, Andy pretty much didn’t seem to do anything. Despite his apparent inaction, the intersection just seemed to work. People were calm and relaxed, with the drivers making right turns creating breaks for others making left turns, and everything worked a lot like it did before anyone showed up to help—just a little better.

Putting on our consultant hats, we realized we’d just witnessed three distinct styles of management—Barney’s micromanagement, Aunt Bee’s motherly management, and Andy’s masterly management. Since these styles are also common in software project management. Let’s look at each of them in more detail, and see what we can apply to our own software projects.

A Question of Style

Each of our managers made different assumptions that shaped their style—in particular, assumptions about the people being managed, and about the role of the manager. These assumptions determined how they approached the critical activities of managing. In his book, Quality Software Management, Vol. 1: Systems Thinking, Jerry Weinberg highlights five critical activities:

1. understanding the problem to be solved,
2. planning the solution approach,
3. observing what the people being managed are actually doing,
4. using rules and process models to determine what to do next, and
5. taking action to guide the group toward its goal.

Together these activities form a feedback system that “steers” the project team. How they are executed (i.e., what the manager defines as the problem, how the manager plans, what observations get made, which rules get followed, and how the corrective actions get taken) makes all the difference—determining just where the team will go, how the team members will feel about the software project as a whole, and ultimately how satisfactory the results will be.

Micromanagement

Barney practiced micromanagement, which is based on the assumption that the manager has to see to it that everything gets done. Most micromanagers don’t deliberately meddle out of a need to be in control; they’re just operating under the assumption that if they don’t do it, it won’t get done. Micromanagers also tend to make the related assumption that those being managed will do what they’re told to do; no more, no less.

These assumptions describe machines better than they do humans. Indeed, when Barney said we needed “human traffic lights,” he was describing a situation in which both the manager and those being managed were more mechanical than human. Perhaps this is why so many good programmers become micromanagers when they get their first promotion—they’re just “programming” the “bio-robots” who work for them!

Using Weinberg’s model, we can see how Barney’s assumptions defined his view of the critical management activities:

1. The problem to be solved was to personally make sure everything was done in an orderly fashion.
2. The plan that followed was for Barney to pretty much do everything himself. He would personally direct the movements of each and every vehicle. This meant that the plan had to be simple enough that he could be in control of its execution at all times.
3. Even with the simple plan, Barney was far too busy directing traffic to observe much. Standing in the middle of the intersection, he wasn’t in the right position to see up the ramp when traffic began to back up onto Highway 52.
4. Even if he had made better observations, his manager-centered process model didn’t allow him to do much. The underlying assumption that he was personally responsible for each and every car going through the intersection meant that he couldn’t delegate much – he couldn’t count on the drivers to do anything other than what he told them to do.
5. Barney’s actions were pretty limited; because he had to control each vehicle, he couldn’t leave his spot in the middle of the intersection. In the end, he couldn’t do much beyond try harder at what he was already doing—waving his arms more frantically at the folks, in the hopes that they’d get through faster.

Because the manager must make (or at least approve of) all decisions, only one thing happens at a time and everything else lines up waiting for a turn. When simplicity, centralized information, and oversight are turned from virtues into vices, it creates a choke point that affects project planning and execution.

Simplicity Since the entire project plan must be under the control of the manager at all times, the plan must be simple enough that a single person can comprehend it in its entirety. This sets an upper bound on project complexity—if the problem to be solved is beyond this bound, the manager has to simplify it somehow (e.g., letting traffic go in only one direction at a time). This serialization of activities is a common simplification in micromanaged projects as well, and it wastes both effort and time. When serialization isn’t enough, the manager may start leaving “non-essential” activities out of the project plan. Micromanagers are notorious for over-simplifying, to the point where their software project plans may leave out something essential for a successful product launch.

Centralized information Since the manager is the only one who can make a decision, it’s critical that he get lots of quality information about how the project is doing. Unfortunately, the only observations allowed are those that the manager puts in the project plan—but that manager’s far too busy making each and every decision to actually observe much of anything. So in practice, micromanagers are often flying blind, making decisions on little or no actual information.

Oversight The need to get explicit approval for each action adds to the amount of time required to accomplish tasks. So micromanagement tends to be inefficient, with a lot of people waiting around for the manager to tell them what to do next. The manager-as-bottleneck is a key structural problem. The practice also leads to people problems, such as initiative squelching. The manager’s assumption implies that the people being managed have nothing to contribute beyond the functions defined for them by the manager. What if the workers want to do something other than follow the rules—because they see a better way or a problem with the plan? Forget it. The micromanager will not allow it to happen. This creates short tempers and long days for those who are micromanaged.

Most people don’t like this style of management. Some will respond with a sort of dead, mechanical compliance, waiting dutifully for their next set of instructions from the manager. Others may choose some form of subtle rebellion, such as “working to rule”—following the manager’s instructions to the letter, no more, no less, even when those instructions are clearly a recipe for failure. And others will rebel more openly, taking advantage of the manager’s continual distraction to get away with whatever they can. Alas, these responses to micromanagement tend to set up a positive feedback loop that reinforce the micromanager’s assumptions and leads to even more micromanagement. Micromanagers tend to be very busy people.

So, is micromanagement ever appropriate? Certainly, when the problem to be solved is small enough for one manager to truly comprehend the entire project plan, and the people doing the work are willing to follow each and every command of the manager. While this situation can occur now and then, it’s not very common in the software world.

A common cause of micromanagement is the newly promoted, technically competent manager rushing in to help a floundering employee or rescue a particular part of a software project. This creates a co-dependent dynamic where the manager becomes the rescuer, and the employee becomes helpless. This ensures that the next time there is a problem, the manager will step in again, and so on, until something happens to break the pattern.

While micromanaged projects can (and often do) result in successful product launches, it’s often more in spite of their management than because of it. There ought to be a more efficient and less aggravating way to handle the situation.

Motherly Management

Aunt Bea chose a kinder, gentler style that we call motherly managing, allowing the drivers to do some things for themselves, and helping them when she thought they needed help. But her underlying assumption was still pretty close to Barney’s: the people being managed might be able to do a few routine things without being told, but all significant decisions—especially when there was some form of contention or competition—were still firmly under her control.

If the micromanager views the people being managed as machines, the motherly manager sees them more like children, able to do a few routine things but still needing protection from anything potentially dangerous. Like the micromanager, the motherly manager is not necessarily malicious or desperately in need of control. Aunt Bea had no great need to have power over the drivers; she just knew that they couldn’t make major decisions without her help. She simply couldn’t visualize the situation where one person could be turning left into the gap created by another turning right, because she couldn’t see who was controlling the
relationship, and she knew that two drivers certainly couldn’t cooperate without somebody to coordinate them.

Aunt Bea’s motherly assumptions defined her view of the key management activities:

1. The problem to be solved was something like “take care of the people who have to cross other traffic.” Like Barney, she saw the problem in personal terms; it was her problem, not the drivers’ problem.
2. Because Aunt Bea saw the drivers as human beings who could do a few things for themselves, her plan was a bit less rigid than Barney’s. She could allow at least a few routine things to happen in parallel, but under exceptional conditions she would take full control of everything, which meant reverting to serial execution.
3. Aunt Bea’s more distributed plan required somewhat more sophisticated observations than Barney’s. She had to observe those situations in which her help was needed—in particular, left turns. Notice that she wasn’t observing whether people were having trouble making left turns; her underlying assumption said that a left turn signal was a request for help. Like Barney, she spent her time in the middle of the intersection, a point from which she couldn’t see up the
   ramp very well.
4. Because of her motherly assumption that the people being managed couldn’t handle any form of contention or conflict, Aunt Bea’s process models dictated that she must personally resolve these things. So her response to just about any out-of-the-ordinary condition was to stop traffic and go back to taking turns.
5. Like Barney, Aunt Bee was working from a very limited set of actions, in part restricted by her need to be in the position of control at the center of the intersection. If those actions didn’t work, about all she could do was more of what she was already doing.

Like micromanagement, motherly management can work when its underlying assumptions are true and the problem and solution aren’t too complex. Trouble is, most software development shops aren’t day care centers, and most development is non-routine and requires that a lot of conflicts be resolved. Interfaces, partitioning, decomposition, protocols—these are all “left turns” in the view of a motherly manager, who must personally make sure that everybody plays well together. This creates a structural problem similar to micromanagement. Similar, but also different. Since some work can take place independently under motherly management, the manager is less of a choke point than in the case of micromanagement.

But because the process is still highly manager-centric, the actual amount of work that can be done in parallel is often less than expected. We end up with a process that’s very nearly effective: almost parallel, relatively observant, and coming awfully close to giving workers independent responsibility:

Parallel (almost) Only pre-defined “routine” things can take place in parallel. As long as traffic went straight ahead or turned right, Aunt Bea’s plan seemed to work. But she couldn’t predict how many people would want to turn left. When lots of people started turning left, her plan fell apart. In the same way, the actual performance of a motherly-managed software project depends heavily on just how much of the development is really “routine” with no need for interactions or conflict resolution. If there are a lot more “exceptions” than expected, a lot of developers working in parallel according to the project plan may be sitting on their hands waiting for the manager to make a decision. This can make a project plan that was parallel in theory become serial in practice.

Myopic Motherly managers make more observations than micromanagers, but they still confine those observations to specific conditions noted in the project plan. If the conditions defined by the manager are in fact not the key exceptions that need to be managed, the motherly manager will be spending time and energy observing the wrong thing, while missing the observations that are really necessary for project success.

Nannying Motherly management can be less oppressive than micromanagement for the people being managed, because the “mother” allows her “children” to do a few things on their own. The individual developers can go ahead as long as they aren’t going against the flow or getting into conflicts. But at the first indication that something non-standard is going on, the whole process stops until the manager decides what to do. The manager must handle all the decisions that really matter—and this squelches the individual contribution to solving the overall problem just about as effectively as micromanagement. There is a great deal of variation here—a manager who views the employees as teenagers is less openly controlling than one who views them as toddlers. Still, most of the people who work in the software business have college degrees, and we wonder if we’re making the best use of their expensive educations when we manage them as though they were children.

If we are going to find a style that’s more efficient and effective than micro and motherly, we must start by changing our underlying assumptions. Barney sees the people being managed as machines to be programmed; Bea sees them as children to be helped. Now let’s see what happens when Andy views them as adult human beings.

Masterly Management

Andy took an approach that at first didn’t look like “management” at all. He just sat in his chair, sipping lemonade and watching traffic on the Highway 52 off-ramp. When it started backing up badly, he strolled out into the intersection, stopped traffic on Key Street, and let the off-ramp clear; then he went back to his lemonade. He seemed to be “working” a lot less than Barney or Aunt Bee, yet traffic flowed smoothly. We refer to Andy’s style as masterly management — because of our three traffic controllers, only he was truly the master of the situation.

The keys to Andy’s management style were his underlying assumptions: that drivers are adults, that most of the time they can take care of themselves, and that his role as a manager is to support these competent adults so they can do the real work of getting themselves safely through the intersection. This is vastly different from Barney’s and Aunt Bea’s assumption. Andy felt secure enough about his own competence and the drivers’ know-how that he could remove himself from the center of the job.

Because Andy did not place himself at the center of the management task, he could be much more flexible and effective at the key management activities:

1. Andy saw the problem to be solved as moving traffic efficiently and safely through the intersection. He also realized that most of the time this intersection didn’t need any help; people made turns here every day without any supervision. What made this a unique problem that might require some management intervention? The detour increased traffic on the Highway 52 off-ramp, and that might, on occasion, cause traffic on the ramp to back up onto the highway and cause a safety hazard. Notice the difference—while Barney and Aunt Bea defined the problem in terms of what they had to do, Andy defined the problem in terms of results, independent of who actually “did the work.” By doing this, Andy positioned himself to observe and “steer” the system that did work, rather than as the person doing the work.

2. With his understanding of the real problem to be solved, Andy was able to construct an effective plan for its solution. The drivers could be responsible for getting themselves through the intersection. He and his “management team” would monitor the off-ramp and make sure that it could be emptied when (and if) it backed up far enough to pose a safety hazard. While Barney might accuse Andy of not having much of a plan, the fact is that Andy’s simple-looking plan actually allowed some very complex things to happen. Because he didn’t attempt to control low-level actions by the drivers, Andy’s plan delegated management work to individual drivers. This allowed them to operate in parallel, which they did—drivers waiting to turn left off the ramp took advantage of gaps in traffic created by drivers turning right.

3. Now that he had both a problem statement and a plan, Andy could identify which observations he needed to make. To keep traffic from backing up onto Highway 52, he had to watch the ramp—not the intersection. So he positioned himself off to the side, where he could see the ramp. This is another critical difference in Andy’s style. Standing in the middle of the intersection, Barney and Aunt Bea were taking in a great deal of information—most of it irrelevant to solving the real problem. They weren’t in the right place to make the observations that really matter. Of course, Andy didn’t ignore what was happening in the intersection—but he didn’t make the intersection his primary focus.

4. Andy’s management style used two process models. First, if traffic’s backing up on the off-ramp, stop traffic on Key Street and allow the ramp to drain. Second, if something blocks the intersection, get it out of the way immediately. The rest of the time, Andy’s process model says “let the drivers take care of themselves.”

Both of these models are more subtle than they look. The first model allows Andy to do some fine-tuning as the morning progresses. How far up the ramp is “too far” for traffic to back up? At first he took a conservative approach, draining the ramp when it was backed up about halfway to the highway. Later, after observing how quickly Key Street traffic could be stopped to drain the ramp, he changed his definition of “too far” to something more like three-quarters of the way up the ramp. This meant even fewer interventions were needed, because often traffic would back up to the halfway point and then drain back down by itself.

The second model contains a flexible definition of just what triggers action. Andy’s looking for a symptom, which could have a variety of root causes. If something blocks the intersection (e.g., a driver too timid to turn left), Andy’s model will handle it.

5. Finally, Andy took a lot less “overt” action than either Barney or Aunt Bea. Most of the time it appeared that he was doing nothing at all. Yet, when action was required, he knew what action was appropriate and effective. But it would be wrong to say that Andy’s actions were simpler than Barney’s or Aunt Bea’s. In fact, his infrequent interventions required more skill. After all, Barney and Aunt Bea were already standing in the middle of the intersection, and had the drivers’ complete attention. Andy had to enter an intersection full of moving vehicles, get the drivers’ attention, temporarily interrupt their self-management, get the drivers to carry out his instructions, and finally re-establish the self-managing system. This is a task requiring some skill.

Like the other two styles we’ve discussed, masterly management works when its underlying assumptions are valid. In software development, where the people being managed are skilled, competent, educated adults, these assumptions are usually true. Masterly management, therefore, addresses the structural and behavioral problems we saw with micro and motherly management:

The delegation inherent in the plan means that most contentions and minor conflicts get solved without the manager’s intervention, so most of the time the people aren’t waiting for the manager’s attention. When a problem does require the manager’s attention, that problem doesn’t have to wait in line behind a bunch of minor conflicts.

This support for parallel activities means that masterly management can work with projects that are just too complicated to be understood in all their detail by a single manager—and most software projects would fall into that category.

Because the people being managed are also delegated a self-management job, they are able to contribute observations that a micro or motherly manager is likely to miss.

Masterly management involves managing the project rather than the individuals. Most of the time, the people doing the work are free to pick their own methods within some basic guidelines (for instance, driving on the correct side of the road, or using the corporate standard tool set). This allows creative energy that might otherwise be spent on finding ways to “beat the system” to instead go toward creating profitable products.

In short, a masterly manager like Andy observes and steers a system. If the problem is well understood, the plan is appropriate, and the people doing the work are competent, the controller often doesn’t need to do much. Unlike micro and motherly managers, masterly managers spend most of their time in observation and thought rather than in frantic activity. But don’t be fooled—when Andy was sitting in his chair sipping lemonade, he was more effectively in control of the situation than either Barney or Aunt Bea.

If masterly management is so good, why don’t we see it more often? Because in some ways it’s unsettling, especially for the manager:

Looks can be deceiving Masterly managed projects often give a certain appearance of chaos. When Andy managed the intersection, traffic was turning every which way, which was disturbing compared to the neat and orderly behavior when Barney was in charge. However, more traffic moved through the intersection, and did so more safely, under Andy’s chaotic-looking management style. Many software projects already look like chaos. Will going to masterly management make them more so? We doubt it; we suspect that much of the apparent chaos in software development comes from resistance to micro and motherly management.

Power is as power does Masterly management requires a different mindset. Most people associate the word manager with the word power. Yet moving from micromanagement to masterly management involves giving up much of the apparent power and authority of the managerial position, and giving it to the people being managed. The masterly manager has more real power, according to writer Barry Oshry (quoted in Weinberg’s book Becoming a Technical Leader), if we define power as the ability “to act in ways which enhance the capacity of our systems to thrive and develop in their environment.”

Measuring what counts In some organizations (particularly those where micromanagement is the rule), a masterly manager may have a hard time getting promoted. After all, you won’t be doing much visible managing compared to the micro and motherly managers around you, and it will be easy for the micromanager who makes promotion decisions to conclude that the project succeeded in spite of your “inaction,” not because of it.

But masterly management also has rewards. Masterly managers often don’t have to work as frantically as micro and motherly managers. As a masterly manager, you’re less likely to find yourself in the office at three in the morning, trying to resolve yet another trivial issue. And you’ll get the satisfaction of knowing that you’re truly an effective leader when the project team says, “We did this ourselves.”

Micro, Motherly, or Masterly Management

The best way to determine your management style is to ask questions and observe what is happening.

Do the people reporting to you scatter like leaves in the wind when you show up? Do you feel like they are performing to the letter of the law and not the spirit? Do you jump in and start coding when there is a problem? If so, you’re probably micromanaging.

Do you organize workflow for a minimum of interaction so things go smoothly in the team? Do you step in and try to make everything all right for everybody? In crunch mode, do you revert to micromanaging? Your heart may be in the right place, but you may be in motherly managing mode.

Do you spend a fair amount of time observing what is happening, thinking about the impact the events will have on your team and project, and planning what to do? If so, you may be masterly managing.

If you would like to change your management style, there are some important questions to think about. First, how did you come to have your current management style? For most of us, the way we manage is influenced by the people who’ve managed us, and by the environment in which we manage. Acknowledging these influences, and the constraints of your current work situation, may help you determine whether it’s time for new models. It’s important, too, to examine how you feel about your style. If you’re happy with the status quo, change may not be necessary. But if you feel overworked, and seem to be constantly fighting fires, then maybe a change is in order.

And finally, what would you like to have happen? We saw that Barney, Bea, and Andy’s view of the “problem at hand” shaped their unique responses, and the same is true for you. Once you know what you would like to have happen, you can create and implement the plans that will allow you to achieve your goals and keep your traffic running smoothly.