Archive for the ‘Collaboration’ Category.

Avoiding the knowledge transfer bottleneck

In software development there are many ways to transfer the knowledge about how to build a product to the people who do the actual building. Production can be severely hampered, however, if that knowledge is being produced more rapidly than it can be consumed. This is the knowledge transfer bottleneck.

I recently hosted a workshop that let participants experience three different ways of transferring knowlege in a production environment. The product, in this case, was a paper airplane of unusual design. The idea was to try different ways of transferring the knowledge about how to build the airplane from the “chief designer” (me) to the production workers, and to compare the relative productivity of the different methods, which were:

  • Documentation – The workers were given written instructions (22 steps worth) for building the airplane.
  • Reverse Engineering – The workers were given a completed airplane which they could study in order to reproduce the steps required to build it.
  • Mentoring – The “chief designer” built an airplane step by step and the workers replicated each step as it was performed.

The experiment was conducted in two phases. In the first phase, all 8 participants used the Documentation method. In the second phase, one team of 4 tried Reverse Engineering, while the other team of 4 tried Mentoring.

The results were interesting. Using the Documentation method, only one person out of a total of 8 came close to being able to build the airplane at all in the 5-minute period allotted.

Using the Reverse Engineering method, 1 person out of a total of 4 produced a completed airplane in 5 minutes.

Using the Mentoring method, each of 4 team members produced a completed airplane, and in less than the 5 minutes available.

The knowledge transfer bottleneck in software

In a software development effort, knowledge transfer takes place all the time, and it’s easy to imagine a software developer in the “chief designer” role described in the exercise above.

Let’s say I’m a developer who has discovered, and written the code to implement, a technique for binding some data to the controls in a user interface, and that this technique forms a pattern that my fellow developers want to know about. If you were one of my fellow developers, would you rather I (a) gave you a document I had written about the technique, (b) told you where the code was and suggested you figure it out for yourself, or (c) paired with you to implement the pattern for a new set of data?

Now, certainly, pairing with you takes more of my time, and might seem less efficient from my viewpoint. After all, I could be off designing the next pattern, and the one after that. But the  productivity of the team as a whole, rather than my personal productivity, is what’s important. And mentoring helps increase the team’s productivity by avoiding knowledge transfer bottlenecks.

Mindful engineering

I’ve been pondering lately what was special about the teams I’ve been on that have felt the most effective to me. It wasn’t just a certain set of practices, though those were helpful. The essence, I think, was a certain openness to ourselves and to each other, a willingness to really look at what we’re doing and how what we’re doing affects the project, ourselves, and each other.

Retrospectives are a specific practice that provides regular opportunities for this kind of openness. But even more, when I’ve really felt productive there’s been a pervading attitude on the team that it’s always okay to take a moment to explore some interaction or event at a deeper, more personal level.

One day, on a team of four, we were programming in two pairs. At some point my partner and I noticed that the other pair had reduced to a solo. We asked, “Where’s your partner?” and he replied, “I think he got upset with me.” My partner replied, “Well, I hope we can talk about that later.” And the really amazing thing is: We did. The partner returned, and described what he had gotten frustrated about, and we were all able to talk constructively about how to deal with that kind of frustration.

Another day, on another team, also while pairing, I noticed my partner withdraw and get quiet. I wasn’t quite sure why, though I was aware that we had been debating some technical point. She started to go on with the task, but I stopped to ask what was up, and she said, “I’m just not getting much ‘Yes, and…’ from you right now.” We had both learned the “Yes, and…” principle from improv classes—which I highly recommend—and it was an easy way to remind ourselves to respect and build upon each others’ ideas rather than only pursuing our own. This quick check-in in the middle of a task short-cut what could have been a long period of frustration, leading instead to a productive, collaborative session.

As I said, this isn’t about specific practices as much as it is about a thorough willingness to talk to each other openly and to respect each others’ thoughts and feelings. Obviously, I think that Agile practices, especially retrospectives and pair programming (when done well), are a good way to foster this kind of openness. In fact, what first drew me into the Extreme Programming community was the openness to learning that it demonstrated.

In my short career up to that point, I felt that I wasn’t really learning much—I was already a pretty good programmer, but the really tricky problems on my projects were less about programming and more about communicating with each other and with the project’s stakeholders and about finding ways to keep everyone sane in the face of growing complexity and business uncertainty. These were the real challenges, but no one was really addressing them—until I found the XP community, who were meeting every month to talk about exactly these issues, and about what they were trying and what they were learning about them.

