http://jrothman.com/blog/mpd/2005/01/managing-multi-tasking-in-a-small-group.html Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk. Mon, 01 Dec 2008 23:14:16 +0000 http://wordpress.org/?v=2.6.5 http://jrothman.com/blog/mpd/2005/01/managing-multi-tasking-in-a-small-group.html#comment-47 James A. Ward Fri, 14 Jan 2005 17:54:21 +0000 http://jrothman.com/blog/mpd/?p=8191#comment-47 Johanna is absolutely correct in her suggestions on fixing the root causes of the problems this organization is experiencing. I would make a couple of suggestions on dealing with the symptoms. We should remember that the problems are never going to disappear completely, no matter how good we are. First, the key phrase is "have to fix problems immediately." You don't HAVE TO do this. This is a management decision, just as the decision to ship the product with latent defects is a management decision. Most bug fixes can be deferred, and put on the list for consideration for inclusion with the next release of the product. Second, based on historical data, estimate how much time is consumed in bug fixes during each three month release cycle and subtract that from the time available to work on the release. You can assign one developer to handle all "critical" bug fixes during that cycle, on a rotating basis, thereby isolating the other two developers to work exclusively on the release (except for the peer review that Johanna suggests). If more than one developer on a part time basis is required to deal with problem fixes, you have a far more serious problem. Incidentally, why haven't you been doing peer reviews all along? Johanna is absolutely correct in her suggestions on fixing the root causes of the problems this organization is experiencing. I would make a couple of suggestions on dealing with the symptoms. We should remember that the problems are never going to disappear completely, no matter how good we are.
First, the key phrase is “have to fix problems immediately.” You don’t HAVE TO do this. This is a management decision, just as the decision to ship the product with latent defects is a management decision. Most bug fixes can be deferred, and put on the list for consideration for inclusion with the next release of the product.
Second, based on historical data, estimate how much time is consumed in bug fixes during each three month release cycle and subtract that from the time available to work on the release. You can assign one developer to handle all “critical” bug fixes during that cycle, on a rotating basis, thereby isolating the other two developers to work exclusively on the release (except for the peer review that Johanna suggests). If more than one developer on a part time basis is required to deal with problem fixes, you have a far more serious problem.
Incidentally, why haven’t you been doing peer reviews all along?

]]> http://jrothman.com/blog/mpd/2005/01/managing-multi-tasking-in-a-small-group.html#comment-48 Faisal N. Jawdat Thu, 13 Jan 2005 23:06:13 +0000 http://jrothman.com/blog/mpd/?p=8191#comment-48 Seconded on the automated testing. Depending on the scope of the products, I'd go farther: - coders should produce unit tests for all code they write, and those unit tests should be added to the regression suite - testers should produce tests that reproduce problems Given the size of the team and the length of the schedules, I'd suggest reading up on extreme programming. I don't think all the XP practices would necessarily be appropriate, but some of the tools for handling change management, scoping, and testing may come in handy. Seconded on the automated testing.
Depending on the scope of the products, I’d go farther:
- coders should produce unit tests for all code they write, and those unit tests should be added to the regression suite
- testers should produce tests that reproduce problems
Given the size of the team and the length of the schedules, I’d suggest reading up on extreme programming. I don’t think all the XP practices would necessarily be appropriate, but some of the tools for handling change management, scoping, and testing may come in handy.

]]>