I use a simple poll of how safe people feel. I got this from Norm Kerth’s book, Project Retrospectives (page 110). Norm describes this as part of an exercise to increase the sense of safety in the room and promote honest and open speech. In the context of a day-long-or-more end-of-project retrospective, then I can see the value of such an exercise. For an heartbeat retrospective, I don’t attempt this. I’m not optimistic about significantly raising the level of trust in a short period of time. There will be other retrospectives, and there will be time to work on trust issues in between. It’s often helpful, though, to bring the issue of trust and safety to the surface.

For getting a sense of the safety in the room, I’ll ask people to rate their feeling using this scale:

1.    I’ll just keep my mouth shut
2.    I’ll agree with whatever the group says
3.    I’ll discuss the non-controversial topics
4.    I’ll discuss almost anything
5.    I’m willing to talk about anything

I have everyone write a number on an index card or sticky note as a private ballot, and fold it so the number is not visible. I will then collect the ballots (or delegate to someone who seems both trusted and without power over others) and count the number of each value. On a whiteboard or flip chart I’ll record these with hashmarks. This gives a simple obvious view of the reported safety.

Sometime I’ll point out that this is only the reported level of safety. After all, if someone doesn’t feel safe, they may not feel safe enough to answer this question openly, either. They may give then number that they think is expected, or the one they think others will give.

Retrospectives are difficult in low-trust situations. They’re also a great tool for building trust over time.

I’ve led a separate retrospective for developers (programmers and testers) at a client making an Agile transition. In that situation, it seemed to me that the full-team retrospective concentrated on “acceptable” improvements—things that were easy to propose in a corporate environment. And I noticed that a number of the developers didn’t say volunteer anything. That was a clue to me that there were things to be said that people didn’t feel comfortable saying. Given the fact that the Scrummaster was a former project manager, this dynamic wasn’t unexpected. Having a separate retrospective, with a safety exercise at the beginning, allowed some issues to be acknowledged, even if they weren’t tackled.

In my friends situation, the majority of the participants are programmers who have, for the most part, worked with each other at other companies. They know each other well and are working together at this company precisely because they get along and respect each other. That’s all well and good, but the side effect is that there’s a bit of a monoculture among these developers. They readily agree with each other within a limited viewpoint.

You would think that a retrospective would bring out other viewpoints and counteract the hegemony of this group. Unfortunately, the group had settled on “majority vote” as their standard means of deciding which topics to pursue in the retrospective. How did they choose that? I don’t know, but I’d guess they voted. Ellen Gottesdiener examines a number of group decision-making approaches in her article “Decide How to Decide.” (Software Development Magazine, January 2001) While majority vote is fast and efficient, it always results in a loser, and sometimes in a persistent loser. For retrospectives, I prefer “Spontaneous Agreement” or “Consensus.” When the group I’m facilitating can’t converge on a choice that hears all voices, I’ll sometimes fall back on “Decision Leader Decides After Discussion” to give those voices a chance.

If you’re stuck in this sort of situation and you’re not the facilitator or otherwise capable of making the decision, then feedback to the retrospective facilitator might be in order. It could be that the facilitator just hasn’t noticed what is happening. It could also be that the facilitator doesn’t yet have the skills to know what to do about the retrospective being consistently owned by a sub-group. Some helpful feedback, stated in terms of observed behavior and personal impact, might be just the thing to break that log-jam. Or, it might not, particularly when there’s a difference in organizational power between the facilitator and the person who wants to help the situation.

Having a separate retrospective of people locked out of the decision-making in the larger retrospective is an escalation of this approach. If one person has been unable to influence the facilitator’s behavior such that all voices are heard, perhaps the group of disadvantaged people can dig deeper into the problem and come up with some more effective solutions. If this group continues to feel the need for a separate retrospective, though, then it indicates a continuing problem.

That’s not a good sign for the organization. Human dynamics of a given group don’t always work out smoothly. And sometimes organizations fail.  Being deaf to voices have different information, values, or preferences is a good way to fail. The universe doesn’t depend on every organization succeeding. As an individual, there’s always Martin Fowler’s advice, “Change your organization, or change your organization.“