Now, of course, this kind of concern for how we work together is not the exclusive domain of Agile communities, though some of us often talk that way. The CMM community is likewise dedicated to trying new things and talking candidly about how they’re working, albeit with a more formal approach. The Space Shuttle software project case study described in the CMM book is actually quite an inspiring story of worker empowerment and process experimentation and improvement over time.

Why do many in the Agile community criticize the CMM, lumping it together with the straw man process known as “Waterfall”? I think that Waterfall is an example of formality in a process without authentic openness and introspection. When a manager looks at an undisciplined project and sees it spinning out of control, the most common reaction is to impose some control with some mandated formality. The CMM may be used as a framework for that formality, even though the authors of the CMM themselves strongly warn against using it to impose formality without honest assessment and openness to continuous improvement attached. (They even have nice things to say about XP.)

I’ve been exploring the practice of mindfulness lately, and I think it nicely captures the kind of openness and introspection I’m talking about here. Mindfulness can be practiced through activities such as meditation, improvisation, journaling, and reflective listening, and has documented benefits for compassion, empathy, concentration, and even happiness itself.

I can easily see the appropriate level of formality varying based on the nature of the project, but this quality of mindfulness seems essential to any endeavor. Agile methods tend to be moderate to low on the formality scale, and—when they work—high on the mindfulness scale.

How are you mindful of your work? How are you not?

Start at the end

Any software development effort involves the conveying of information, but it’s easy for the important information to be hidden by related (but less important) stuff. Starting at the end is a good way to focus on the information that matters most.

Drawing Maps

In the days before Google Maps, we used to ask other people for directions to places we wanted to go, and often someone would volunteer to draw a map on paper. After taking part in many of these information exchanges, I observed that most people (including myself), when drawing a map, start at the beginning. That is, they start the drawing at the traveler’s point of origin and proceed from there to the destination.

The result was almost always adequate for the intended purpose of getting the traveler from point A to point B, but I noticed that the destination often ended up being crammed into a corner of the page, almost as if it were an afterthought rather than the most important piece of information on the map.

Now it certainly makes sense to draw a map in this fashion. I imagine that the main reason for doing it this way is that when drawing a map we imagine ourselves actually taking the trip we’re describing. We start at the beginning of our imaginary trip and eventually find our way to the destination.  And unless we begin with an inordinately large piece of paper, or are particularly good at allocating space ahead of time, we end up with a map that contains extra information we really don’t need, while details of the destination are omitted because we run out of room.

So I started drawing maps from the end. The first place I put on a map is the destination. From there I work backwards, drawing the streets leading to the destination. Then, if I have room, I draw the highways leading back to the city of origin. The result is a map that emphasizes the important details.

Communicating Technical Information

I’ve noticed a similarity between the way people draw maps and the way they convey technical information. That is, they often tend to start at the beginning and proceed in chronological order to the end.

Just as in map drawing, this approach makes a certain amount of sense. It’s natural for people to convey information in the order in which they discovered or developed it. The communication of the information is kind of a chronological account of the original experience of creation.

The problem is, it’s the end (the destination) that I’m most interested in. I tend to think of the result as the important part, with everything leading up to it being more like “supporting information” which I may or may not want (or even need) to know.

In other words, I tend to get lost in the details of the journey, when what I’m really interested in is where I’m going to end up.

Writing Software

I used to write code from top to bottom. That is, when I wrote a method I would start at the top of the method, and write lines of code in the order in which they would be executed. It made sense, in a way, because I was taught to read and write English from top to bottom. It seemed the natural way to go about it. Unfortunately this approach tended to introduce unnecessary code into the method that had to be stripped out later.

Now when I write software, I like to start at the end. When I write a unit test, for example, I start by writing the assert statement, even if it asserts against objects that don’t yet exist. I start with the assertion, then I see what the assertion requires and I write a line of code above it to satisfy those requirements. If satisfying those requirements introduces new requirements, I write a line of code above that, and so on.

The result is a unit test that carries no extra baggage, no superfluous information, with an emphasis on the most important part, the assertion.

The assertion in a unit test is analogous to the destination on a map. Both are the most important pieces of information. Both make excellent starting points.

Clicky Web Analytics