quantmleap

Over the past few weeks I’ve been trying to put my head around the #NoEstimates approach. I am not a cynical type of person and I have approached this investigation with open mind and with a view to rationally verifying whether the approach is sufficiently solid to be used in the type of corporate software development domains in which I normally operate.

For an approach, any approach, to be accepted by the mainstream it needs to provide a complete solution. To be taken seriously it needs to address not just an immediate problem but also all connected facets that this problem is associated with. When it comes to the area of estimates – in the software development domain – any proposed alternative needs to address the same type of questions and expectations that the current approach is attempting to deal with.

I have come across two main active proponents for this approach (Woody Zuill and Neil Killick) so I decided to do a sweeping review of their published writing to try and  gauge the completeness and comprehensiveness of their approach.

Both gentlemen agree that at the heart of the drive to obtain or deliver estimates is the need to make decisions. The types of decisions can vary but, most often than not, they will touch on such issues of affordability, about investment strategies, about ROI, etc.

They also agree that while the need to make decisions is a legitimate one, estimates are the wrong tool to enable that process. They therefore suggest that as long as decisions can be made without estimates then estimates can be disposed of as an unnecessary, redundant and useless technique.

This is how Woody sums this up HERE:

…it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,  and maybe we should explore other ways to make those same decisions.

At the heart of the proposed approach lies the following proposition (see in Neil’s post HERE):

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint). Within that constraint the team can then fix incremental delivery dates (e.g. end of every Sprint) to allow focused effort on iterative product evolution (it’s not good to have priorities changing every day on a whim) and provide the opportunity to deliver early and/or under budget. This approach is also useful where there is no concrete budget or delivery date, although the need for interim release dates diminishes if the team (and organisation) is mature enough to have a continuous delivery model.

And a few additional comments from Woody’s blog:

Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here...]

Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.  That is an important point. Dwell on it.

To summarize, given that estimation has ‘built-in’ uncertainty associated with it, this uncertainty can be completely removed by fixing a delivery schedule based on a per-agreed budget and/or time constraint.

So this is my understanding of how this process is proposed to work.

1. The organization allocates fixed amount of $’s and uses these $’s to ‘buy/hire/employ’ a certain number of resources (I am assuming that these resources could be people and assets, as appropriate)
2. The resources are allocated to work on development activities, with the priority being determined by the business value these will deliver.
3. This is progressing in an iterative manner until such time that the allocated funds are exhausted or until such time that a certain milestone, or predetermined date, has been reached – at which case the process ends.

If I was an owner of an organization and someone were to approach me with the above proposition I could decide to take it on. Given the fact that I spend my own money I can certainly decide that this could work for me.

What if I were to spend someone else’s money? Would that change the dynamic of that decision? Let’s explore this question:

When committing other people’s money there is often a requirement for transparency in the decision making process. In this case the following are legitimate questions that person can ask:

1. “why did you decide to spend my money on this product, and what will I get for my money at the end”
2. “I have a number of products I can invest my money on, why should I spend my money on this product at the expense of other products?”

Woody is suggesting the following to mitigate these questions:

There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.

This, on the surface, is not a bad advice but does this approach work for large and complex implementations?

Would you commit many $50M on an enterprise ERP configuration project with the approach that “we will make decisions as we go”? And even on a much smaller scale. You need to make an investment of $2-3M on a new Document Management System using SharePoint. Would you make decisions on the fly given that you need to commit upfront funds  for purchasing the software and the hardware on which it will ultimately reside? Sure, determining what will be developed and allocated to each and every iteration can be done progressively throughout the project, but what about the large and more strategic decision?

While some aspects of the #NoEstimates approach can work, they can only work in very limited and confined circumstances. I suspect that even then they cannot be implemented on large scale software development projects, and they cannot be implemented in organizations where strategic budget allocation is done based on cost benefit and ROI considerations. Until such time that this approach can demonstrate how it would deal with these issues, from my perspective it is busted.

Think about it!

Bob Cravens has a fantastic post about estimation in a software development domain. Contrary to others who attempt to come up with reasons why estimates are a waste of time and cannot be legitimately done, Bob articulates a practical and logical path through which estimates can be done in a sensible and credible way.

Bob suggests the following ‘principles’:

• Estimates require domain knowledge.
• Tasks with a large size (or effort) are harder to estimate than smaller tasks.
• Uncertainty decreases as we gain confidence and understand our abilities.
• Uncertainty continually decreases as we get closer to the finish.

Now, not everything in Bob’s post is to my liking. For instance his comment that “First let’s spend some time discussing how we determine the size of the features we must estimate. We must learn from the past and not fall into the trap of the waterfall development process” is bizarre, to say the least, as it is not clear what trap he is specifically referring to. Does he suggest that the waterfall development process does NOT learn from the past? Do I really need to elaborate why this is non-sense?

Apart from this and perhaps one or two other Agile self-righteousness observations, the principles outlined above are as correct in Agile project as they certainly are in non-Agile projects. The notion that estimation is either not required or alternatively not possible is clearly debunked.

Think about it!

Recently I have been involved in heated debates on Twitter (and also in comments to an earlier post) with proponents of the #NoEstimates approach. They come in different shapes and forms and you have to constantly remind your self that these people are not loonies. They passionately defend their point of view and argue their case with zeal and fervor.

