Riding the Bench in Software Development

At any given moment I probably have a handful of my developers who aren’t buried knee deep in coding, testing, or gathering requirements. They’re ‘riding the bench’ as the term went in the professional services world. In a consulting shop if you rode the bench for too long you were soon asked to be successful elsewhere. So proactive developers would always be trying to scrounge up the next client project, or volunteering to build a ‘useful’ internal software tool. The slower ones, the types you wanted to weed out of any good professional services firm viewed bench time as a bit of a vacation and attempted to milk it. That was generally a bad strategy.

In the more traditional corporate IT shops without the pressure to squeeze every last dollar out of their primary resources, their consultants, downtime seems to be a little more common. Typically it seems to come out of traditional project planning and resource allocation. The problem starts at the beginning of the project where the PM demands some development resources. Probably one of those resources is really involved up front in requirements. If you’re lucky the rest have some configuration work or research related to the project to work on. Often they’re underutilized until coding really gets underway. Then again in design the bulk of the developers are only peripherally involved, but hopefully there’s valuable prototyping and spiking to be done. Then the coding begins and goes until delivery. Even here things can slow down if a developer finishes a module early and can’t easily start a new assignment because of dependencies. Then generally we move into a testing phase and if the developers have done a good quality job along the way there are often few bugs and so again a lot of downtime. No one can be released though because they were ‘promised’ to the project and the sponsor would scream. Then even after a project’s deployed the business isn’t always ready with a backlog of projects for people.

Much of this stems from most corporate developments fixation on waterfall like processes even RUP run as waterfall. As I move more of our teams to a Scrum like approach I’m hoping to get much better utilization out of our developers. It was great to see on the first Scrum pilot project as the developers adjusted each day to take on new work, or help others get their assignments done that they kept busy with a minimal effort. I’m hoping to see this continue as we roll Scrum into more of our projects. Of course some individual developers are more or less motivated when seeing the option to slow down, but with short iterations and deliveries there seems to be added peer pressure to stay busy. I’ll have to see how well this works out on the next set of projects.