Agile

I’m still experimenting with Dialogue Sheets for Retrospectives (the download page, and my earlier blog entry) and so are other people. Of the feedback I’ve had so far it has been overwhelmingly positive. Perhaps people who aren’t positive don’t bother trying them.

The sheets are free to download but I do request people register. My objective here is to obtain more feedback. Periodically, like today, I get the e-mail addresses of those who have downloaded and I send a polite note saying “Any feedback?”.

In registering I ask a couple of other questions. One of these questions is: “How often do you hold a retrospective?”. I thought it would be interesting to share the results of this data so far:

How often do you do a retrospective?

38%	Every two weeks or more often
21%	Never
16%	At least once a month
15%	I am a retrospective facilitator and so hold many
6%	Rarely
3%	At least once a quarter
1%	About every six months

This is good to see, about 54% of people are holding retrospectives with the frequency you would expect from a Scrum, XP or other type of Agile team. But sadly the second biggest group is never holding retrospectives, 21% of people. And 10% are holding them rarely or very occasionally.

Now think again, this data is not representative. 15% of people are not retrospective facilitators (e.g. Scrum Masters, Agile Coach, etc.). The people who download these sheets have an interest in retrospectives, this group is self-selecting.

The implications of this are that an awful lot less than 54% of people are doing retrospectives with anything near the frequency one should expect from an Agile team. Given that retrospectives are the primary means of learning in an Agile team I suspect that means that an awful lot of teams are are not really practicing Agile as described in the books.

I have long suspected that retrospectives are actually one of the more advanced Agile techniques and are far from common. I think this data supports that argument, but at the same time I think they are more common than I tended to think, maybe thats the progress of 3 years.

Earlier this week I had a conversation with Benjamin Mitchell about an entrepreneur he’d done some work with. Benjamin had been suggesting a lean start-up approach to the business in which the entrepreneur worked to validate his business idea early and gradually build the product one validated step at a time.

Things didn’t go well, the understanding I came to from Benjamin’s story – although his might be different – was that the entrepreneur was very attached his business idea. It was pretty well formed and he could imagine it working. In popular culture entrepreneurs are often seen as iconoclasts who battle doubters, naysayers and banks to bring their ideas to life against the odds. Benjamin was just another doubter.

Now I tend to agree with Benjamin’s approach because it is very difficult to tell if a new business idea, indeed any project, will work until you try to build it. But building it is expensive so I advocate a “Try, fail fast, fail cheap, move on to the next thing” approach – I don’t think this is that different to lean start-up thinking but as I’ve not read the lean start-up book I don’t really know.

I don’t just advocate this approach for new businesses, I advise it for established businesses embarking on a project. My logic is: you can’t be sure a product will work in the market till you try it, nor can you plan a project until you know how fast (velocity) the team will work. In fact, until the team trys to work together and build something you don’t have any data on which to project plans. Making estimates without data is little better than guessing.

Thus, I advise a Mao like approach to corporate projects, “let a thousand flowers bloom” – start multiple small projects, small teams and use portfolio review to remove those that don’t seem promising and reallocate resources to those which do seem promising – or launch more experiments.

Unfortunately, like the entrepreneur, people get very attached to the idea of a project so it gets momentum. Big corporations respond by only starting projects in which they have a high degree of confidence. That means they do a lot of pre-project work – planning, designing, etc., this in turn makes it difficult and expensive to start projects, which in turn means that any project that does get started already has momentum. And it means that once underway the project finds it difficult to cope with change.

It seems to me that successful projects in corporations are often the result of one person who wants the project to happen and does what is necessary, not unlike entrepreneurs. In both cases a strong willed, capable, person makes something happen. That person needs to be motivated, they need hope, they need ambition and hope. Such people are going to kind who ignore naysayers and doubters.

The Agile approach – try, gather data, evaluate, or my “fail fast, fail cheap, retry” approach are not going to go down well with the kind of pig-headed, obstinate, passionate, do-anything-it-takes, approach which has made many successful projects a success. Quite the opposite.