One of the low points was when several people, including a business analyst, product owner proxy, and the program manager, individually said that they couldn’t alter the “user stories” to cut across multiple components of the system because they were already in the computerized planning tool (and Word documents) and it would be too much work. That team did not appear to be getting much value from their “Agile approach” and had significant integration risk that was being studiously ignored.

One of the most frequently asked questions on public mailing lists and forums devoted to Agile development is “What Agile Planning Tool should we use?” There is always a chorus of answers touting this or that computerized tool, usually without asking any questions about the context. Is there one best tool?

Given the number of such tools available, either for purchase or for free, people are still seeking that perfect tool. Like Lord Franklin seeking the Northwest Passage, some pay a heavy price for that search.

What’s the big difference between the two situations described above? The first difference is that one was using a physical planning tool and the other a computer program. Should we take that as evidence that physical tools are always preferred and computer programs should be eschewed? That would be hasty without looking deeper. Our second “why was one team more successful than the other” answer is that the first team adapted their process according to the successes and difficulties they were having. The second held to a “consistent process” when it was getting in their way.

One of the biggest problems for teams trying to learn how to be successful with Agile techniques is that they often don’t recognize what’s getting in their way. They’re often trying to do things “by the book” to learn Agile practices–which is a good starting point. But they’ve not yet got enough experience to see the early warning signs of Agile impediments, and by the time they do, they often jump to the conclusion that “Agile doesn’t work.”

Let’s look at a recent inquiry on the Agile Project Management yahoogroup. The questioner mentioned that his small team was moving to Agile/Scrum and because they were partially distributed, were looking for “a product management platform at least to enable a virtualized scrum board and some basic reports like the burn down chart, etc.”

Some people opined that, because they were distributed, only an electronic tool would work. This isn’t necessarily the case. I’ve heard several reports of successfully using physical boards duplicated at each location. I can see some real advantages to this approach. One of the biggest challenges of distributed development is keeping the assumptions and attention of each location in sync with the others. Talking through the changes on the board on a daily (or more frequent) basis is an excellent means to accomplish this. Having silent changes that happen in the background within a computerized tool while you’re not looking, is not.

As it turns out, the team isn’t really distributed. The product owner and another business stakeholder is remote to the development team. The product owner makes an effort to be regularly engaged, but wants to give more visibility to the other business stakeholder. Using a distributed planning tool for this sets off warning bells in my head. It’s making the daily work of those producing the software more difficult for the benefit of someone who is insufficiently engaged in the process. I often hear the counter argument that “it’s only a few seconds to use the tool.” That may be, but those few seconds are multiplied many times over during the course of the project. They become a real drag on productivity and lengthen the cycle times. I’ve not measured the effect, but I’ve seen it clearly. Worst of all, it eventually discourages people from making improvements to their process because they’ve got so much invested in the current incarnation.

There are more insidious effects, too, when an electronic tool is being mandated just to observe from afar without engagement. The information that goes into the tool becomes a public record, and people start worrying about how to make it look good to others rather than how to use it to get work done. This is an even greater productivity friction, and it siphons attention away from the original goal.

The product owner of this team would do far better to develop a sprintly summary for the other stakeholder. Business stakeholders don’t really need visibility into the details within a sprint, anyway. If they truly do, then the sprints are too long. Broadcasting all of the minute details of how people are working just invites micromanagement and breeds distrust.

This is just one case study. In other situations, I would call attention to different details and likely offer different advice. Covering all the cases would be far too much for a blog posting. Besides, the real point is that people need to keep their ultimate goals in mind, and not trade thoughtful observation and decisions for the magic of a virtual tool.

P.S. Tim Ottinger and Jeff Langr have published some very good advice on this topic.

Hat for Test Driven Development

He included a photo of me wearing my Red-Green-Refactor TDD hat. This had may be more famous than I am, having been worn by Uncle Bob Martin in Episode 6 of his CleanCoders videos.

I hope this will be done by then.

These are sad and scary words to me.  When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations.  Further, it’s likely that there is no good indicator of what can be delivered when.  With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.

We’ve done our part.

This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.

You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.

This weekend I was saddened, though not surprised, by the number of tweets with complaints about the conference, often tweeted by people who didn’t go. To paraphrase Yogi Berra

