Estimating in the abstract

This excerpt from the Kindle pocket guide, Practical Estimation, discusses the relative merits of the most common units used in relative estimation.

Abstract Estimation Units

When estimating the traditional way, a discussion of estimation units doesn’t happen very often. If someone asks you how long it will take to complete a task, they’re thinking in terms of calendar time. The implication is that they expect you to answer in kind.

But it doesn’t mean that you have to estimate in calendar time. Relative estimation necessarily means that you’ll be working in abstract units. Some examples of this are:

  • Ideal Time - An ideal day is a work day free from interruptions and other overhead.
  • T-Shirt Sizes - Some teams use Small, Medium, Large and eXtra Large to indicate the time required to complete projects.
  • Points - Abstract units representing relative time to complete units of work.

When I first started practicing relative estimation, I was taught to think in terms of ideal time. If, for example, I believed that a task could be completed in 1 ideal day, and the team’s velocity was 2.5 ideal days per week (0.5 ideal days per day), then I could expect the task to take 2 days to complete. But I found this conversion between ideal days and real days confusing. The technique also had the unwanted side-effect of encouraging me to think in absolute time instead of relative time, so was really no better than estimating in real days.

The use of T-shirt sizes has a certain appeal, in that it provides a mechanism for quickly conveying high-level information from developers to managers. In my experience the drawback is that, being non-numeric, these units cannot be used to perform arithmetic, so cannot directly be used to predict schedule.

I prefer the use of abstract points for relative estimation. Point values can be used to express the relative time it will take to complete a unit of work, compared to other units of work. Early on I was encouraged to think of points as representing the “size” of a unit of work or the “effort” required to complete it. Those terms, although somewhat helpful, never seemed to describe what it was I was actually estimating, and I eventually came to think of estimating in points as estimating in terms of relative time.

You can read more on this subject in the article titled What Are We Estimating, Anyway?)

The other theory of relativity

This excerpt from the Kindle pocket guide, Practical Estimation, discusses how we can leverage our ability to compare similar things to help create reliable project schedules.

The Most Accurate Estimates You’ll Ever Get

Here’s a formula for getting estimates that are 100% accurate:

  • First, do all the work
  • See how long it took to do the work
  • Make that your estimate

This simple formula works every time, but it’s not especially useful because it provides no predictability, only information after the fact. A valuable principle, however, is contained in that formula, and that principle is this:

Knowing how long it took to do some actual work can be useful in determining how long it will take to do similar work in the future.

Phrased this way, the principle just sounds like common sense, but there’s a wrinkle. How do we gauge similarity? And what if we haven’t done any “similar work” in the past?

If you’ve ever taken your car to the shop for repair, you’re probably familiar with this principle in actual practice. Repair shops have a guide in which they can look up standardized labor times, allowing them to quote labor costs for just about any repair or part replacement. Those labor times were likely arrived at by measuring and averaging how long each repair actually took some person or people to perform.

In the software development world, things are not so straightforward. I’ve yet to see or hear about any standardized lists of development times for tasks that developers perform. Why is that? Perhaps because software development is a process of discovery more than it is one of engineering—in software we’re always trying to discover (a) what to build and (b) how to build it. There are at least as many ways of developing a piece of software as there are people to develop it. I say “at least as many” because each software developer is capable of coming up with more than one way to develop any particular piece of software. It’s a field filled with choices.

So how do we apply the principle stated above to the world of software development? One approach is to see how long it takes to do only part of the work, and apply that information to work yet to be done. That makes the formula look something like this:

  • First, do some of the work
  • See how long it took to do the work
  • Use that information to inform future estimates

That sounds fine, as far as it goes, but it still doesn’t quite address the need to compare future work with past work. In the repair shop example, we have a guide that (theoretically) contains labor times for all conceivable repairs, based on someone actually having performed those repairs in the past. All we need to know is what repair we want to perform, and we can look up a standardized labor time in the guide.