Interestingly Benjamin had another example of a company which does take the “fail fast, fail cheap, try again” approach and was staffed by passionate, hopeful, people. From what he told me these people were passionate about the process as much as they were passionate about the products they tried. They could accept regular failure of good ideas because they saw the process working, and perhaps more importantly, could transfer their hope to the next idea. There was always a next idea.

What I am saying is: Don’t rely on hope to get your projects done, use data – be empirical not emptional.

Finally, I should say, that while I talked much of this over with Benjamin he would be the first to point out unvalidated steps in my thinking, and ungrounded assumptions I’ve made. So maybe this entire entry is really a hypotheses. The hypothesis is:

“The trial and error approach of Agile is unlikely to please those who get passionate about an idea and want to move heaven and earth to make it happen.”

I’ll let you, dear reader, decide for yourself on that hypotheses. If you have any evidence – to support or disprove – my hypothesis please add a comment below.

One of the things I’ve always found paradoxical about Scrum (specifically ScrumTM) is its position on management. On the one hand, Scrum is very management friendly – see my Scrum has Three Advantages over XP post. Basically Scrum has done a very good job of marketing itself to managers.

But Scrum is a little like a Monty Python Spring Surprise – “that’s our speciality – covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.”

Hidden inside the tasty Scrum case is a sometimes evangelical dislike of managers, and in particular project managers. Take these excerpts from the Scrum Primer (Deemer and Benefield, some versions have Larman as a co-author too):

• “The ScrumMaster is not the manager of the team or a project manager; instead, the ScrumMaster serves the team, protects them from outside interference, and educates and guides the Product Owner and the team in the skilful use of Scrum.”
• “unlike a project manager, the ScrumMaster does not tell people what to do or assign tasks – they facilitate the process, supporting the team as it organizes and manages itself. If the ScrumMaster was previously in a position managing the team, they will need to significantly change their mindset and style of interaction for the team to be successful with Scrum. In the case that an ex-manager transitions to the role of ScrumMaster, it is best to serve a team other than the one that previously reported to the manager, otherwise the social or power dynamics are in potential conflict.”
• “Note there is no role of project manager in Scrum. Sometimes an (ex-)project manager can step into the role of ScrumMaster, but this has a mixed record of success – there is a
• fundamental difference between the two roles, both in day-to-day responsibilities and in the mindset required to be successful. ”

Indeed I once sat in on a course entitled “Agile Project Management” by a well known Scrum trainer. In response to the a question from a project manager “What does a project manager do in Scrum?” the answer was “If you have a project manager in Scrum you aren’t doing Scrum.”

Take another example, Bas Vodde’s Nokia Test, the final question asks “are project managers (or anyone else) disrupting the work of the team?” Every time I show that question to a project manager we have to discuss it, project managers don’t generally believe they disrupt the team unreasonably. It certainly looks like Bas doesn’t like Project Managers.

A few years ago when Jeff Sutherland spoke in London I recall him saying there was little future for project manager. Many needed to revert to programming (which they had done before project management), a few would become Scrum Masters, a few Product Owners and a very few could continue being project managers on the largest projects.

Sutherland’s own Scrum Handbook seems pretty clear: “there is no team manager or project manager in Scrum.” (Actually, if you read what else the handbook says about project manager it looks like the text is taken directly from the Scrum Primer, Sutherland seems to feel the same way as Deemer, Benefield and Larman.)

Given all the anti-manager, specifically anti-project manager project manager noise from some in the Scrum camp I found it surprising a couple of months ago when I noticed that Scrum Master Certificate now come with the implicit endorsement of the Project Management Institute.

For example, take Martine Devos’ London Scrum Master Course, it is worth 14 PMI Professional Development units. Jeff Sutherland’s own Scrum Master course boast 16 PDUs (one assume these are PMI units although he doesn’t state so explicitly.)