Nobody goes to the Agile Conference anymore. It’s too crowded.

It’s true that the Agile Conference doesn’t have a tight, narrow focus. It casts a wide net and is as inclusive as possible. This means that, no matter what your interest, it doesn’t concentrate on that. This means that it’s almost certain to have more interesting sessions than you can possibly attend. On top of that, there are many interesting conversations and side-sessions in Open Jam and in the hallways that are often worth as much or more than the sessions. It’s an embarrassment of riches.

I no longer worry about the things that I’m missing. Instead, I concentrate on the fact that my time there is bringing me value. I can’t optimize the value I receive, but I can use the “Law of Mobility” to get up and go somewhere else if I’m not getting enough value. This year, I found I rarely had to do that. Even when I wanted a bit of peace and quiet, I got sucked into valuable conversations. Even walking down the hall, I got sucked into Jim Shore and Arlo Belshee’s “Stages of Practice: the Agile Tech Tree.”

It was a conference of connecting ideas for me.  The Agile Tech Tree session tied right into the levels of proficiency from Willem Larsen’s “Fluency over Proficiency: Accelerating Agile Learning and ‘Hunting Fluency’.” Barbara Fredrickson’s keynote, ” Why Care about Positive Emotions?” contained many key points that dovetailed with my workshop on ” Team Swarming–Why and How.” (Those in my session know there were no slides, but I’ll be uploading the flipcharts we generated in the workshop. I’ve uploaded the flipcharts, as well as the slides I didn’t use.)

Yes, I missed many, many sessions that I would like to have seen. Sometimes I missed sessions not because of the conference design, but because of the limitations of my own body.

To be sure, there are things that could be improved about the conference. That’s always true. Every year, the current organizers hold a retrospective to notice things they want to change, or continue, in the next year. As Linda Rising says, “We are all a work in process.” It’s futile to ever expect optimization of a system composed of people, though. And this conference is an extremely distributed work by many volunteers, some of whom are new to the process. There are a wide variety of goals among those who work to put on the conference. Far from being disappointed in its imperfections, I’m amazed at how it soars.

But now the conference is over and I’m back at home. There are many things I want to pursue while the ideas and passion are fresh. There are two ideas, especially, that I’d like to collaborate with others who have passion in the same area.

• Applying the ideas and techniques from Willem Larsen’s Language Hunting to learning and training Agile concepts and techniques.
• Exploring team swarming and collaborative team formation.

If you have passion and energy in these areas, please contact me, and let’s see where we can go with it. And if you want to stay in touch less energetically, sign up for my occasional email newsletter.

But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. It’s like having a small box of crayons.  One person takes the red crayon, others orange, yellow, green, blue, and violet. With that, we try to create a glorious full-color work of art. It’s no surprise that’s hard to do.

Colors in the real world flow from one named color to another, without a discernible boundary. It’s a continuous spectrum to which we’ve given names at certain approximate points. You just can’t draw the world as we see it using only six crayons.

The typical corporate response is to add more crayons.  And more people to hold those crayons. And more delays caused by passing things from one person to another. And… we still don’t get the picture we want. The more people we have, and especially the more specialists, the harder it is to get a pleasing cohesive picture.

We don’t need to eliminate specialization, though. Just blur the boundaries a little. We can get the full-color rendition we want with our limited palette if we blend the colors where they meet.

Rather than pass the work from one type of the work to the next, let the people doing those different types of work work together. They might even swap colors with each other from time to time. Odds are, they’ll do a much better job at producing the picture you want.

Bob Pease, analog engineer at National Semiconductor and writer at EDN Magazine, used to say, “when something seems funny, measure the amount of funny.” That’s easier done in the engineering domain than the people domain, of course.

These two simple guidelines will help:

1. Measure the things you really care about. Too many people collect numbers that are based on guesses or on indefinable units. If you’re measuring productivity, figure out a way to measure delivered, working features, not “story points” or other estimates. Jack gave an example where, to increase the number of circuit boards being produced, the technicians were not bothering to repair the boards that didn’t work. They were tossing them aside, creating a pile of waste inventory. In Jack’s example, the productivity measurement only measured part of what was desired.

