Blog

Estimates, Teams and Commitments

Teams for many years have been used to providing estimates and  being held accountable for meeting them and are frequently told that the estimates are far too big and to reduce them because “it cannot possibly take that long”.  To make matters worse these estimates have often been provided on the team’s behalf by people who will not do the work and little or no account has been paid to the amount of time that people are actually available to spend on the work.

I ask anyone reading this to let me know if they have ever been able to spend one full day working on nothing but the task in hand, without any interruptions at all, no phone calls, no emails., no brief chats.  If you have then you must be unique so come along and see me and I will happily buy you a drink :)

We must learn to separate our estimates from our commitments; we must also learn to allow the team who will do the work to provide the estimates and accept that the team who will do the work are best equipped to estimate the size of the work.  Why are we surprised when things do not arrive when expected especially when the definition of an estimate is “an approximate calculation or judgement of the value, number, quantity, or extent of something”; and on top of this the estimates have been given to teams, or teams have been told to cut them, or no account has been made for the difference between size and duration.

We must change this thinking.  We must allow the people who do the work to estimate the size of the work and we must allow them to be able to make a commitment that separates the size from the duration and no longer force our opinions onto teams; until we do this we will always be bitterly disappointed with the results. 

To do this takes trust and courage, but by embracing courage and giving trust we will get more predictable results and ultimately have far better teams with more predictability of when work will be complete.  This can be a big step for many people who have been involved in IT for a long time, but it is a step that you will be glad to have made should you have the courage to take it.

What’s A Taxi Rank Got To Do With Agile?

A little while back on a trip to Las Vegas I went to see a great show, upon leaving the show on my way back to hail a taxi en-route to my hotel I encountered rather surprisingly a huge queue, probably a good 150-200 people deep. I joined in and as I looked around noticed that there was an equally large fleet of taxis! More than enough to cope with the demand, I was puzzled as to why the fleet was so big.

As I watched the queue of people slowly dissipate, I could see that there was a Valet who was controlling everything, the taxi’s would not move to the head until called by the Valet and the passengers would not approach a taxi until called out to do so. Furthermore, the passengers would not open the taxi door as they waited for the Valet.

This was all extremely time consuming, even more so when the Valet was slightly distracted for any reason as the passengers and taxi drivers had to wait for him to signal them to move on. Essentially things were only done when the Valet said so.

This all caused a lot of frustration for the waiting passengers and no doubt taxi drivers too, as the longer they waited the less time they had to earn a living.

This whole situation led me to think of Euston Railway Station in London, UK. Euston is a large mainline station where at peak times there are hundreds of people getting taxis. But the one big difference is the queue is always fairly short as people move through it quite rapidly.

I considered why this was the case as the taxi rank in London also had someone with a similar role to the Valet, it dawned on me however that the key word was similar. The Valet in London does not control, direct, or manage the queue but simply guides the whole process. The taxi drivers move themselves to the head of the queue when they see the customers are ready and it is safe to do so, and the customers walk towards the taxis as they approach, open the door themselves and hop in. The London Valet only gets involved if there is a bottleneck and in this instance he removes that bottleneck. All in all this leads to a smooth flowing and fast queuing system.

So what has all of this got to do with Agile? You may already have worked out that in London the whole process is self-organising, the team (customers and taxi drivers) organise themselves, they manage their own workload and decide on how best to do it. The Valet in London acts like a Scrum Master, he guides the team but does not control them and he does not tell the team how to do the work. To be precise he doesn’t tell the taxis when to move to the head of the queue or tell the customers how to get to the taxis or get into them, but when necessary he does remove any impediments that stop the smooth flow of the queuing system. This is all a far cry from the command and control nature and the micro-management approach that was taking place in Las Vegas.

So, if you work with teams allow them to self organise and empower your team, do not direct and control them. If you let go and allow them to truly self-organise then you may just get astonishing results and the team will move a lot faster.

Maybe we should tell the taxi rank operators in Las Vegas, I’m not sure however that the Valets would be pleased to be losing their one dollar tip, but I can guarantee that the customers and drivers would be over the moon with joy.

We Work With

baille Gifford british airways cabinet office credit suisse ericsson here kaplan microsoft minsistry of justice objectivity vocalink