Tuesday, February 01, 2005
Managing Multi-Tasking in a Small Group
Every one in Software Industry has this question: "We have a group of four people (4 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they're developing, but have to fix problems immediately if someone finds a problem and reports it. How do I manage the multi-tasking?"
Each product has technical debt, from insufficient testing (all the way through development) from previous releases.
There are a ton of ways to deal with insufficient testing. I would first start with peer review of fixes. If someone is interrupted from new development to deal with an already-existing, but newly discovered problem, have the developer ask a peer to review the fix. Part of the peer review would be to create automated tests for this fix. (Yes, I realize this now interrupts two people. I find that if there's a Big Problem in one product, there are frequently other related Big Problems in the related products.)
After peer review and automated tests, I would (gently) ask the tester how the tester missed this problem. This is for root cause analysis, not to assign blame. The tester doesn't read or write code, so the tester can only perform black box testing. Black box testing, by its very nature, is unlikely to find most of the gotcha's in a product. After a short root cause analysis, I would add some form of automated test development activity to each project.
I can see some heads shaking from here. "If we take time to add tests, we can't add as many features." You're absolutely right. But here's the problem. You're not adding the features now. You're adding broken almost-features. That's not helping the customers. The customers deserve to have features that work.
So, to deal with multi-tasking from defects in a small group, I recommend changing the way you work. If you keep the same lifecycle you have now, add the practice of peer review of all code and all fixes. Add in automated testing for all defects that have to be fixed from the field. Change the testing, because it's not exposing the Big Problems before you release. If you choose to change lifecycles, I suggest an agile lifecycle with test-driven development.
Whatever you do, don't assume that wishing away the problem will make it go away. Some practices need to change. Maybe not the ones I've suggested, but some of them do. The change will take time, depending on how much technical debt you have. Otherwise, you're left with the quality pledge and no muscle behind it.
Each product has technical debt, from insufficient testing (all the way through development) from previous releases.
There are a ton of ways to deal with insufficient testing. I would first start with peer review of fixes. If someone is interrupted from new development to deal with an already-existing, but newly discovered problem, have the developer ask a peer to review the fix. Part of the peer review would be to create automated tests for this fix. (Yes, I realize this now interrupts two people. I find that if there's a Big Problem in one product, there are frequently other related Big Problems in the related products.)
After peer review and automated tests, I would (gently) ask the tester how the tester missed this problem. This is for root cause analysis, not to assign blame. The tester doesn't read or write code, so the tester can only perform black box testing. Black box testing, by its very nature, is unlikely to find most of the gotcha's in a product. After a short root cause analysis, I would add some form of automated test development activity to each project.
I can see some heads shaking from here. "If we take time to add tests, we can't add as many features." You're absolutely right. But here's the problem. You're not adding the features now. You're adding broken almost-features. That's not helping the customers. The customers deserve to have features that work.
So, to deal with multi-tasking from defects in a small group, I recommend changing the way you work. If you keep the same lifecycle you have now, add the practice of peer review of all code and all fixes. Add in automated testing for all defects that have to be fixed from the field. Change the testing, because it's not exposing the Big Problems before you release. If you choose to change lifecycles, I suggest an agile lifecycle with test-driven development.
Whatever you do, don't assume that wishing away the problem will make it go away. Some practices need to change. Maybe not the ones I've suggested, but some of them do. The change will take time, depending on how much technical debt you have. Otherwise, you're left with the quality pledge and no muscle behind it.