2. Use measurements to illuminate, not as a goal. As Michael Bolton says, good metrics allow you to ask better questions. They don’t answer them. The productivity numbers mentioned above didn’t say how productive the workers were being, because it didn’t show the wasted inventory.

Measuring things is a great way to sharpen the observations. It’s still an observation, though. Sometimes you can observe things that you can’t measure. In that case of a “strong feeling of ‘things are better,’” you may not be able to measure how much better. But you can still ask the data question, “What have you seen or heard that makes you think things are better?”

Observations without measurements are still valuable.

In the course of writing this post, I’ve just discovered that Bob Pease died last month in an automobile accident. The world has lost a great analog engineer, and a man who eloquently cared about engineering.

Data show that good people do various software tasks 7 to 28 times better than others… Could we, for example, find out what the good people do? And once we found out, could we transfer that technology to others?

Now, I haven’t read this paper, so it’s quite possible that it’s taken out of context.  But it was introduced to me with the question

This sounds like the goal we are trying to do, to discover the most effective way to do something and then enable others to work the same way.  Does anybody disagree with this as the goal?

That sounds so logical, doesn’t it. We find that person who’s most productive, and have everyone else work the same way. All we have to do is write down what they do and make it the standard. Oh, dear. I’m afraid that’s not the way people work. Fortunately, it also doesn’t be quite what this person intended, either. But this point of view, or some parts of it, pop up often enough in the software development field that it’s worth taking a closer look at it.

There’s no doubt that some people are more effective at some tasks than others.  Such observations are common.  Less common are observations that group effectiveness is often highly dependent on the little-noticed behavior of someone who is not considered highly productive, but who acts as a catalyst to others.  I’ve heard tales where the catalyst was eliminated as non-productive, and the group’s productivity, including that of the stars who were put on a pedestal to be emulated, plummeted.  It’s clear to me that we should not look to “good people” but to “effective teams.” The most effective teams take a mix of people and approaches, not a bunch of clones.

This is but one of the ways that a process definition approach tends to miss the mark.  What is an effective process for one group might not work so well in the group next door.  Yet there are ways for each group to collaborate and excel.  Effective teams are not created by telling them how to work, but by facilitating their finding their own way to work.

Most “standards programs” attempt to make all units work the same way. I suppose that it seems easier to manage that way. You wouldn’t have to know the capabilities of the individuals. Or the teams. You could treat them all interchangeably, right?  Of course, it’s pretty obvious that people are not fungible. In operation, even identical machines turn out to need individual care.

Back in 1998, a consortium led by Motorola started a satellite phone business, named Iridium, with low-earth satellites. A short nine months later, Iridium was bankrupt. There was much discussion about what to do with these satellites, which if abandoned would be a significant hazard. Fortunately, the backers were able to find a buyer for the company, at less than a half-cent per dollar of the original investment. How did such a venture go so very wrong? There are many things, but one significant problem was the assumption that flying a fleet of identical satellites would be little harder than flying one. That turned out to not be the case. Each individual satellite, once launched, was subject to unique conditions and required individual trajectory calculations and control. This drove up the ground control costs by a couple orders of magnitude, which made the service too expensive to profitably sell. So much for economy of scale by standardization.

With people, there’s even less reason to expect such economy of scale. Remember that the Agile Manifesto points out that individuals and interactions trump process and tools. It doesn’t say that just to protect people. It says it because it’s the experience of the signers that it’s more effective to put your trust in people than in processes.

That’s not to say we shouldn’t share what works with our processes and learn from each other.  But it does say that each group has to adopt their own process, not have it imposed on them because some “scientific approach” has found it to be superior.  That’s just a return to Taylorism.

Many standards programs assume that there is a most effective way to do something.  They assume that this effective way is transferable from one person to another.  And they assume that the benefit of this magical way of working will pay off all of the deleterious effects of trying to enforce that transfer.

In my experience, there are many effective ways to do most things. What’s most effective for one person might not be so for the next. What’s most effective in one situation might not be for the next.

Transferring beneficial practices from one person to another cannot be accomplished by a third person decreeing it. The person picking up these new practices must want them. This means that there must be something desirable about these practices for them, not just for the company. Pushing hard for standardization from the outside can have the opposite effect, that the practices are never given a reasonable trial before being rejected.

