STOP measuring knowledge based work in hours!
Last night I was having a quick browse through one of the most famous essays ever written on Software engineering, "The Mythical Man Month”... I don't think I've read the book in over ten years during which time its been sat quietly collecting dust on my bookshelf! To my surprise when flicking through I noticed that the original version was published in 1975 making this year the 40th anniversary - However despite being marginally older than myself it shows perhaps how little has changed in the last 40 years!
A while back I was doing some coaching with a team roughly made up of 4 scrum teams of 10-12 people - The product being developed was late and over budget...
The knee jerk reaction was to throw yet more developers at the project, The effect? Well anybody who’s read the book can probably already guess - But for those who haven't suffice to say it didn't help matters!
One of the issues in terms of governance and reliability of estimates was the obsession with the man hour. All work was estimated in hours.... The total project time was calculated in man hours and the number of hours worked per sprint were recorded.
Ensuring the project was on track was as simple as subtracting the number of hours worked per sprint from the total project size - To be fair that is a slight simplification of the reality... But I do mean slight! Senior management were happy that this method of tracking hourly burn down ensured that things were on track and PM's ensured that the scrum teams were loaded up with around 3000 man hours per sprint.
Unsurprisingly the project began to run late - Alarm bells weren't triggered early because the burn-down charts all looked good! Work was being allocated by squeezing jobs based on hours into the sprint... Which had the effect of ballooning WIP (Work in progress) and decreasing work fully completed and tested - ' Tasks were allowed to stretch over multiple sprints and all the while more was was being pushed in..... All to meet the 3000 man hour target per sprint.
I'd like to think this was a unusual setup (Well I wouldn't... Otherwise I'd find it harder to find work!) - But time and time again I meet with and talk to managers who are obsessed with measuring and estimating in man hours! I have yet to be shown what the standard output per man hour is? Unlike working in a factory producing the infamous widget where output is tangible and quantifiable (You can count the number of widgets manufactured per hour) software isn't so simple! Perhaps these managers are measuring lines of code per hour! Which would be funny except that I've actually seen it done!
I don’t have a problem with the concept of measuring the productivity of widget manufacturing using man hours... Particularly if you happen to be living in the 19th Century and you go to work wearing a top hat everyday.... But that's exactly where such management techniques belong.
Apart from being a totally useless method of measuring productivity, Estimating deliverables or applying governance - It's actually harmful to the team's performance.
I quickly discovered that the retrospective had long been abolished - the reason was that is was too expensive for 50ish people to be in a meeting for an hour.
The below Cumulative Flow Diagram shows a different story to that of the burn-down charts - It was just unfortunate that nobody looked at it!
CFD Diagram - Source: That’s Intelligence
Massive Lead times between work starting and being completed… Too much Work In Progress - And not enough work marked as 'Done' - Despite the above graph clearly showing a problem within the first couple of sprints alarm bells weren't raised until 6 months into the project.
As a Scrum Master I generate metrics all the time :-
Flow efficiency
Lead times
Velocity (You need to be careful with this one)
Histograms (Ticket/Story completion by type and/or size)
Cumulative Flow Diagrams
And the ubiquitous burn-down
So why do managers insist on using a methodology which we all know simply doesn't work?
Perhaps it's because much of our thinking is still based on construction metaphors... But software is not construction.. We're not building brick walls... You can't measure quality or progress with a tape measure! Or by counting lines of code or recording time sat coding at a desk.... Some of my best ideas when working as a developer occurred over a cup of tea, Walking around the park or waking up at 3 in the morning with the answer! - How does that fit in with man hour management and costing?
The accountants hold a lot of the blame.. Projects and departments and teams are still costed at person level and Project managers are often expected to account and justify the cost of every person.
However - Sadly I suspect there might be a bigger reason why people are still addicted to the man hour..... It's just too easy! Ask the development team to estimate... They pluck a number out the air, double it and add 20% - The PM then only has to divide the project size in hours by the time available to calculate how many people are needed or the reverse to calculate delivery with a know team size... It doesn't get much simpler or wrong!
True project planning - Where you understand the average lead time of tasks and stories... Where you know that a story estimated at 8 points is completed within 5 days 80% of the time, Where you know what work is 'Done' and shippable and how much work is left - When you know the optimum time to start various bits of work because you have reliable metrics and you have a team that actually deliverers at a known sustainable, repeatable pace... Well that takes a lot more effort and requires real thinking not sitting down with a calculator!
As a follow on from this blog I intend to write a series discussing useful metrics which help your team plan more accurately.