So, if the PMI are now crediting Scrum Master Courses, and the Scrum folks are making their courses compliant with PMI rules then one assumes that the two are reconciled. Why would a project manager who is intent on being a Scrum Master, and therefore no longer being a project manager, want credits?

Maybe Turkey’s are voting for Christmas. It looks odd for me.

Actually, to be fair to Scrum, the situation is a little more complex than I’ve laid out here. Looking a little bit further into Scrum history we find the following.

Schwaber and Beedle in Agile Software Development with Scrum say “The Scrum Master is a new management role introduced by Scrum” and a little later “The team leader, project leader or project manager often assume the Scrum Master role.” This final statement describes what I have seen happen most often in practices.

In Agile Project Management withScrum Schwaber says “The Scrum Master fills the position normally occupied by the project manager. I’ve taken the liberty of redefining the role.”

One explanation might be that the view of the Project Manager has changed over time. Initially the Scrum originators saw project managers as candidates for filling the Scrum Master role – or at least not the source of problems. As Schwaber almost says: it is the same role filled in a different way.

Later Project Managers, and maybe all managers, came to be seen as a problem, and, most recently as it becomes clear that Project Managers can be Scrum Masters and can be a force for good on a project the position has returned to the original view.

Alternatively it might be there are multiple opinions on how Scrum and the Scrum Master relates to the traditional Project Manager role. It benefits some people, at some times, to claim the Scrum Master is not a Project Manager. And it benefits some people at other times to reconcile the two roles.

One of the advantages of Scrum, specifically ScrumTM, is that is defines what is it, and is not, much more clearly than “Agile”. However with time this picture is becoming muddied.

Finally, this entry is a bit critical of Scrum, I won’t pretend it isn’t, but really, I’d like to understand what is going on here. If anyone can shed some light on the thinking, whether it changed or not, please add a comment.

I’ve mentioned some of the work I’ve been doing in Cornwall over the last eight or nine months in this blog a few times, and anyone who follows me on Twitter will have seen my Tweets about the “Cornish Software Mines.” Well, one of the spin off of this work is a Cornish Agile Conference – Agile on the Beach.

Agile on the Beach is happening in Falmouth on Thursday 15 and 16 September 2011. Speakers include: Kevlin Henney, Tom and Mary Poppendieck, Rachel Davies, Steve Freeman, Jon Jagger, Jason Gorman and quite a few more – see here. Some more speakers will be announced nearer to the conference.

Tickets went on sale today, early bird price is £230 – if you are quick you might get one of the limited number of £195 tickets available.

The organisers (and yes, I’m one) hope that people attending the conference will take the opportunity to extend their visit to Cornwall into a long weekend. After all, Cornwall is much better know as a holiday destination than a software development centre.

All the details on the Agile on the Beach website. In addition, if you plan to attend sign on to the LinkedIn group and you can see who else will be there. More details are being announced all the time so to stay up with the latest announcements follow the Twitter hash tag #AgileOTB and Twitter User @Agileonthebeach.

I heard this story a few months ago from Benjamin Mitchell, it is good and I wanted to believe it so I did. (Benjamin by the way tells it with a good deal more embellishment.)

Anyone who has had a course from me in the last six months has probably heard me retell the story with a large health warning saying “I’ve heard this story, I believe it but I don’t have a source to prove it.”

Now, Toby Parkins has tracked down the link. So here it is: Parrot cages, the true story, care of the BBC – so it must be true!

I’m off to Cornwall again next week for my monthly visit. Anyone who follows me on Twitter (allankellynet) may have noticed that every few weeks I put out a few tweets along the lines of “On my way to the Cornish Software Mines again”. They may not actually dig source code out of the ground in Cornwall but there are some very active software companies there.

Under the auspicious of Grow Cornwall I have been in providing Agile coaching to several companies as part of an Agile programme designed to bring better development practices to multiple companies. To date six companies have been part of the programme to some degree and next week we are adding some more.

In the next few months I hope more of this work will come into the public domain as articles and case studies. There are even plans to hold an Agile conference in Falmouth, to be named Agile on the Beach. (More to follow soon.)

