The mindset behind estimating and planning for agile

Abstract

From the industrial age until now, the nature of the work being performed in modern societies has totally changed in nature. Unfortunately and far too pervasively, work's estimators have not adapted.

In this paper, we aim to make project teams aware of not only optimal techniques but also the tendency to abandon them in the heat of their work without even realizing it. Without some form of reasonable estimation, much modern work would be too risky even to attempt. Failing projects commonly have poor estimation as a root cause. Only with serviceable estimates can effective budgeting and feature selection and trades be made.

We give clarity to this problem and its origins and propose solutions by examining two primary work types, knowledge work and task work, and address the issue of projects that incorporate both types. We present the key related concepts of continuous estimation, estimation in size versus time, and relative versus absolute estimation. We illustrate the value of each when applied to knowledge work.

Even when these types of estimation are done well initially, constant diligence is necessary to maintain the discipline of their application, a discipline too often lost. Without it, many projects are at serious risk of cancellation or failure.

The Purposes of Estimation

Estimation is an indispensable element of project work. The end result is a concept of the effort required to do each work element, which can be translated into financial terms for project-feasibility determination and resource-allocation projections. However, when done well, a much overlooked and invaluable benefit is the (perhaps forced) discussions that result in greater understanding of the work at hand. Fortunately, the same techniques invaluable in producing great estimates also encourage collaboration and understanding.

Although lean thinking considers estimating wasteful, in the authors opinion the approach used there is perfectly in synchronization with the agile movement's estimations in relative terms, which are then adjusted to the actual rate of work progress.

Vital Distinctions Between Types of Work

Cost overruns continue to plague industry with serious and sometimes fatal results for the sponsoring organization, the particular project, or perhaps the current career of the project manager. To get to the root of many of today's work challenges, we must begin with the realization that not all work is the same. Let's distinguish between two types of work that must be treated and estimated very differently: knowledge work and task work. Our primary focus is on the knowledge work that makes up the bulk of current project work as opposed to product work.

Knowledge work is work that usually requires “thinking.” Knowledge workers are considered people who “think for a living.” For example, doctors, lawyers, software developers, engineers, teachers, nurses, financial analysts, and architects perform non-routine tasks that require some level of thinking and creativity. As businesses have increased their dependence on information technology, the number of fields in which knowledge workers are necessary has increased dramatically.

The key differentiator between knowledge work and task work is its primary core of non-routine problem solving that requires a combination of convergent, divergent, and creative thinking.

The Management of Knowledge Work

The traditional plan-based approach to work isn't flawed in and of itself; it just isn't suitable for managing knowledge work. In the task-work-based construction industry, the plan-based approach is suitable. The blueprints, which are the requirements, are fixed and probably won't change substantially while the building is being built. Therefore one can estimate how long it will take to build the steel pillars, pour the concrete, and so forth. The reason why the traditional plan-based approach is suitable for the construction industry but not a knowledge industry like the software industry comes back to the difference between the way we control the process of doing knowledge work versus the way we control the process of doing task work.

There are two major approaches to controlling any process:

• The defined process control model
• The empirical process control model

The defined process control model requires that every piece of work be completely understood. Given a well-defined set of inputs, the same outputs are generated every time. A defined process can be started and allowed to run until completion, and it will always produce the same results. The defined process control model provides and exercises control through planning, coordination, and control. The defined process control model is usually suitable when:

• No creativity or “new thought” is needed during execution;
• There are mostly predictable actors that you can coordinate and control; and
• It is possible to identify, define, schedule, and order all the detailed activities.

The empirical process control model, on the other hand, is suitable for processes that are imperfectly defined and that generate unpredictable and unrepeatable outputs. An empirical process cannot be rehearsed but will provide a great deal of learning, experience, and discovery that may or may not be relevant the next time the process is executed. The empirical process control model provides and exercises control through frequent inspection and adaptation. The empirical process control model is usually suitable when:

• Creativity and “new thought” are needed during execution;
• There are mostly unpredictable actors that you cannot coordinate or control; and
• Execution cannot be planned in detail but rather by inspection and adaptation.

For many years, the majority of people involved in knowledge work have based their control model on the defined process. But any form of knowledge work doesn't necessarily generate the same output every time given a certain input. Creativity and the human thought process are unpredictable by nature.

Agility Is the Key to Managing Knowledge Work

The modern concept of agility is based on the empirical process control model of “inspect and adapt.” In contrast, more defined, less creative, and less dynamic processes are suited to the “coordination and control” style appropriate for construction and manufacturing.

Knowledge work or inherently creative empirical processes work much better with an “inspect and adapt” management approach. This approach encourages learning and shorter cycle times with quickly incorporated feedback for continuous improvement and delivery of greater value.

A group of authors wrote a document called the Manifesto for Agile Software Development (Beck, et al., 2001). Their goal was to identify the values that yield the most benefit to a software development process. Agile has become a very hot topic in the software-development industry. However, its core mindset, values, and principles can be expanded far beyond software into the more general realm of all knowledge work. Indeed, this is exactly what is happening and happening quickly. From that single origin the movement is finding rapid adoption in the entire realm of project management. As we know, everything in life is a project.

