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:
- You can’t predict or control the circumstances (including the human creative thought process) as you build your output.
- You must deal with knowledge work differently than you deal with task work.
- 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?
Suggested Read: Agile project management with scrum
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.
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.
Also Read: Agile innovation and the project manager
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.