But no such guide exists in software development. Each new software product has its own unique set of components and component relationships. From a certain perspective, all software is custom software, making it impractical to create a standardized guide.

Fortunately there still remains an aspect of software that we can use for making useful comparisons, and that aspect is relative development time.

What Makes Relative Estimation Work?

Relative estimation seems to yield better results owing to the theory that human beings are much better at it than they are at absolute estimation.

For example, I may not be able to tell you how tall two adjacent buildings are, but I can certainly tell you if one is taller than the other. I can even estimate, for example, that one building is a third taller than the other.

I may not know off the top of my head how long it will take to get to the grocery store, but I know it will be longer than it takes me to get to the gas station. I can even estimate that going to the store will take, say, twice as long as going to the gas station.

These are examples of relative estimates, which are expressions of one thing compared to another, similar thing.

The same principle can be employed when estimating software development tasks. For example, I might estimate that developing a feature to allow user registration for a web service will take fifty percent longer than a feature that allows the user to log in. I may not know how long (in absolute terms) each feature will take, but I feel pretty comfortable saying that one will take longer than the other, and by about how much.

All I need to do to get an idea of when both of those features will be completed is to develop one of them, see how long that took, then apply that information to the other feature.

It is fairly common to express the relative estimates for such features in abstract units or “points.”

Velocity

At some point, which typically is before you answer your manager’s query about when a project will be completed, you’ll want to convert your abstract (point) estimates to calendar time.

This conversion takes place through the use of a conversion factor that has come to be called velocity.

Velocity says how many points of work were completed in a specific amount of calendar time, so will be expressed in something like points per week or points per sprint (for Scrum teams).

To arrive at actual velocity, you’ll have to do some actual work. Let’s say that you and your team complete 50 points worth of tasks in a week-long period. That would make your velocity equal to 50 points/week.

To predict a project completion date, divide the number of points remaining in the project by your velocity. If, for example, there are 450 points worth of tasks remaining in your project, it will take about 9 weeks (450/50) to complete the project.

You can read more about velocity in the article titled Velocity—it ain’t what it sounds like.

Estimation values: near-Fibonacci vs. true Fibonacci

This excerpt from the Kindle pocket guide, Practical Estimation, discusses the relative merits of using the familiar “near Fibonacci” sequence vs. the true Fibonacci sequence for estimating work effort.

Fibonacci Numbers

Estimates are educated guesses. They are predictions based on past information, therefore we cannot expect them to have a lot of precision. If I spend time agonizing over deciding whether a task is either, say, 50% or 51% larger than another task, I am probably wasting time. Any individual estimate, being an educated guess, is not going to be correct with that kind of precision. Sometimes an individual estimate will be too large and other times too small. We can, given a number of samples, expect these anomalies to cancel each other out over time, yielding fairly reliable predictability of schedule.

We can limit the amount of precision that our estimates imply by using numbers from sets that are not contiguous. The Fibonacci sequence is an example of one of those sets.

A number in the Fibonacci sequence is created by summing the prior two numbers. Starting with zero, the sequence is:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, …

The extra “1″ is unnecessary, so we can ignore it. Likewise, some may find that the “0″ is superfluous.

The Fibonacci sequence is handy for several reasons:

  • The formula to generate the sequence is easy to remember and perform.
  • The gaps between numbers grow as the numbers get larger, and can be thought of as representing the “uncertainty” of an estimate.
  • Throughout the sequence, the numbers grow at a rate that makes it possible to represent useful relationships such as (roughly) one-and-a-halftwicethree times larger, etc.

Near-Fibonacci vs. True Fibonacci

Some teams use what might be called a near-Fibonacci sequence, which looks like:

1, 2, 3, 5, 8, 13, 20, 40, 100

Notice that this sequence differs from the true Fibonacci sequence after 13. Early on, when I first started practicing relative estimation, I was encouraged to use this “near” sequence, and to think of the smaller numbers (1-13) as being the proper sizes for work items. Anything larger than a 13 was assumed to need decomposition into smaller items.

