To estimate or not to estimate (that is the question)

Not too long ago I was introduced by Jim Benson to the concept of dropping estimation in favour of measuring cycle time. To me, this was a radical departure. My very being seemed to rebel against the notion (yes, I have been a project manager). And yet the argument against estimation seemed so powerful, so in keeping with my own experience (humans are notoriously bad at estimation, estimates are wilfully interpreted as concrete commitments) that I could not easily dismiss it. The idea of measuring cycle time also appealed strongly to my empirical bent. I was thrown into a state of confusion, of profound cognitive dissonance.

How to facilitate essentials for governance like ROI projections, prioritization etc. if not with estimation?

Shortly thereafter, while reading David Anderson's excellent Kanban, and the account contained therein of how Dragos Dumitriu (@netheart) turned a struggling Ops Dev team around, many of these concerns were addressed. In fact, I wished I had been as smart as Dumitriu in a recent similar engagement of my own. Basically he agreed with his customers that the team would abandon estimation and instead would undertake to complete any piece of work they committed to within a certain time frame. This was possible as existing agreements stated that the team involved should not take on work beyond a certain scope – work of that nature was managed and executed via different channels. Historical data indicated that only 2% of requests made to the team exceeded the agreed-upon scope and it was decided that the team could query work items (by estimating them) if they felt the item in question might exceed the limits specified. Upshot of all this was that the team went from estimating every job that they did, or eventually did not do, to estimating only in exceptional cases. In combination with a couple of other very astute changes this led to a fairly spectacular improvement in the team's performance. I was convinced, nearly...

Part of my ongoing issue with dropping estimation arose from the benefits I had seen Planning Poker deliver - if the team was not estimating, when would the opportunity for high-bandwidth communication on the content of upcoming work arise? What if the team involved had no agreed cap on the scope of work it should take on, very large chunks of work might arrive and clog up their queue. What to do with outliers? How to identify them? How much variance can be tolerated in a queue without detrimentally affecting throughput? And what about batch size, if we are not estimating, how do we know when to split?

Well dear reader, I'm sure you will be glad to know that, thanks to Siddharta's recent post on variance in velocity (and what not to do about it), the alpha waves are humming away harmoniously inside my cranium once again .

I suggest, in the spirit of CALM Alpha, that this seeming conflict between multiple agile methodologies (or their proponents) can be resolved as various approaches to the same problem. The trick is to think in ranges and limits and not absolute numbers. In the Dumitriu example above, estimation was implicit in the agreed scope limit (we estimate that we can get this done in less than X days), Mark Levinson has blogged on related insights (stories < 8 to 13 pts), and Ron Jeffries is proposing a similar approach of late (we estimate story to be sufficiently small to complete in a few days). This is congruent with the complexity heuristic of fine-grained objects.

We can conclude, in agreement with Esther Derby, that estimation can be useful because of the communication that it engenders, but that estimates more accurate than the likes of “needs to be split” and “small enough” have questionable worth. Such aggregated estimates are used for managing batch size and variance (and thus throughput) and not as a stick for beating developers. Thereafter, whether you use velocity or cycle time matters little - prediction remains precarious.

Fighting the good fight (A personal parole)

Recently, Bob Marshall (@flowchainsensei) has raised his lashing of agile and all its manifestations to a frenzy. His language has become ever more dramatic and sensationalist, culminating in a post entitled 'Agile Coaching is Evil'. To understand what the point of all this might be it is essential to read another post of his; 'On the Morality of Dissent'.

If you can peel back the layers of irony and provocation - all this talk of morals and ethics and Good and Evil – then there is certainly value to be discovered in what is being said. I continue however to disagree fundamentally with much of the detail of what Marshall is promulgating, even as I find his stated goals honourable and worthwhile. Yes, I am an agile coach.

I view the three main points of Marshall's argument in 'Agile Coaching is Evil', points that he makes repeatedly over many channels, as:

