This past Thursday and Friday I attended a 2-day OpenAgile Team Member Training session.
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:
- 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.
Should satisfying the customer be the number one goal of your business? Almost.
The first principle in the Agile Manifesto states:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Now, I don’t know anyone, nor have I ever heard of anyone, who spoke out against the concept of satisfying the customer. Look at any company’s mission statement and you’re likely to find a phrase in there like “the customer is our top priority” or “customer satisfaction is our number one goal.” Is there anyone who hasn’t heard the expression, “the customer is always right”?
And it’s a fine sentiment. Satisfying the customer is a good thing. But is satisfying the customer really the main goal of your business? I’d guess not. You could satisfy your customer by, for example, giving away your goods or services for free. Talk about satisfaction! (At least for your customer. You would probably not be quite as happy about it for very long.)
That’s not to say that satisfying the customer is not your top personal priority. It may very well be, as we tend to derive a lot of personal satisfaction from satisfying others.
But the main goal of a for-profit business is to make money. For many the goal is not just to make money, but to make more money. Satisfying the customer is simply an effective means to that end.
I don’t mean this in a cynical way, mind you. I run a business, and I want it to make money. No apologies. And it really helps to remember that if I want to make money, I must satisfy my customers. That direct association is a lot more meaningful to me, especially when it comes to making business decisions.
So, then, how is it that satisfying the customer helps your business make money? Through repeat business and referrals. If a customer comes back, that’s more money for you. If a customer recommends you to someone else, and you get them as a customer, that’s more money for you. If this keeps up, you stay in business.
But disappoint your customer, and your customer goes away. Even if you’re currently a sole source for a customer, as soon as another, more satisfactory provider appears, you’ve lost a customer. And even while you’ve still got that captive customer, will that customer recommend you? Would you?
So how can early and continuous delivery of valuable software satisfy your customer? By helping your customer make money. Remember, your customer is also running a business, and the goal of that business, just like yours, is to make money. Early delivery of valuable software to your customer can help them start earning sooner. Continuous delivery of valuable software to your customer can help them adapt to a changing market.
And what makes software valuable? Simply put, software is valuable if the cost of the software is substantially less than the cost of the problem it solves. So if you can provide your customer with a software solution that costs substantially less than the problem you’re solving, your customer makes money and is likely to be satisfied. The earlier and more often you do that, the more satisfied your customer will be.
So in addition to the first principle of the Agile Manifesto, you might also consider applying a business-oriented version of the “oxygen mask rule”:
“We take care of our business first, so that we can continue to provide valuable software to our customers.”
Much has been said questioning the appropriateness of the title ScrumMaster to describe a person who has attended a two-day Certified ScrumMaster (CSM) course. I believe the title is appropriate. Here’s why:
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.
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.
September 28th, 2009 in
Can you measure the productivity of an individual developer or team of developers? Do you really want to? If the answers to these questions are “yes”, the first thing you’re going to want is a clear definition of productivity.
(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.”)
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?
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.
September 16th, 2009 in
Chris Sims and I are hosting a workshop on September 30 in Redwood City, CA.
This one-day experiential workshop will equip you with tools to understand who your users are, what they do, what they need, and how your product can deliver maximum value to them. You will be ready to provide product leadership to your development team, at agile speed.
The workshop is ideal for agile product owners, product managers, business analysts, and anyone who wants to understand how to gather and manage requirements for an agile development team. Developers are also encouraged to participate in order to experience what it’s like to own the product.
Please visit http://agilelearninglabs20090930.eventbrite.com/ for more details.
September 9th, 2009 in
There’s a long tradition (since 1968, according to Wikipedia) of looking at software development as an engineering discipline. But calling software development engineering is something like adhering to the letter of the law, rather than to the spirit
Software development is about acquiring knowledge
If you think of software development as strictly an engineering discipline, you might be inclined to believe that the job of a software engineer is to apply his or her previous knowledge and training toward solving a particular problem. And you’d be right, to a point, because knowledge and training are important aspects of software development.
But you’d also be missing the key factor, that software development is mostly about acquiring new knowledge. Software developers are always engaged in the following pursuits:
- Discovering what to build
- Discovering how to build it
This goes a long way toward explaining why so much software is custom software. If software development were entirely an engineering discipline, it is conceivable that we would be able to construct just about any software application by plugging together the proper parts, chosen from a catalog of well-known, existing components. The fact that we aren’t even close to being able to do that is an indication that we still have a lot of discovery ahead.
Discovering what to build
How do we discover what to build? By working closely (and continually, if possible) with the customer. By getting feedback as often as possible from real users, and by constantly applying that feedback to the product under development.
Discovering how to build it
From the developer’s perspective, this is a career-long pursuit, as new techniques for building software are always appearing. As software developers, we can provide the greatest benefit to our clients by being aware of new developments in the field, but tempering that with the client’s needs to meet specific schedules and cost targets.
For any particular product, we can practice Test Driven Development (TDD) and encourage emergent design, so that we avoid imposing our own pre-conceived (engineering) notions on the product, and instead develop just what the client needs (and no more).
August 23rd, 2009 in
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 knowledge 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.
August 14th, 2009 in
A team in which everyone works at top capacity has got to be the most productive, right? This article explains why it ain’t necessarily so.
(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.
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.
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.
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.
Much has been written on the subject of how to estimate the effort involved in developing software products. Some Agile teams use Story Points as their estimation units. Others estimate in Ideal Days. Still others use one of these plus Task Hours to help refine their estimates. Planning Poker is a popular method for quickly arriving at group consensus on estimates.
My own earliest attempts at estimating predate the Agile era by a couple of decades. In the beginning I used a technique that has probably been tried (with varying degrees of success) by many others:
- Break the development effort into as many small tasks as you can think of
- Estimate each of the tasks in hours
- Add all the estimates together
- Apply sufficient “padding” for comfort
- Hope the boss buys it
Estimation’s main purpose
There’s no doubt that the more recent Agile estimating techniques are much better than what I started out with, and I’m glad that so much effort has been put into developing these methods. Even so, I believe it’s easy to lose sight of the purpose behind estimating, which can be summarized as follows:
The purpose of estimating is to provide the customer with a predictable development schedule.
Predictable is the operative word here. With a truly predictable schedule, the customer can derive the information that is most important from his or her point of view. Given a predictable schedule, the customer can answer important questions, such as:
- How much will this development cost?
- Will we be able to hit the market window?
In other words, the customer is probably not interested in the accuracy or precision of your estimates in and of themselves. The customer is more likely interested in the predictive power of your estimates. Given that, you want to focus your estimating efforts on things that provide predictability.
Duration should be derived, not estimated
I like to encourage teams to focus on estimating User Stories in Story Points, and to discourage them from estimating tasks at all, largely because coming up with Task Hours doesn’t seem to contribute much to the goal of providing the customer with a predictable schedule. Admittedly, estimating Task Hours may help to inform the team about how good or bad it is at estimating duration, but that’s a metric that’s not directly useful to the customer.
What is directly useful is duration that is derived from a team’s demonstrated velocity. Given a velocity in units of Story Points per iteration, plus knowledge of how many Story Points remain in a development effort, the customer can quickly and easily predict the development schedule.