But tying a specific range of numbers to a specific block of calendar time can have the unfortunate side effect of causing team members to mentally (and unconsciously) map individual estimates to absolute time. When that happens, estimates become little more than alternate representations of calendar time, an unnecessary complication. We might just as well have estimated in hours (which we’re not especially good at).

I like to use the true Fibonacci sequence because it allows expression of relationships between work items of all durations. Using numbers from this larger sequence enables quick, up-front estimation of entire projects, even when its components have not necessarily been broken down into work-sized items.

I also favor the true Fibonacci sequence for its re-scalability. If, for example, I initially estimate a work item as a “1″, then eventually encounter other work items that are smaller, I can re-label any existing work items so that my “1″ becomes a “13″ and then I have all of the smaller numbers (1,  2, 3, 5, 8) to work within. In other words, I can make all of my estimates consistent relative to each other, regardless of size, because there is no upper bound to the sequence.

Another way to think about this is to consider the idea that the following two sequences are roughly equivalent to each other:

1, 2, 3, 5, 8

13, 21, 34, 55, 89

If you’re doing relative estimation, since all you’re really interested in are the ratios of the numbers (and not the absolute values of the numbers), then you should be able to use the above two sequences interchangeably. For example 2:1 is roughly equal to 21:13; likewise 3:2 is roughly equivalent to 34:21 (given a level of precision that is appropriate for estimates).

See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”

Are you really doing relative estimation?

This excerpt from the Kindle pocket guide, Practical Estimation, discusses how estimating with abstract units does not necessarily mean that you are doing relative estimation.  

Traditional Absolute Estimation

As a software developer, I may not really know how long in absolute terms (e.g. hours, days) a particular piece of software will take to develop. If you are a software developer, it is likely that you have experienced this first-hand.

Manager: “How long is this project going to take?”
Developer: “Three months.”

That exchange is an example of absolute estimation. One person has asked for an estimate in terms of calendar time, and another has responded in kind. Nothing wrong with that, on the surface—it is perfectly natural for the developer to answer a question the way it was asked. A difficulty arises, however, if the developer doesn’t yet have sufficient information to answer the question, but answers it anyway just because it was asked.

Early on in my own career, I did software development work on a fixed-price contract basis. That could be a tough game because if I didn’t bid a contract appropriately, I ended up making less (sometimes a lot less) money for the time spent. Working as a programmer making minimum wage wasn’t a career goal, so I had a very good reason to get good at estimating.

Here’s the basic technique I used:

  • Break down the work assigned into as many small tasks as I could think of
  • Estimate each of those tasks, in hours
  • Add up the task estimates
  • Pad the sum of estimates by 50 to 100% to account for unforeseen work
  • Present the estimate to my manager
  • Resist my manager’s attempt to negotiate the estimate downward
  • Do the work, which would take more time than either of us had imagined

I hoped that repeating the above process on each new contract would eventually help me get better at the estimation part, but it never really did, even though I was highly motivated. (Later on I overheard my manager telling someone that he usually took my estimates and doubled them in order to get an idea of schedule.)

I never really got good at this kind of direct, absolute estimation, and it wasn’t until many years later that I learned another way.

Relative Estimation vs Absolute Estimation

Manager: “How long is this project going to take?”
Developer: “The project has been estimated at 720 points, and we’re currently averaging 60 points per week, so 12 weeks.”

That conversation is an example of the ultimate use of relative estimation. Even though the manager has asked for an estimate in terms of calendar (absolute) time, the developer has responded, at least initially, in terms of some different, abstract units called “points,” then performed a quick calculation to convert those points to something the manager can use.

The assumption here is that the project in question consists of a number of individual development tasks, that each of them has been assigned its own estimate (in points), and that those have been added together to arrive at a single estimate for the entire project.