The essence of the agile mindset's values and principles revolves around several key concepts. Three of them are particularly relevant to this paper:

1. You can't predict or control the circumstances (including the human creative thought process) as you build your output.
2. You must deal with knowledge work differently than you deal with task work.
3. The output of knowledge work is not knowable in advance and therefore planning and estimating need to be approached in a different manner.

The ability to estimate a project is strongly affected by these three issues, raising the following question. If you can neither predict nor control the ensuing project circumstances beyond the acknowledgment that significant change is inevitable, how can you plan and estimate? Furthermore, what constitutes good planning and estimating in the first place?

For estimates, the term “serviceable” is useful. In general, it means that something is useful in fulfilling its current purpose. Evolving estimates do just that, being the best that can be known at the time.

While even the most chaotic processes could be termed “agile” because they can “turn on a dime,” agility as described in the Manifesto is an approach that is highly disciplined in how it manifests, maintains, and assures its flexibility. That very flexibility is inherently fraught with opportunities for veering off course.

It's surprisingly difficult for practitioners to acknowledge that estimating and planning need to be done differently in order to cope. Let's examine three large pieces of the necessary solution.

Continuous Estimation

A first coping mechanism is to never stop estimating. We talked earlier about the difference between defined and empirical processes. As we start discussing estimation in empirical processes, an analogy helps explain this point in better detail. We are assuming that most of those reading this have used a Global Positioning System (GPS) device at least once before.

Even though driving is a creative process or a form of knowledge work per se, it is managed using an empirical process because you can't coordinate or control the circumstances around you. If you somehow had the ability to control all the traffic lights, weather, and other drivers, it would be a defined process. That, of course, is not the case.

When it comes to estimation and driving, you enter your destination into the GPS, and using the most sophisticated estimation techniques it gives you an estimated time of arrival. Even though the best estimation techniques available are in use, as soon as you start driving the GPS will likely soon change its estimate based on the current driving and traffic conditions. If the GPS were an employee in the corporate world, it might very well have been fired because it failed in its upfront estimate and perhaps miserably so. The whole point of this analogy is that, similar to how a GPS can only give its best estimate upfront based on what it knows, estimations for knowledge-work projects encounter the same exact challenges. Even if you give the best estimate upfront, you need to continuously re-estimate because the circumstances are always changing and there is nothing you can do to control that.

Some examples are in order. If the creative juices of the developers or testers aren't flowing freely during the design phase, how are you going to control that? The answer, of course, is that you can't. If suddenly two or three of your developers become sick, how are you going to control that? Buffering doesn't really help because these events are unpredictable. Buffering is most effective when you know that something is predictable and there are chances of this happening. You can buffer for three developers getting sick twice on the project, but who can really say that is what will happen? So just like a GPS re-calculates based on new information, knowledge-work environments should too. That is not to say that you won't have an initial estimate. Just like the GPS, you produce your best estimate knowing that you will almost certainly need to change it.

The biggest challenge here is the pervasive accountability culture that corporations have regarding estimates, deeming that once an estimate is set it is final and people are held accountable to it. That is exactly like telling your GPS that once it gives you an estimated time of arrival it must control the uncontrollable so that you reach the destination within the predicted time frame. One of the beautiful tenets of the agile movement is that storypoint estimates are not commitments but rather truly best effort estimates for future refinement. In other words, in a truly agile world, there are no heads in the sand. Another wonderful aspect of all agile estimating is that estimates cover all the work involved in a work element, including design, creation, testing, and acceptance.

Estimation in Size Versus Time

A second and critical coping mechanism is to look at the relative sizes of the work pieces rather than the time required. To illustrate, in our classes we try the following experiment. we ask for a volunteer to guess the height in inches of a certain fellow student. Invariably, the estimates are all over the waterfront, varying by as much as 2 feet or, in percentages, of the order of 33 percent. We then ask another student to stand next to the first student. we ask the same erring estimators which of the two students is taller. Invariably, the answers are 100 percent correct.

The success in this case illustrates the soundness of the correct use of the story point. In some cases, estimators never understand that estimates are supposed to be made in a relative fashion. That is, some tasks are estimated based on initial guesses. Other tasks are estimated based on the perceived effort required, but relative to the initial guesses. Over time, this particular team in this particular environment in this particular project learns to compensate for reality converging on still wrong but increasingly right guesses. Experience with this approach results in increasingly accurate estimates, even though they are still just that—;estimates.

Two common problems occur too often in the application of this very effective approach. In some cases, there is a lack of understanding of the importance of the relative concept in the beginning and the approach is never properly applied. In other cases, that concept is initially agreed to but falls by the wayside as the team drifts back to its old, very human habit of trying to produce absolute estimates.