This engagement has really given me a chance to think about my coaching style and develop some techniques and approaches which I’ve thought about in the past but not really codified. One of these I call Light Touch Agile Coaching.

Many description of Agile Coaching assume a full time coach. Scrum specifically just about mandates a full time Scrum Master for each time. The Scrum Master is closest Scrum gets to an Agile Coach, indeed, some people would see them as the same thing. I don’t, and thats worth a full article in its own right but not today.

In Cornwall there are three companies I’ve be working with more than others and a clear pattern to the work has emerged. It goes something like this:

• Companies joining the programme receive a training course over two days, preferably offsite. This has worked best when the net is spread wide and the whole development team and managers are involved.
• The team are allowed a little time to digest this then asked: do you still want to try Agile? The programme is designed with the expectation that they say Yes, in which case the coaching begins. If they say No then fair enough, its is there decision.
• I visit once a month, I spend between half a day and two days with the team. How much time I spend depends on the size of the team and the company, how long I have been working with them, and the particular set of problems they are faced with.
• My visit usually starts with an inspection of the white board – call it a Kanban board or an Information Radiator if you prefer – its the board with all the work on it.
• I read the board, I ask question, I get asked questions, I understand the state of play and get an idea on what needs addressing.
• Sometimes, some places, I sit down with a manager and talk about the last month. What has happened, what progress they have made, what understandings they have reached, what has puzzled them, how the team have performed, and so on.
• Next I sit down with the development team and conduct a similar type of exercise. Sometimes the teams have conducted their own retrospective and I review that, other times this exercise takes on elements of a retrospective.
• (One of my challenges is to make all the teams proficient with retrospectives so when my work is finished they can continue themselves.)
• In some companies I sit with the marketing group for a conversation too. All the companies I’m working with develop software for external customers and some of them have marketing teams. As the development teams have become more effective a lot of my focus has shifted to marrying up marketing with development so the right thing gets built.
• During the course of these meetings I start to construct a list of “Expected next time”: things they managers and teams tell me they will change, or things they will put in place for my next visit. Naturally, as a I talk to people I’m also looking through the last “Expected next time” list and seeing how the team have done.
• I started doing the “Next time” list for my own benefit but I’m open about it with the teams and it has become a useful little tool in both tracking whats changing and getting commitment form the teams.

I like this light touch approach. On the whole it has worked well, I get to help the managers and teams while they keep responsibility and feel ownership. Yes, there are cases were I wish I had been there more frequently, and there are cases where I feel I could just step in and fix it far more quickly, but that is not my role.

While I’ve concentrated on Agile processes and management (both product and more company) coaching we have also introduced more technical coaching. Jon Jagger and Nancy Van Schooenderwoert have helped out here. They have taken a similar light touch approach. In Jon’s case he normally spends his time pairing with the developers on his visit while Nancy works remotely.

There are some variations to the approach outlined above, things haven’t always gone smoothly and one company dropped out of the programme right after the training. But, on the whole it is working and working well.

Some successes to date:

• One company develops a software product for doctors, they recently received ISO-13485 using an Agile process I helped them develop. ISO-13485, for those who don’t know, is a standard based on ISO-9000 which certifies a company to create medical devices.
• The day after completing TDD training with Jon Jagger one team wrote a unit test which found a bug in their live system.
• One manager when asked “So this estimation process and charts are more accurate than the way you used to do it?” replied “This isn’t estimation, that is Mystic Meg stuff, this is science, I know when we will deliver.”
• By adopting Agile one company has won, and is successfully working on, a new website for one of the worlds largest telecom’s companies. The same company has now spawned a spin-off which is born Agile and will work with the same telco in a contract worth over a quarter of a million pounds.
• The three companies I am working with have all been strong enough to hire new staff in this year.

I’m not saying that light touch coaching will work in every case – indeed, at one of the Cornish companies we decided they needed a more intensive programme. I do think that this is a model that can be used elsewhere.