Relative estimation also necessarily implies indirect estimation, meaning that estimates are expressed in some abstract units, such as the points described above. This doesn’t work both ways, however. Using abstract units does not necessarily mean that you are doing relative estimation. It’s entirely possible (and fairly common) for development teams to engage in what might be called indirect, absolute estimation. This occurs when point values are merely substituted for their absolute equivalents.

I’ve worked on and with several development teams that believed themselves to be practicing relative estimation, but who were actually performing indirect, absolute estimation. The telltale sign in every case was that team members mentally mapped point values to calendar values while estimating. The typical thought process was something like, “Well, I think this task will take a full day to complete, and 1 point equals half a day, so this task is 2 points.”

So it’s possible to estimate in abstract units while actually engaging in absolute estimation. This is not especially useful, in that it adds an unnecessary level of indirection to the estimation process, which is no better than estimating directly in absolute units (e.g. hours, days).

Telltale Signs of Absolute Estimation

Relative estimation is always done using abstract units, so it’s easy to believe that, if you’re estimating in abstract units, you’re doing relative estimation. But units alone aren’t enough of an indicator—it’s entirely possible to estimate using abstract units (e.g. points) while still only doing absolute estimation.

Here are some ways to know if you’re just doing absolute estimation:

  • Relative estimation relies on comparison, therefore it requires at least two items (task, features, etc.) to work properly. If you find yourself assigning point values to individual items, without comparing them to other items, then you’re probably engaging in indirect, absolute estimation.
  • If, when you’re estimating, you find yourself thinking of point values as mapping to a specific amount of clock or calendar time (e.g. 1 point = 4 hours), you’re probably engaging in indirect, absolute estimation. At estimation time, estimates should be thought of as relative to each other, not mapped to clock or calendar time.
  • If you find it necessary to introduce new values (such as “½”) into the Fibonacci sequence in order to make some estimates fit, you’re probably engaging in indirect, absolute estimation. The ”½” that is sometimes used in estimation sessions to indicate a small effort is a clear sign of mapping points to clock or calendar time. In true relative estimation, you can simply re-scale your estimates to make room for a smaller estimate.

See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”

 

Velocity—it ain’t what it sounds like

In the physical world, velocity is a common and well-understood term. In the world of Agile software development, “velocity” means something that, at first glance, seems similar to the physical world meaning, but which is in fact different in an important way.

Velocity in the physical world

Anyone who drives a car is intuitively familiar with the meaning of velocity. It means speed, and is commonly expressed in miles or kilometers per hour. A slightly more abstract expression would be some distance per some unit of time. An even more generic way to say that is the ratio of benefit to time (benefit/time).

In the physical world, whether from the point of view of a commuter, a cabbie or a race-car driver, increased velocity means increased value—in more technical terms, that’s an increase in the benefit/cost ratio. In these cases, the benefit is miles traveled. Time taken is the cost.

To the commuter, traveling a fixed number of miles in less time provides increased value by lowering the time required to get to or from work.

To the cabbie, who effectively gets paid by the mile, covering more miles in a shift provides greater value.

To the race-car driver, winning the race has more value than coming in second.

Velocity in Agile software development

People engaged in Agile software development also use the term “velocity” and, probably because of the physical world meaning of the term, can be inclined to believe that increasing velocity means increasing value (or benefit/time), just like it does in the physical world.

Velocity in software development is typically expressed in terms of (story) points per iteration. At first glance this seems very velocity-like—something delivered in some period of time. But a closer look at what is being delivered reveals something interesting.

Story points don’t represent benefit

Many agile teams use relative estimation in one form or another to project how much time it will take to develop various functional bits (user stories) in a product. It’s common to assign a number of points to each story being estimated. In relative estimation, when we estimate a story at 3 points, for example, we’re saying that we believe it will take 3 times the amount of time to develop that story as a story estimated at 1 point.

So let’s say that we work in 1-week iterations, and at the end of a week we total up the estimated points for all the stories we completed that week and find that we completed 25 points worth of stories. We call that total our “velocity” and we use that velocity figure (25 points per week) both to project future completion dates and to determine how much work we think we can do next week.