1. Tackling partial problems leads only to more problems – systems must be addressed holistically otherwise any change will eventually be swallowed up by the system.
2. Effectiveness being a function of mindset implies that significant change can only be realised once a radical and wholesale philosophical shift has been effected
3. Anyone purporting to help an organisation improve its effectiveness by way of local optimisations is at best naïve, probably disingenuous and possibly plain corrupt

Let's start with the holistic systems-thinking argument. It is in fact, easily dismissed:

There is no point in addressing problems in your software development organisation because the organisation around it has not yet changed its mindset (had its mindset changed? brainwashing, hypnosis, how does this happen?), therefore any optimisation achieved within your sw development organisation will eventually be nullified or even reversed by the immovable object of the mindset of the departments adjacent to it in the value chain. Okay. Say we effect mindset shifts in product management, sw development and operations? Not enough - finance, sales, customer service etc, still have not moved so eventually the local optimisation will be swamped by the inertia of the rest of the organisation. And so on until the company has somehow instantaneously leaped the mindset chasm as a single organism. But wait. Then there is the system that is the markets in which the company operates. If said markets haven't changed their mindsets in the meantime the company we have been talking about is doomed, after all, it will eventually succumb to the mindset of the greater system in which it, sub-system, is embedded. Etc., ad infinitum.

There is much of use in systems-thinking, and its focus on people and their empowerment can be found in agile, lean and the Cynefin model (complexity). In all these other cases however there is either the implicit or explicit recognition that everything progresses in small steps. In the case of Cynefin, which specifically addresses complexity and our inability to use reductionism to solve certain problems (initially), it's interesting to note that a heuristic like 'fine-grained objects' is prevalent. Wicked problems are untangled strand by strand. Possibly also interesting to note at this juncture is the fact that much of what one might do in the complex domain in the Cynefin model is aimed at moving problems into the complicated domain. Black-box observation with the specific aim of making reductionist analysis possible!

Regarding mindset shifts as a pre-requisite for increased effectiveness:

I think that Marshall has this exactly wrong. Strangely enough this would seem to be a position he has arrived at since he first published his Marshall Model, sub-titled as it is “Dreyfus for the organisation”. The Dreyfus model of skill acquisition, as with other learning models, implies that insight (mindset) follows practice and not the other way round. In other words, Marshall's insistence that effectiveness follows mindset is in my opinion, the misattribution of cause and effect to an observable correlation. I would posit that mindset is an emergent property of practice. More correctly, practice informs mindset which in turn informs practice – a positive (meaning re-enforcing) feedback loop. There is no conflict here with the observed mindset leaps at the boundaries of the organisation types in Marshall's model. Punctuated equilibrium is not an alternative to gradual change, it is its manifestation in the real world; phase shifts are the result of cumulative change in combination with tipping points.

If Effectiveness = f(Mindeset)
         and Mindest = f(practice)
then Effectiveness = f(practice)

Rightshifting phases - copyright 2010 FallingBlossoms.com

On local optimisations and the nefariousness of their champions:

It is possible to learn without a teacher, in some ways it might even be better (conjecture; one might continue to nourish a beginner's mind more easily), but it is almost certainly the slowest way to learn and autodidacts are often hampered by strategic weak spots in their conceptual armoury. There are of course always bad teachers, in every domain.

In my role as coach, I pursue small modifications in local practice and understanding, while keeping an eye on the bigger picture. Does this make me naïve, disingenuous or corrupt? I can't be accused of naivete precisely because I realise that change, if achieved at all, happens in small steps. Because I communicate exactly this to (prospective) clients, and always start any discussion with an enquiry as to why agile, I am not disingenuous. If my only motivation were my pay cheque I would be corrupt. I am however motivated primarily by the conviction that work for most people is unnecessarily miserable, a drudgery to be survived rather than a fulfilling and rewarding part of life. I feel that the agile manifesto can help and that it is as relevant today as it was ten years ago. The only thing required to make it universally applicable is to replace 'working software' with 'concrete product' (or some such).

I shall continue to try and execute workplace coaching transparently, on the basis of high bandwidth communication, and regularly vetted by concrete results, as a force for good in the world.