I’m at ACCU 2011 this week, in my lightening talk I publicly unveiled, for the first time, Retrospective Dialogue Sheets.

I have been experimenting with dialogue sheets at conferences for a few years now. For a long time my aim has been to use them for team retrospectives. I’ve now produced a few variations and tested them with some teams. Still I need to do more tests, so I’m looking for volunteers.

I’m making these dialogue sheets available as a community resource, without charge. However, there is a catch: you need a large printer (A1 size) to print them. So I’ve set-up a print-on-demand service where you can buy printed versions.

Right now you can:

• See examines of previous dialogue sheets and exercises
• Read more about retrospective dialogue sheets, www.dialoguesheets.com
• Download a retrospective dialogue sheets to print use with you team
• Buy printed dialogue sheets

If you do try one of these sheets please e-mail me and let me know about your experiences.

Finally, I’m still looking for volunteers who will let me watch teams using these sheets. I’m happy to give teams printed dialogue sheets for free if you will let me observe the team doing the exercise. If you can help, please e-mail me.

One of the questions that comes up again and again in the context of Agile work is “How do I know how many people to put on this project?”

(I’m using the word ‘Project’ in the loosest sense, think “piece of work”)

My usual answer is: Staff Strategically, allocate people to a piece of work in relation to how important this piece of work is relative to everything else you are trying to do. Keep teams together for as long as possible, only make small, gradual changes to teams over time.

This isn’t really a problem when work is underway, you simply sum up the ball-park estimates on the work remaining (in abstract points), measure the velocity (again in abstract points), divide total by the velocity and if you get an answer you like then all is well. If the answer is not soon enough you can (gradually) add more people, and if the answer is very good you might even slow down.

However, the problem really comes when you are starting a piece of work. Particularly if you are bidding on a contract to do work for someone else. The problem occurs because without any data (velocity, sum of outstanding work) you can’t estimate when you will be done, and without doing the work you can’t get any data.

Rule 1: Without data you can’t forecast anything so don’t pretend you can.

So, what do you do?

Option 1 is to pretend you aren’t doing Agile; use whatever methods and techniques you’ve used before, get an estimate (or maybe more of a guess) on how many people you need for how long then get started with those numbers. As soon as you start throw away the plans. Wing it for an couple of iterations, by then you have the data and can re-plan.

Not a perfect solution but one that could work.

Option 2 is to just start. Start as small as you can, I think two people is about as small as you can get – below that you are into the realm of micro-projects which have their own dynamics.

Let this mini-team run for a few iterations and then, as if by magic, you have data.

Once you have data you can: keep as is, grown, shrink or cancel entirely.

Rule 2: Start small, get data, grow later

Starting small is essential because it reduces risk and because it minimises the momentum which can make it difficult to cancel work.

It also minimises the influence of Conway’s Law: “every organization will produce systems which are a copy of the communication paths in the organization.”

If you start with a big team you will get a big project – allocate a C# developer, a DBA and a UI designer and you’ll get a three-tier architecture. If you start small you should get a small project.

In the longer term how you staff a project is less a function of “How many people do I need to do this work?” and more a question of “How many people can I afford to do this work?”

Projects are never really staffed on a “how many people do I need” basis, we just pretend they are. Writing today, March 2011, you will probably put more people on a piece of work than you would 18 months ago, but fewer than you would have three years ago.

Rule 3: Staff work strategically relative to the other work to be done and corporate priorities, rebalance only occasionally

Strategic staffing means looking at how any one piece of work stacks up against the other pieces of work in play – or proposed – and the resources that are available to use. It means considering: what is the benefit of a piece of work? What is the risk? What work absolutely must be done, and what work can be left undone? What work is experimental?

The trick is to arrange work so teams can grown, or shrink, as resources and priorities change.

That is not a recipe for changing team composition every week. Indeed, the general principle should be: keep teams together and consistent for as long as possible. Only change teams occasionally, and only grow teams slowly.