But what we call “velocity” in software development isn’t like velocity in the physical world, in that points don’t represent a benefit. At best, what we call “velocity” is actually only a ratio of relative time to absolute time. It’s a useful ratio, to be sure, but only so far as it lets us make calculations that convert our estimates to actual (calendar) time. Multiplying “velocity” by the number of weeks remaining until a deadline tells us how many points worth of stories we can expect to complete. Dividing the total number of story points in our backlog by “velocity” yields the number of weeks remaining until anticipated completion.

What we call “velocity” in software development doesn’t represent a benefit/time ratio like it does in the physical world. The largest implication of this is that increasing velocity does not necessarily translate to increasing value.

What’s in a name?

It’s important what we call things. The term “velocity” is certainly more convenient than something like “relative to absolute time factor” but it can mislead if not well understood.

Have you been in a situation where you’ve been encouraged to “increase your velocity”? It’s almost certain that the person doing the encouraging was really asking for you to go faster—to increase the benefits delivered in a certain amount of time.

In hindsight, it would probably have been better to use the term “velocity” to describe a benefit/cost ratio, like it does in the physical world. One of the easiest benefits to understand, at least in a for-profit company, is revenue. Revenue is a benefit, and time is a cost, so revenue/time is a reasonable way to express velocity. Or would be, if the term didn’t already have an accepted meaning.

We may have to live with the term “velocity” to describe what is actually only a “time factor.” After all, we’ve got roughly a decade’s worth of inertia supporting this now-traditional usage.

But we can at least be aware, and strive to make others aware, that increasing velocity isn’t something to aim for. Try increasing value instead.

 

Estimating for the bottleneck

Your Agile team may employ an estimation technique that requires the participation of all team members. But this kind of all-hands involvement is completely unnecessary if you know where your bottleneck is.

Finding the bottleneck

If you can picture your development process as a chain of dependent operations that are performed in sequence (e.g. development, testing, deployment), then one of those operations will be your bottleneck. And just so we’re clear about what is meant by “bottleneck”, here’s a working definition:

A bottleneck is any resource with no spare capacity.

In other words, one of the operations in your development chain is going to set the pace—to determine the rate at which work items are completed. Find the operation whose throughput matches the throughput of the entire chain, and you’ve pegged your bottleneck.

All-hands estimation is unnecessary

Conventional estimation sessions, even within the Agile community, include input from all team members. It’s common to see teams arriving at an estimate for a given unit of work (e.g. user story, backlog item) by summing the anticipated efforts of each operation. (Development will take 3 days and testing will take 2 days, therefore the final estimate is 5 days.)

The problem with the above scenario is that it assumes that no work is done in parallel, which is rarely the case. In reality, development and testing will be occurring simultaneously most of the time, and the production rate of the bottleneck operation will determine the production rate of the entire chain.

When all operations in the chain are working in parallel, and assuming that there are many units of work to be done, then the time to complete a given unit of work is determined solely by the time it spends at the bottleneck operation. Therefore, in the above scenario, the time to complete the unit of work will be closer to 3 days than to 5.

This means that there’s really no need to involve the entire team to arrive at estimates. Getting estimates from team members involved in the bottleneck operation only will yield appropriate results.

What if we can’t find our bottleneck?

I often hear teams reporting that they have multiple bottlenecks, or that the bottleneck jumps from operation to operation, making it difficult to “estimate for the bottleneck.” If this appears to be the case in your development chain, then you’re most likely observing BINOs (Bottlenecks In Name Only). In any give chain of dependent operations, there will be one true bottleneck. There are several techniques for revealing where it is:

  • Observing Inventory Buildup – Find the operation that has the largest growing volume of work to be done.
  • Matching Cycle Times – Find the operation whose cycle time matches the cycle time of the entire chain.
  • Assignment – Where two or more operations have similar production rates, choose the one you wish to set the pace for the entire chain.

Note