Instead, we’re better off building an environment that makes it easy to share information. We need to foster a culture that values learning. We need to facilitate, not force.

It’s my understanding that the “standardized work” of the Toyota Production System is not a standard imposed from outside the workers following that standard. It’s their recording of the way they currently work to the best of their ability. And it’s intended to be modified and improved on a continual basis.

That’s the kind of process standard that produces benefit.

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me.

I wholeheartedly agree with Brian’s assertion that we have “a readiness to reduce (abstract away, simplify, generalize) the world’s complexity into something simpler that you can work with and think about.” This is not just true of knowledge workers, but of people in general. The assault of the universe on our senses is far too much to observe without doing so. As Brian says, “By default, we mostly act unconsciously, with the unconscious mind forwarding only anomalies to the rational part of the mind.” In other words, when the world around us is appearing to conform to the models that are most ingrained within us, we can react according to those models without making a conscious choice.

Other models are less ingrained, and we apply them more consciously.  Brian’s examples of the “homo economicus” and the “V-model of the Systems Engineering Process” models are good illustrations of models we’ve built particularly to help us with situations that our subconscious doesn’t handle.

Is there a fundamental difference between our unconscious and conscious models? As far as I can tell, it’s only in our awareness of them.  The study Brian uses to illustrate the power of the unconscious mind describes a detectable awareness between a cookie sheet and a chess board.  The unconscious model accounts for putting a cookie sheet into the oven, but does not account for putting a chess board into the oven.  Certainly both cookie sheets and chess boards are too modern to be innate to the species. Instead, the pattern of putting a cookie sheet is one to which we’ve become accustomed by familiarity. Or, at least, most of us have. Trying the same experiment with people unfamiliar with ovens, cookie sheets, and chess board would assuredly give different results.

Reductionist models are the way that both the conscious and unconscious mind deals with the sensory overload.  But the models we use can lead us astray.  As Brian says,

So sticky is the “homo economicus” reduction that economists face the occupational hazard of treating it as the only model of human behavior, which can make them say awfully silly things. Similarly, elegant and simple software development models like the V-model are so elegant, so simple, so pleasingly linear that their failure to work with real human behavior and limitations is commonly seen as the fault of the people, not the model.

H.L. Mencken put it this way, “For every complex problem, there is a solution that is simple, neat, and wrong.”  We are more likely to jump to an easy answer when we only know one model that fits the situation, or when we fit a model that’s so deep in our unconscious that we don’t notice it’s there.

If we are to avoid the trap of being limited by an inappropriate model, then we need to know more than one model.  And for the unconscious models, we need to find ways to rethink the situation according to conscious models.

In fact, this latter use is the value I find in the Myers Briggs Type Indicator model that so irks Brian. Brian would like for people to discard MBTI because it’s not “true” and doesn’t predict peoples’ behavior well. I, on the other hand, don’t expect either of these things from MBTI. It only aspires to be a model of preference, not behavior. While it often gets misapplied for things such as predicting what career path a person should take, that’s not, as far as I know, an intended use. And I don’t believe it’s “true” in the sense of corresponding to entities in the human psyche. Instead, it’s “true” in the sense that it corresponds to human observations, much as putting a cookie sheet in the oven does. I’m not even convinced that the preferences indicated by the MBTI are constant. I wonder if my preferences change slowly over time, and if they sometimes change rapidly and suddenly in response to the situation.

Whatever the faults of the MBTI as a model for people, it helps me to rethink the application of my unconscious models. As an introvert, my unconscious model might label an extravert as pushy and self-absorbed. Re-evaluating the situation in the light of MBTI, however, may suggest to me that they’re merely thinking out loud. As an NT (iNtuitive-Thinker), it’s easy for me to jump to the conclusion that the solution in my head is both correct and obvious. Realizing my preferences helps me to realize that it is unlikely to be obvious to others, and that I should test its correctness with some data.

We would do best if we always beware our implicit trust in our models, especially our deepest and most closely held ones. These are the models that allow us to act immediately and “instinctively.” But it is the model we don’t question that will most likely get us into trouble. From time to time, especially when things are not playing out to our liking, we can view the same situation in light of multiple models and see if they give us different insights.