One of the things that intrigued me about the OpenAgile framework was the explicit mention of four “capacities” that are essential to its effective use, these being:

• Courage
• Detachment
• Search
• Love of the Work

Of these it was the last one, Love of the Work, that sparked the most discussion in the training, and it brought up an old memory from a movie (whose name I can’t remember) in which an operatic singer volunteering to sing in a choir populated largely by non-professionals expressed her disdain for them by calling them “amateurs.”

The choirmaster set her straight by explaining that, contrary to popular understanding, the word “amateur” means “for love of work.” So it really wasn’t the put-down it was meant to be, but rather a compliment, however unintended.

I just now looked up “amateur” in the dictionary and, indeed, it has its roots in the Latin for “love.”

I must confess that I like that idea of being a professional amateur, a person who gets paid to do something he loves. And I like that OpenAgile calls this quality out and makes its importance visible.

We should all be so fortunate as to earn a living at work we love doing.

ScrumMaster Doesn’t Mean “One Who Has Mastered Scrum”

The intended meaning of the title ScrumMaster can be interpreted in many ways due to the ambiguity of the English language. The word master, according to dictionary.com, has several meanings, including:

• a person eminently skilled in something, as an occupation, art, or science (e.g. the great masters of the Impressionist period).
• a person whose teachings others accept or follow (e.g. a Zen master).

Now, it doesn’t seem reasonable to believe that attending a two-day course can suddenly promote one to the ranks of the “eminently skilled.”  Acquiring skill takes time. Acquiring anything that could be classified as a skill almost certainly takes much more than two days’ time. We may conclude, then, that ScrumMaster is not intended to mean one eminently skilled at Scrum.

It’s a little easier to believe that attending a two-day course could place one in the position of being able to offer advice and guidance on a topic, and I think it must be a fairly common practice for a teacher of a fresh subject to perform his or her duties by staying a lesson ahead of the students. We might, therefore, accept that ScrumMaster means a person whose guidance about Scrum others are willing to accept or follow.

Other Masters

So far I haven’t heard anyone argue that the title master of ceremonies is a misnomer. And no one expects the typical emcee to possess a mastery of all things ceremonial. He is simply the person whom others have agreed will facilitate an event.

Likewise, a ringmaster isn’t expected to have somehow mastered the rings in the circus. Rather, he is the one who facilitates the performance and helps keep it moving.

Finally, a toastmaster isn’t one who has mastered the art of the toast, but instead is the person who announces or proposes toasts, or announces after-dinner speakers. Yet another facilitator.

What’s In a Name?

Ken Schwaber, in his book Agile Project Management With Scrum, says he chose “a strange name like ‘ScrumMaster’” because he “wanted to highlight the extent to which the responsibilities of the ScrumMaster are different from those of the traditional project Manager.” He goes on to say, “The ScrumMaster earns no awards or medals because the ScrumMaster is only a facilitator.”

Given this, it seems wholly appropriate to confer the title of ScrumMaster on a person who has attended a short course on Scrum facilitation skills. The title doesn’t convey mastery. At its simplest, it’s just an indicator of a way to employ the person bearing it.

(I was inspired to write this article by a thread in the scrumdevelopment Yahoo! group titled Executives Tracking Individual Developer Productivity?  The originator of the thread wrote about a real issue in his company that had to do with the CEO wanting to measure the productivity of the company’s developers based on the principle that  “you can’t manage what you can’t measure.”)

Productivity good!

We can probably agree that productivity (in the abstract) is a good thing, but can we agree about what it means concretely? For starters, what are the “units” of productivity for individual people or teams?

For example, we can compare the gas mileage of vehicles to each other in units of  “miles per gallon”, and we would probably agree that vehicles with higher numbers are more productive.

What units could we use to compare individuals or teams in a similar fashion? One commonly-employed notion from our past, and one that we have thankfully left behind, is that developer productivity could be measured in lines of code produced in a given period of time. But if that’s behind us, what are we left with?

Productivity defined

The business novel The Goal defines productivity as follows:

“Productivity is the act of bringing a company closer to its goal. Every action that brings a company closer to its goal is productive. Every action that does not bring a company closer to its goal is not productive.”

Sounds simple enough. Now all we have to do is to figure out what the company’s goal is, and we’re there.

Do you know what your company’s goal is? Not its mission statement, but its goal? Is your company in business for a profit, or do you work for a non-profit concern? Most of us, I believe, work for companies interested in making a profit. And if that is so, then most companies’ goals might very well be as simple as making a certain amount of profit per year.