Although the example above talks about estimating in absolute time (days), I highly recommend estimating in relative time (points). We’re generally not very good at estimating in absolute terms, but can be quite adept at relative estimation (e.g. unit of work A will take about twice the time as unit of work B).

See my previous article, What are we estimating, anyway?

 

 

That bottleneck may be right where you want it

Mere mention of the word “bottleneck” is often enough to generate a flurry of proposals on ways to eliminate it. But every system has a bottleneck, and yours may be right where you want it.

A useful definition

Examples of bottlenecks, both at work and out in the world, abound. Work piles up on the desk of a co-worker who is out sick. Traffic comes to a standstill on the freeway while driving to and from work. (The most common one in my commute is a particular spot on Highway 101 north of Novato where three lanes turn into two.)

But some things that we think of as bottlenecks, aren’t. In a work environment, it’s common for people to label anyone or anything that is preventing them from starting their own next work task as a bottleneck.

A more useful definition of bottleneck comes from The Goal by Eliyahu M. Goldratt:

“A bottleneck is any resource whose capacity is equal to or less than the demand placed on it.”

That’s a powerful statement. And it’s the “equal to” part that I find the most interesting. If you turn the definition on its head, you can express it as:

A bottleneck is any resource with no spare capacity.

The bottleneck is a pacesetter

It’s convenient to think of a software development environment as a chain of dependent operations (e.g. requirements gathering, design, development, testing, deployment).

The bottleneck in your software development environment is the operation with no spare capacity with respect to the demand on your chain of development operations as a whole. If you measure the rate at which finished product is leaving the end of the chain, you can identify the bottleneck by finding the operation whose production rate matches the system’s rate.

In other words, the bottleneck operation sets the pace of production for the entire system. And that’s why I find it useful to refer to a true bottleneck as a pacesetter.

Deciding whether or not to eliminate a bottleneck

Your system is going to have a bottleneck somewhere, and fixing a bottleneck at one operation will have the effect of moving it to some other operation. You only want to move a bottleneck if you don’t like it where it is.

So how do you know if your bottleneck is in the right place? Just take a look at the rate of production of your development environment as a whole. If delivery of finished product (e.g. features, user stories, or whatever units of work you use) is keeping up with demand, you’ll likely want to leave the bottleneck where it is.

And how do you assess demand? In a software development environment, demand might be determined by your marketing organization (i.e. “We need to have features A, B and C delivered by the end of March”).

A bottleneck side-effect

A development environment that is keeping up with demand, and that has a well-managed bottleneck, will also exhibit what is often perceived as an undesirable trait: Not every operation in the development chain will be occupied 100% of the time. In other words, some people are going to appear as if they’re not working at least part of the time.

But this is intentional. If the bottleneck is the pacesetter for the entire system, then all of the non-bottlenecks will, by definition, have spare capacity which can be used, when appropriate, to make sure that the pacesetter operation is never starved for work.

 

 

Grow your own best practices

Development organizations are often concerned with finding out what “best practices” they should employ to help ensure a successful product. But practices don’t always transplant well. Rather than adopting someone else’s practices, you might want to derive your own from basic principles.

The bowling story

Many years ago I took my younger daughter to the bowling alley for an afternoon of fun. I hadn’t been to this particular bowling alley before, so was unfamiliar with their policy regarding shoe rental.

When I asked the young lady behind the desk for a lane and shoes, she responded, rapid fire with, “I-need-a-shoe-size-and-a-shoe.” It sounded like all one word.

I didn’t understand what she had said, so I asked her to repeat it. Again she said, “I-need-a-shoe-size-and-a-shoe.” This time I caught the words “shoe size,” so I replied, “Ten and a half.”

She plopped a pair of size ten-and-a half bowling shoes on the counter, then said, “And a shoe.”

I was puzzled. “What?” I asked her.

She repeated, “And a shoe.”

“I don’t know what you mean,” I replied.

“I need one of your shoes.”

“Why?” I asked.

