2010 has been the most productive year ever for me as part of a development team, and I attribute this in great part to having no deadlines.
In what may seem counter-intuitive, deadlines actually slow down development.
Deadlines are generally worked out either based on external forces (for example, a ticket website may have its deadline based on a sporting event), or calculated based on estimates from the developers.
In the case of external forces, the resulting time period will either be more than what’s really needed (in which case Parkinson’s Law, “Work expands to fill the time available”, applies); or less time than needed, in which case developers who sense they’re running out of time will resort to CYA measures to avoid responsibility for potential failure. CYA measures mean long emails and meetings, stress, office politics and lack of decisions – leaving less time for productive development.
As for projects based on estimates, no developer can predict exactly how long something will take. If they’d solved the exact same problem before, surely they’d just use the previous solution? The more time spent working on an estimate, the more accurate it will be, but ultimately the only sure way to promise an achievable deadline is to pad it to account for unforeseen circumstances.
Management invariably figure out one day that the estimates are padded and start forcing developers’ estimates down. Developers will just take that into account by padding them up even further the next time. It’s a never-ending cycle and the only things one is guaranteed to achieve are annoyed developers and wasted time.
Don’t get me wrong – the pressure of a deadline in the right circumstances can force teams to turn to creative answers – but in my experience as both a developer and manager, there’s a better philosophy.
It starts with what is to me the most critical aspect of any technology company: having a competent and trusted technical lead, who can tell when the team is working hard or when they’re under-performing.
If management can be assured that everyone is already doing their job at maximum efficiency, what difference is a deadline going to make to the outcome?
The next step is to involve developers in solving the business problems. Let them see each task as their project, their component, web page, etc. Too often I’ve seen development managers keeping a project’s rationale and constraints hidden from the very people who have to build it, as if the full scope is some kind of management-only secret. I say let the developers lead the whiteboard sessions for the parts they’ll work on. When challenged to come up with the solution that makes their work feasible, a developer is putting himself/herself in the spotlight, and more often than not will make it his/her personal mission to succeed, putting in the extra hours and thought of their own accord.
Consider that “This must be done by June 1st or else” will garner a lot less understanding than, “If you can find a way to ship this feature before our competitor, you may have some fun scalability challenges coming your way.”
I’m not advocating that a team has no direction or project management. Obviously no company can wait indefinitely to ship their next release. The solution is to keep iterations small and simple. Even without deadlines, the average project life-cycle should be a couple of weeks at most. If it turns out to be longer than this in reality, the next feature should be chopped up into smaller chunks.
Think of this as a reactive management strategy. Actively forcing deadlines is always going to add time to a project; reactively tweaking your team for the next one will only use up time when things go wrong.