But we’ll probably want to measure the productivity of our developers more frequently than once per annum, so we might express the productivity of an individual or team in terms of “profits earned per iteration”.

The thing is, can we actually measure the contribution to profits made by an individual developer or even a team of developers? Offhand I’d say that this is a difficult proposition, at best.

However, I contend that if we cannot correlate the productivity of an individual or team with profits, then there really isn’t much point in trying to assess that productivity in the first place.

Looking where the light is better

There’s on old joke about a man who is searching the area around a corner streetlight. A second man comes along and asks him what he’s doing, and the first man replies, “I’m looking for a quarter that I dropped.” The second man joins in the search, but neither man is able to spot the lost coin. Finally the second man thinks to ask, “are you sure you dropped it here?” The first man replies, “no, I dropped it in the alley, but the light’s better here.”

In a for-profit company, attempting to measure the productivity of a developer in any terms other than contribution to profits amounts to looking where the light is better. In other words, don’t measure something just because it’s convenient to measure.

(Note: I didn’t invent the exercise described here. I first saw something like it presented at the Agile2006 conference by Ashley Johnson and Rich Phillips of Valtech Technologies, Inc.)

The assembly line analogy

I recently conducted an exercise with the folks at North Bay Agile in which two teams formed assembly lines for folding paper airplanes. Each assembly line consisted of a number of distinct operations, as follows:

• Operation 1 – Get raw material (a sheet of paper) from stock.
• Operation 2 – Fold inward lengthwise, then unfold.
• Operation 3 – Fold top corners inward.
• Operation 4 - Fold sides inward, fold in half, fold wings down.

In the first shift, every member of each team worked at top capacity. The result: Each team produced about a dozen airplanes in 5 minutes.

But then I had each team fill out a “profit and loss” statement. They got credit for “selling” all planes produced, but they were also debited for the labor and material costs of uncompleted airplanes (which stacked up in front of Operation 4, the bottleneck). The financial news: Both teams incurred a loss.

In the second shift, the teams were instructed to slow down to match the rate of the slowest operation. This was accomplished by creating a “buffer zone” before each operation and following a rule which said, “you can’t pass your work on to the next operation until that operation’s buffer zone is empty.” The result: Each team still produced around a dozen airplanes in 5 minutes.

When the profit and loss statements were filled out a second time, each team showed a profit. This was directly due to the fact that no work-in-process inventory built up, thus reducing the amount spent on materials and labor.

The most obvious difference in the overall activity of the assembly lines from shift to shift was that, in the second shift, the upstream operations were sometimes idle. By slowing the upstream operations to match the rate of the slowest operation, both assembly lines increased their productivity.

Increasing productivity stepwise

After the first shift in the exercise, the inclination of several participants was to try to find ways to improve the performance of the slowest operation. As the second shift demonstrates, however, a simpler first step is to just slow down all of the upstream operations to match the rate of the slowest operation.

The business novel The Goal outlines a process for increasing the productivity of a manufacturing system:

• Step 1 – Identify the system’s bottlenecks.
• Step 2 – Decide how to exploit the bottlenecks (e.g. don’t let a bottleneck be idle).
• Step 3 – Subordinate everything else to the above decision (e.g. throttle back the upstream operations).
• Step 4 – Elevate the system’s bottlenecks (e.g. speed up a slow operation).
• Step 5 – If, in a previous step, a bottleneck has been broken (i.e. a bottleneck is no longer a bottleneck) go back to Step 1.

 As you can see, the recommendation is to slow down all non-bottleneck operations before trying to speed the bottlenecks up.

How does the assembly line exercise relate to software development?

Although software development is not the same as manufacturing, there are situations in development that exhibit the characteristics of an assembly line. Suppose, for example, that you are a developer building components for use by other developers. If you (the upstream operation) produce components at a rate faster than the other developers (the downstream operations) can understand and use them, you can create a bottleneck, causing excess “inventory” to build up.

Software development is about creating and sharing knowledge

Here are some simple things to remember when considering whether it is more profitable to work at top capacity or to be idle part of the time:

• Knowledge is the inventory of software development
• People consume knowledge at their own rate
• Creating knowledge faster than it can be consumed causes excess inventory
• Excess inventory reduces profits

In other words, working at your own top capacity may not be the positive thing you think it is. If you’re producing software components at a rate greater than the rate at which they can be put to use, you could be hurting the bottom line.