Instead of answering me, she pointed to a sign on the front of the counter which said something to the effect that customers are required to leave one of their shoes at the front desk at the time of bowling shoe rental.

I looked back at the young lady (who was probably already tired of dealing with me) and said, “That’s not why, that’s what.”

A few moments of awkward silence told me that she was disinclined to explain further, so I gave her one of my street shoes, collected the bowling shoes, and walked toward the lane she had assigned us, a little off-balance, one shoe off and one shoe on. (Diddle diddle dumpling, my son John…)

Bowling alley policy – principle vs practice

By pointing to the policy statement, the young lady was indicating the bowling alley’s practice regarding shoe rental. That told me the what, but not the why. By the time I arrived at my assigned lane, I was able to infer the why, which likely had something to do with people literally walking off with bowling shoes. (A quick conference with my daughter tended to confirm this hypothesis. She told me that a number of her friends occasionally wore bowling shoes to school.)

Thus I was able to infer the principle involved, which might be expressed as “some customers will steal our property unless we hold onto something of theirs that they value more than our property.”

Practices may not transplant well

Now let’s suppose that the owner of another business, say a miniature golf course, decided to enact a similar policy (after, perhaps, speaking to the bowling alley owner who expressed that theft was all but eliminated after implementing the “shoe policy.”)

And let’s further suppose that the miniature golf owner hopefully and enthusiastically has a sign made up and displayed prominently, stating that all people playing miniature golf must leave one of their shoes at the counter, hoping to eliminate theft of the occasional putter.

You can imagine the results. Rather than reducing theft, this policy will likely have the effect of reducing revenue, by thinning the golf course’s customer base down to those who enjoy playing minus a shoe.

And, of course, no reasonable person would actually implement a policy that was as ill-fitting as this. The mismatch is too obvious. Instead the owner of the miniature golf course is likely to infer a principle from the bowling alley practice, then implement a similar practice appropriate to the miniature golf business, perhaps something like all people playing miniature golf must leave a small cash deposit at the counter.

Principle vs practice in a development environment

Development (and especially software development) organizations seem to like the idea of finding and applying what they call best practices. I’m not aware of any common agreement on what “best” means, but in my experience it almost always involves “something that someone else is doing.”

And while the differences between software development organizations may not be as glaringly obvious as those between a bowling alley and a miniature golf course, suffice it to say that differences (e.g. size, experience level, customer type, product type, etc.) do exist.

Pair programming is one example of a development practice that’s been around for a while now. In pair programming, as the name suggests, two developers work side by side, on the same code at a single computer. Proponents of pair programming cite increased quality, better design and instantaneous code review as some of its benefits.

I’ve worked on several projects where attempts to implement pair programming were made. Some worked well. Others, not so much. Generally speaking, I’d say that the unsuccessful cases occurred due to social, rather than technical, reasons. In all instances, everyone attempting the practice was technically skilled. But personality or style mismatches sometimes got in the way, making pair programming something other than a best practice in those cases.

Looking at principles rather than practices might have been helpful. So what principles might we have been able to infer? These come to mind:

  • Having more than one person review code will decrease the defect rate.
  • Code that is understandable to more than one person is more maintainable, and therefore less costly to the organization.
  • Simpler designs result from collaboration

From the principles listed above, can you derive some practices that fit the unique composition and characteristics of your organization? I’m guessing that you can. What are they? I can’t say—I’m not in your organization. The practices that you come up with are based on generally applicable principles, but the specifics of those practices are highly dependent on your particular work environment. (In other words, you’ll have to figure them out for yourself.)

I’m interested to hear what you come up with. Are there specific practices you can derive from the principles listed above that would serve you better than pair programming? Please feel free to comment.

 

What are we estimating, anyway?

Several schools of thought exist regarding the proper units to use when estimating work effort, especially on Agile teams. This article addresses what just may be “the simplest units that could possibly work” when estimating in order to provide predictability of development schedule.

