As a software development company, we mostly work on client projects. Occasionally one project doesn’t start right when another ends. In that short interval, we would like to work on something useful — in house products, R&D projects, etc.. Unfortunately, we can’t run these “bench” projects the way we run a normal project. We can’t do two or even one week iterations, because some folks may only be on the bench for a few days. So, how do you apply these resources efficiently? Here are a few tricks we use:
- Divide work into very small pieces — no epic user stories!
- Keep your technology as vanilla as possible to reduce the learning curve.
- Use Kanban to organize the work.
What is Kanban? There’s some good explanations of it over at Wikipedia and InfoQ, but just like Agile and the feedback loop, it helps to know the basic principles so you can figure out how it will work for you. From the InfoQ article:
A Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a “pull” production system, invented and developed as part of the Toyota Production System (TPS).
[...]
Kanban’s aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. “Pull” means that the downstream workers withdraw or “pull” the parts they need from their upstream processes.
So, the basic principles are “pull” and minimizing “work-in-progress.” Let’s see how this applies to the bench.
If my user stories move from design to development to testing, then if I don’t have any of them that have been designed, then my developers won’t have anything to work on. Since we typically have several bench projects going at one time, my Kanban board may tell me that I have plenty of development ready stories for project A, but none for project B. If I have an information architect on the bench for a few days, all things being equal, I should have them work on project B rather than project A.
Putting user story cards up on a board helps to point out where the bottlenecks and shortcomings are. If you are about to have a bunch of QA resources on the bench, you may want to divert a few developers ahead of time in order to give them something to test. If they’re billable, however, you may just have to make the decision that the bench projects aren’t going to see any QA time this time around and that the QA resources will be honing their skills, improving processes and tools, or just pitching in on other billable projects.
Sometimes even with good planning, the bench resources just don’t line up. But with Kanban, at least you’ll know why.
Related Services: Agile Development, Custom Software Development
