There are three constants in life: death, taxes and software slipping. I’m doing my best to avoid the first two, but the latter seems here to stay. Software engineering, despite all its advances, has never solved the fundamental question: how long will it take? The advice I got from Nik the development manager on my first day at work after graduation “think of a number, then double it” is still a good rule of thumb.
There are lots of reasons that software slips: engineers are optimistic people, who assume this time round will be better, despite years of evidence to the contrary; the requirements are never really clear, no matter what the product manager tells you; there will always be one innocent little question, 90% of the way through, that suddenly balloons into a metric crapload of work; and everyone’s favourite: what idiot did a half-assed job here, making me finish up his mess – why I oughta!
What’s the consequence of software slipping?
Perhaps you work for one of those companies that don’t care, “you’re done when you’re done; we’ll release when you’re ready”. If so, get outta here, we don’t like your kind round here!
For the rest of us, something has to happen when the schedule slips. Somebody, somewhere has been promised the release by a certain date. All your caveats have been ignored – all that person hears is “It’ll be live by July”. Whether its that big external client; “the business”; or your boss – somebody, somewhere, has an expectation mismatch with reality.
What happens?
I don’t have to tell you what happens – project managers, development leads, your boss – suddenly everybody cares about scope/time/resources and has designs on your weekend.
One way or another, projects normally get out. Scope is cut, resources are pointlessly thrown at the project, you lose your weekends. Eventually the project gets out and everyone lives to fight another day. But spare a thought for the real victim here: quality.
Quality?
And you thought it was all about you? Yes – the real victim in all this is the quality of your software.
In a traditional waterfall project, normally by the time you realise you’re late – its too damned late to do anything about it, and you’re screwed. So you do the only thing you can do – you cut time from the end of the project; i.e. persuade QA they don’t need to do as much testing as they estimated. The result? Bugs are missed, crap code gets released to customers – quality has been in a hit and run accident.
In an iterative project you might be a bit more lucky: it might just be one iteration that’s screwed. So you cut from the end of the iteration (there goes the QA again) and try and cut scope from the next iteration to “pull it back”. Unfortunately, all those bugs from the previous iteration are still there, waiting to derail QA and add unexpected development costs later on in the project. And before you know it, you’re back at the scene of the accident again.
At this point the agilistas are all laughing “but that never happens on an agile project!”.
Doesn’t it?
Agile’s different
Its true: scrum, kanban and the like are much better at forecasting ahead of time when you’re gonna miss some arbitrary date. You know your velocity, you know how much work is left. You can figure out how many features you can deliver in the time available and cut entire features from the end of the project, without sacrificing QA. Perfect!
But the really insidious problem on agile projects, is that the project manager, scrum master, development lead, even the smart developers all start burndown engineering. Sam the scrum master says,
We’re a bit behind on the burndown chart, Mike, so if you can just get this story finished up today we’ll score the points and get right back on track!
Sounds harmless enough, doesn’t it?
Burndown engineering
Burndown engineering is a terrible crime. By continually trying to engineer each story / feature to adhere to some average you’ve dreamt up, quality dies a thousand small deaths.
I was gonna refactor this code, but I guess I can come back and do it in the next story
Sure, Sam, I was gonna write some more thorough tests; but I can do that in the next sprint – this story’s done!
The QA guys have been over it already; we really ought to automate some of these tests but we’ve not had time. Shall we add a story to a later sprint to pick this up?
And suddenly, with the best of intentions, Sam has forced technical debt into the project, just in the interests of maintaining his pretty graph. As a one-off, this is fine. The problem is, this happens on every story, for the whole duration of the project. In the end, Sam doesn’t have to say a word – the team are self-policing. They’re trying to pad their estimates to get time to finish everything they need to, but development’s taking longer than expected because everyone’s coming across technical debt from previously half-finished stories.
What’s to be done?
Quality should be a parameter controlled by the development team. Some companies need a high quality bar, other times you can get away with much lower – it depends what kind of industry you’re in. But the development team should set a standard for quality and then stick to it.
Velocity is an emergent property of the team. If you hold quality and resources constant, the velocity of the team is something you measure not something you change. Sure, change the scope or change the schedule (or change the number of people if you believe in man months, mythical or otherwise) – but forcing each unit of work to take a certain amount of time forces quality to be the variable that changes.
But you still need deadlines
Sure, somebody, somewhere needs to know when the release will be ready. But the product owner should be the one that knows the release schedule. Someone whose only lever is scope. If they want it faster, their only option is to reduce scope.
The scrum master or development lead needs to ensure that development continues apace, but that quality is held constant. If the product owner wants it faster – his choice is scope. Leaving developers to focus on doing what they need to get done, without worrying whether they’re maintaining their velocity this week.
Then we can all stop making crap tradeoffs about whether cutting this story short will make the project deliver faster overall (of course not!); or whether we can justify removing this technical debt to make things quicker (of course we can!).
Ever found yourself on the receiving end of this – being pushed to cut corners to maintain some arbitrary deadline? Ever found yourself trying to justify Doing The Right Thing that you know will take longer now, but make things quicker overall? Let’s hear your war stories!
References: The danger of deadlines from our NCG partner David Green at the Actively Lazy blog.