When I first encountered what was called “Agile estimating” in 2004 or so, it was common to hear people talk about estimating user stories in terms of “size.” The emphasis was not on how long a user story would take, but rather on how big a story was. This seemed like a reasonable viewpoint, as it tended to de-emphasize duration, something that experience told me I’m not very good at assessing. (I tended to be overly optimistic.)

But as I attempted to put this emphasis on size into practice, I discovered that it was difficult to explain what “size” meant. I thought I had a grasp of it myself, but was generally unable to articulate what I meant by “size” to others on my team, and with whom I needed to engage in estimation activities. Often the best I could do was to define size in terms of what is was not (e.g. “it’s not duration” or “it’s not time, it’s size“).

Not satisfied with the inability to communicate clearly about this, I began thinking of and explaining “size” in terms of relative complexity. This was somewhat more satisfying, as the concept was easier to communicate, and my teammates and I seemed to be able to talk about this and use it. We decided that “less complexity” could be equated to “having fewer parts” and that “more complexity” meant “having more parts.”

This was fine as far as it went, but there were still some issues. It sometimes turned out that stories of supposedly equal complexity took substantially different amounts of time to complete, making the predicting of schedules less reliable. Order of story development played a part here. When two equally complex stories shared some underlying infrastructure, the first story to be developed would take longer than the second.

Some time later, I learned of other teams estimating in terms of what they called “effort.” This had a certain appeal, but seemed to raise old issues. Coming to agreement on what was meant by “effort” felt about the same as agreeing about the meaning of “size.” Effort is a slippery term, as it can refer to not only how long something will take, but also the ease with which that thing is accomplished. In other words, a user story that is easy (i.e. enjoyable) to work on may seem almost effortless, yet take more time to complete than a story that is difficult (i.e boring).

It could very well be that the appeal in using any of the above units, (size, complexity or effort) lies in our desire to avoid talking about estimates in terms of time. Perhaps we’ve convinced ourselves that we shouldn’t be talking about time, but about something (anything) else when estimating work effort.

But we should also remember why we’re estimating in the first place. If we’re estimating to provide predictability of schedule, then time is what we’re interested in. I’ll go so far as to state that while we’re not generally very good at estimating in terms absolute time, we’re much more adept at estimating in terms of relative time. (e.g. “I don’t know how long stories A and B will take to develop, but I do know that story A will take about twice as long as story B.”)

Given a choice of all the units described above, relative time may be “the simplest units that could possibly work.” They’re certainly more closely related to what we really want to know (absolute time), and they avoid the ambiguities that seem to be inherent in the other units.

Getting started

I’ve been learning about Agile, and employing its principles and practices, for a while now.

I was introduced to some of the tenets of eXtreme Programming (XP) in 2000 by a co-worker at a software development company. I liked what I saw, but didn’t get a chance to apply it much at the time. My next opportunity came in 2005, when I got involved in another software development effort that started out in the traditional “waterfall” fashion with a good-sized design document, but changed over to an Agile approach because we all knew that the requirements for the product being built were going to be changing constantly.

My personal discovery of Agile principles and practices renewed my interest in software development (in which I had been involved since 1977). Agile held a promise that I could actually be part of creating some fairly large software systems without them becoming inflexible and unmanageable with growth.

As I learned more, I began to realize something that many others almost certainly know: This Agile stuff has much broader application than just in the world of software. So I adopted a broader viewpoint, and began thinking in terms applying Agile principles and practices to productivity in general.

I’m a big fan of Eliyahu Goldratt’s Theory of Constraints, and find myself reading and re-reading his body of work. I like Goldratt’s clear and concise definition of productivity, and use it myself in practically everything I do work-wise.

Eventually I began training and coaching other people in Agile principles and practices, and developing hands-on exercises that help get the basic ideas across. I’m still doing that today, and intend to keep on doing it, hoping to reach larger and larger audiences.

I’m also hoping that this blog will serve to promote the exchange of ideas between myself an other enthusiasts out there. Please feel free to join the conversation.