The folly of absolute time estimation is illustrated by the driving analogy. In a perfect setting, such as 4 a.m. on a Sunday morning, driving to work takes, say, 15 minutes. However, an estimate of 10 miles is more useful because it can be placed in the context of the particular time of day and day of the week in which the driving actually winds up occurring. Relative, continuing estimation therefore places the estimate closer to the context in which the work is actually being done.

Because we must adapt to lots of changing circumstances when doing knowledge work, we need to anchor the estimate in something more stable.

Relative Estimation Versus Absolute Estimation

Early absolute estimation is not only folly but also wasteful because the result is based on incomplete information. Relative estimation involves simpler categorization, with evolving estimates continually improved collectively as experience accumulates.

Agile methodologies offer approaches to facilitate the relative-estimation process. For example, consider affinity estimating. On a larger scale, affinity estimating is especially useful when larger numbers of estimates must be made at the same time, but this approach works perfectly well in smaller samples. Here, typically on a whiteboard with sticky notes, items are place into columns according to estimated effort required, effectively removing from the process attempts at precise estimates. Because items of similar size are grouped together, this method spurs healthy discussion about items that are misplaced.

Beyond the basic practice of relative estimation, various agile techniques are employed to direct thinking further away from absolute terms. Matt Barcomb takes the common estimation categories of S, M, L, XL, and XXL a step further by using woodland creatures of varying sizes, with the creature size representing the degree of challenge (Barcomb, 2011). Creatures increase in size as follows:

• Shrew
• Squirrel
• Badger
• Boar
• Deer
• Bear
• Elk
• Caribou
• Dragon

Such a classification removes the temptation to perform mathematical operations, abstracts the concept of accuracy, and provides much-needed levity. The final dragon category is reserved for those items that are not well understood, are especially challenging, and require special consideration.

A more common technique uses a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) or perhaps a modified Fibonacci sequence (0, 0.5, 1, 2, 3, 5, 8…). These numbers make it more difficult to think in terms of one item being twice the size of another, for example, a degree of precision almost certainly not possible at the initial estimation.

A particularly good extension of these techniques is to blend them with something akin to the Delphi method called planning poker (Wikipedia, 2014). In the Delphi method, participants decide on their own estimates completely independent of each other, removing the effect of particularly dominating group members. In planning poker, members of a group, preferably in the same room, individually decide on a category for each work element. After all have decided, each presents his or her result. Lively discussion is likely to ensue, leading to a better consensus estimate and better team understanding of the group effort ahead. This approach differs from the Delphi method in that group discussion usually occurs first, followed by secret ballots to be discussed shortly thereafter.

For Those Who Simply MUST Think in Time

There are teams that simply refuse to use relative estimation. In these instances, some form of project prophylaxis is essential, such as the inch-pebbles (or miniature milestones) approach (Rothman, 1999). This solution involves much more upfront work, breaking down epic tasks into much smaller chunks that can each be executed in a couple of days. In this case, it must be realized that each “couple of days” task may take one or three days instead. Rothman provides a very good presentation of the technique. If this all sounds familiar, it's because this is the way user stories are normally used. Unfortunately, much extra early work is done breaking down larger elements (perhaps sub-optimally) when the pieces are not yet well understood.

But Is it Really That Simple?

As with all things in life, classification becomes more complicated than one would initially imagine. Upon close examination, it isn't surprising that a given project or effort includes both knowledge work and task work. For instance, in the driving example, in a perfect world with no traffic the effort is almost completely task work. However, the inevitable changes in factors, such as traffic, weather, accidents, mandatory detours, and more, place the effort partially into the realm of knowledge work, where probabilistic decisions can add immense value.

For this reason, even within a single project, each work element must be considered according to its most suitable category as task- or knowledge-oriented or perhaps a blend of the two.

Conclusion

We as humans perform poorly when asked to make absolute estimates, but we excel at relative estimates. Relative estimation is even more valuable when there are more unknowns, triggering discussion and negotiation among the team and the customer. The outcome is more complete understanding and more robust group buy-in of the resulting estimates. The challenge is to avoid slipping back into the abyss of old, familiar, and comfortable tendencies to work in absolute terms.

Regardless of the team's discipline in retaining the relative view, management must understand that the estimates are indeed relative. While past experience can be carried forward into the estimation process, management must be acclimated to the fact that estimates will evolve and should improve over time. Traditional estimating methods simply ignore this reality. Project sponsors should appreciate the fact that the continuous re-estimation that is inherent here is a very positive phenomenon that pays future dividends. Knowledge-work estimates, regardless of industry, are indeed educated guesses that naturally improve with the experience of the guessers within a given project context!

Continued vigilance in the team's application of the three tenets described here can only be assured if the topic is on the agenda at each retrospective, and the rigor of its application is evaluated each time.

As agility becomes ever more pervasive in the efforts of modern endeavor, these techniques, when properly applied, can have an unimaginable impact on the fiscal efficiency of future work and hence societal success. Such an adaptation is long overdue.

© 2014, Dr. Ahmed Sidky and Ameer Gaafar
Originally published as a part of the 2014 PMI Global Congress Proceedings – Dubai, UAE