However, things do change and work needs rebalancing. This should be an active, measured, and occasional process. Better to change staff allocations once a quarter in a review meeting than every week as a knee-jerk reaction.

That is what strategic staffing is. If you find yourself changing staff allocations every few weeks in response to events you aren’t working strategically.

As for deciding how many people to put on a piece of work when you are bidding for a contract, well, its another argument for constructing contracts as ongoing, rolling contracts.

Telling your client: “We think we need six people for six months” is little better than lying if you don’t have data to back it up. Have these six people worked together before? How productive will they be with the client’s environment? With the clients requirements? What work might emerge?

Better to tell the client: “We propose to start with three people for three months, at the end of that time we will review progress with you and decide with you, when we have data, whether to increase or decrease staffing. If you want to move faster than we can allocate four people and review after one month.”

It might not be what your client wants to hear but it sure beats guessing, or lying. Involve your customer, give them choices. It might not be a great sales technique but if the client won’t engage in this conversation there are probably other conversations they won’t have either.

In two previous entries I’ve reported some interesting statistics and findings – possibly facts – from Capers Jones book Applied Software Measurement (see Software Facts – well, numbers at least and More Facts and Figures from Capers Jones). I want to finish off with a few notes from the later chapters of the book.

On packaged software

• Modifications to existing COTS package – I assume he includes SAP and Oracle here – is high-risk with low productivity
• When changes exceed 25% it may be cheaper to write from scratch. (I’m not sure what it is 25% of, total size of the package, 25% of function points, 25% of features?)
• Packages over 100,000 function points (approximately 1m lines of code) usually have poor bug removal rates, below 90%

On management

• Jones supports my frequent comment that comes redundancies and downsizing Test and QA staff are among the first to be let go
• Projects organised using matrix management have a much higher probability of being cancelled or running out of control
• Up to 40%(even 50%) of effort is unrecorded in standard tracking systems

On defects/fault

• “Defect removal for internal software is almost universally inadequate”
• “Defect removal is often the most expensive single software activity”
• WIthout improving software quality it is not possible to make significant improve to productivity
• “Modifying well-structured code is more than twice as productive as modifying older unstructured software” – when he says this I assume he doesn’t mean “structured programming” but rather “well designed code”
• Code complexity is more likely to be because of poorly trained programmers rather than problem complexity
• Errors tend to group together, some modules will be very buggy, others relatively bug free
• Having specialist, dedicated, maintenance developers is more productive than giving general developers maintenance tasks. Interleaving new work and fixes slows things down
• Each round of testing generally finds 30-35% of bugs, design and code reviews often find over 85%
• Unit testing effectiveness is more difficult to measure than other forms of testing because developers perform this themselves before formal testing cuts in. From the studies available it is a less effective form of testing with only about 25% of defects found this way.
• As far as I can tell, the “unit testing” Jones has examined isn’t of the Test Driven Development type supported by continuous integration and automatic test running. Such a low figure doesn’t seem consistent with other studies (e.g. the Nagappan, Maximilien, Bhat and Williams study I discussed in August last year.)
• Formal design and code reviews are cheaper than testing.
• SOA will only work if quality is high (i.e. few bugs)
• Client-server applications have poor quality records, typically 20% more problems than mainframe applications

Documentation

• For a typical in-house development project paperwork will be 25-30% of the project cost, with about 30 word of English for every line of code
• Requirements are one of the chief sources of defects – thus measuring “quality” as conformance to requirements is illogical

Agile/CMM/ISO

• There is no evidence that companies adopting ISO 9000 in software development have improved quality
• Jones considers ISO 9000, 9001, 9002, 9003 and 9004 to be subjective and ambiguous
• Below 1,000 function points (approximately 10,000 lines of code) Agile methods are the most productive
• Above 10,000 function points the CMMI approach seems to be more productive
• I wold suggest that as time goes by Agile is learning to scale and pushing that 1,000 upwards

Jones also makes this comment: “large systems tend to be decomposed into components that match the organizational structures of the developing enterprise rather than components that match the needs of the software itself.”