One of the points of contention surrounding the #NoEstimates approach is the claim that there isn’t any difference between estimates and guesses, so much so that the two are synonymous. The offshoot of this idea is that it is better to make decisions without estimates as estimates are just guesses, and making decisions based on guesses is a futile idea. You may as well make a decision and adjust it as new information comes to hand.

For some peculiar reason the support for this notion seems to be coming from those exercising Agile. The rebellion against the ‘old bad ways’ is taking on a new momentum, beyond those chartered in the Agile Manifesto, and is now expanding into new territories. At the center of this crusade lies the notion of uncertainty and how it should be dealt with. As uncertainty is..well, uncertain, what is the point at attempting to fence it with unsubstantiated estimates. Surely they will never be 100% accurate, so why try?

Although, IMHO, this way of thinking is fundamentally flawed it does, nevertheless, have a silver lining that should not be dismissed. It represent a new generation that questions the validity of established practices and wants to explore other, yet to be chartered, ways. That, in itself, is a good thing. Whether the conclusions they arrive at are correct, that’s yet to be seen, but it is great to have the discussion.

Think about it!

The Agile Manifesto states that:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Please review the above (take your time) and then answer the following questions:

1. Does the Manifesto suggest that agile teams cannot be externally managed?

2. Does  the Manifesto suggest that no documentation will be produced?

3. Does the Manifesto suggest that an Agile project should NOT have a plan?

4. Does the Manifesto suggest that work should commence without having a clear end objective in mind?

5. Does the Manifesto suggest that the customer should commit their money without knowing what would sensibly be delivered to them at the end?

6. Does the Manifesto suggest that development estimates need to be made in points and not be committed in hours, days, weeks or months?

7. Does the Manifesto suggest that the only fixed variable is the budget and that everything else is up in the air?

Think about it!

The notion that Agile removes the need for proper planning and proper scope determination is just that, a notion.

In the real world, and in real projects, the mere thought that a serious development would get a business blessing to spend real money without knowing what they will get for their money is, yet again, just a thought – a baseless concept.

Projects are about benefits realization and the way benefits are realized is via the delivery of capabilities that are the outputs of the projects. The idea that capabilities could be just work in progress, progressively being added during a progression of iterations or sprints, without having a clear visualization of what they will all add up to at the end is pure nonsensical and no serious organization will be willing to commit its scarce resources on such an expedition.

So when someone tells you this is how Agile does it don’t take their word for it.

Think about it!

I was invited to a meeting in one of the building in Melbourne’s CBD and have spotted the following in the building just across the road.

What do you think is happening up there? Click on the image to see enlarged version.

Think about it!

The following video is a result of a conversation that took place at the PM UK APM Knowledge SIG in November 2012.

Do BOK’s, in their various guises and incarnations, add or stifle wisdom and creativity? Watch this video and decide for yourself.

Check out also the related discussion in Linkedin – fascinating!

Think about it!

Many thanks to Jon Whitty for bringing this to my attention.

In recent months I have been part-time engaged in the documentation of a practical Earned Value Management System (EVMS) guide. The purpose of the guide was to integrate the ANSI/EIA-748-B-2007 with my company’s processes and procedures and align the terminology so it is easier for project managers to use the EVM method as part of their project practices.

As I was working on and writing up the guide I have met and had discussions with quite a number of project managers, both from within and outside of my company. A common theme that I have come across was around the concern that the collection of the base data and the maintenance of the metrics system arising from EVM is too complicated and will create unnecessary overheads on project managers that are under pressure already. It was clear to me, as a result of these encounters, that EVM is not well understood and that the cost / benefit aspects of utilizing it are not properly grasped by a large number of PMs.

One of the other aspects of these discussions that struck me as odd was the realization that the above perceptions were equally shared amongst PMP certified PMs. Why odd? Because I thought that the fact that the PMP certification requires basic knowledge in utilizing the EVM metrics for project monitoring and control will provide PMP holders with the basic understanding and the mindfulness required to integrate EVM into their projects.

This is clearly not the case, and here’s why:

Unlike the PMI’s Practice Standard for Earned Value Management, the PMBoK does an injustice to the domain knowledge of Earned Value Management in that it focuses on the way the various metrics are derived and calculated but it allocates no space to explaining what key criteria are required to ensure that a sustainable and credible Earned Value Management System is put in place to allow for these metrics to be derived in the first place.

A PMP aspirant will be aware of (and indeed be quizzed on) the meaning and composition of the various EVM terms but will have no (PMBoK induced) understanding of the system that needs to be put in place to get the fundamentals correct in the first to begin with.

This methodological gap needs to be bridged and the complete (or at the very least – a subset) of the ANSI/EIA-748-B-2007 criteria for the establishment of a EVM System need to be integrated into the main body of knowledge and not just the EVM practice standard. This will ensure that PMP certified project managers are well versed with the EVM terminology and are able to better integrate these principles into their projects.

Think about it!

One of the least understood aspects of the Earned Value Management methodology is that unlike Balance Sheets and Profit and Loss Statements, numbers calculated using this method are estimates only and are only meant to be used as a tool for eliciting management action.

What does it mean?

This means that it is not just the results of various calculations that should be the focus of your attention but rather what they mean and what action you should take to have them ‘fixed’.

It is the proper implementation of the EVMS criteria outlined in the ANSI/EIA-748-B-2007 that would guarantee that the performance measures you will derive are as accurate as possible and thus increase the statistical probability that the forecasts and estimates derived are credible and realistic.

Think about it!