In other words: Conway’s Law. (See also my own study on Conway’s Law.) Its a shame Jones missed this reference, given how well the book is referenced on the whole I’m surprised.

Elsewhere Jones is supportive of code reuse, he says successful companies can create software with as much as 85% reused code. This surprises me, generally I’m a skeptical of code reuse. I don’t disbelieve Jones, I’d like to know more about what these companies do. As has to be more about the organisational structure than just telling developers: “write reusable code”.

Overall the book is highly recommended although there are several things I would like to see improved for the next revision.

First, Jones does repeat himself frequently – sometimes exactly the same text. Removing some of the duplication would make for a shorter book.

Second, as noted above, Jones has no numbers on how automated unit testing, i.e. Test Driven Development and similar, stacks up against traditional unit testing and reviews. I’d like to see some numbers here. Although to be fair it depends on Jone’s clients asking him to examine TDD.

Finally, Jones is very very keen on function points as a measurement tool. I agree with him, lines of code is silly, the arguments for function points are convincing. But, I’m not convinced his definition of function points is the right one, primarily because it doesn’t account for algorithmic logic.

In my own context, Agile, I’d love to be able to measure function points. Jones rails against Agile teams for not counting function points. However, counting function points is expensive. Until it is cheap and fast Agile teams are unlikely to do it. Again, there is little Jones can do directly to fix this but I’d like him to examine the argument.

I want to finish my notes on Jones book with what I think is his key message:

“Although few managers realize it, reducing the quantity of defects during development is, in fact, the best way to shorten schedules and reduce costs.”

As I said in my last blog entry I’ve been looking at some of the academic research on task time estimation. Long long ago, well 1979, two researchers, Kahneman and Tversky described “The Planning Fallacy.”

The Planning Fallacy is now well established in academic literature and there is even a Planning Fallacy wikipedia page. All the other literature I looked at takes this fallacy as a starting point. What the fallacy says is two-fold:

• Humans systematically underestimate how long it will take to do a task
• Humans are over confident in their own estimates

Breaking out of the fallacy is hard. Simply saying “estimate better” or “remember how long previous tasks took” won’t work. You might just succeed in increasing the estimate to something longer than it takes to do but you are still no more accurate.

Curiously the literature does show that although human’s can’t estimate how long a task will take, the estimate they produce do correlate with actual time spent on a task. In other words: any time estimate is likely to be too small but relative to other estimates the estimate is good.

Second, it seems the planning fallacy holds retrospectively. If you are asked to record how long you spend on a task you are quite likely to underestimate it. There seems no reason to believe retrospective estimation is significantly more accurate than future estimation.

Something else that comes out of the research is: psychologists and others who study this stuff still don’t completely understand what the brain is up to, some of the studies contradict each other and there are plenty of subtle differences which influence estimates.

Third, although we don’t like to admit it deadlines play a big role in both estimating and doing. If a deadline is mentioned before an estimate is given people tend to estimate within the deadline. People are also quite good at meeting deadlines (assuming no outside blocks that is), partly this is because estimating then doing is a lot about time management. i.e. managing your time to fit within the estimate.

While deadlines seem like a good way of bring work to a conclusion it doesn’t seem a particularly good idea to base deadlines on estimates. Consider two scenarios:

• Simple estimate becomes a deadline: If we ask people to estimate how long a piece of work will take they will probably underestimate. So if this estimate is then used as a deadline the deadline may well be missed.

• Pessimistic estimate becomes deadline: If people are encouraged, coerced, or scared into giving pessimistic estimates the estimate will be too long. If this estimate is then used as a deadline work is likely to be completed inside the time but there will be “slack” time. The actual time spent on the task may be the same either way but the total elapsed (end-to-end) time will be longer.

I’ve written my findings down in full, albeit somewhat roughly, together with a full list of the articles I examined in depth. “Estimation and Retrospective Estimation” can be downloaded from my website.

I would love to spend more time digging into this subject but I can’t. Anyone else want to?