Jeff Patton has a great blog about Agile product development practices - mostly from the product/design perspective, but he's got some good project management information in there too.  He doesn't post very often, but his posts are real winners.

His latest article is about Kanban Development - something that has been gaining traction and awareness in the Agile development community for the last year or two.  I won't expound much on it here, as Jeff does a much better job of it than I would - read his post!

Kanban development comes from Toyota's famously efficient and high quality product development & manufacturing teams - Kanban means literally visual card (or board), and is about the use of simple visual devices to control the flow of work through any system.

A common problem in software development is having too many unfinished work items on a person or team's plate at any one time.  This is usually a symptom of people not completely finishing the items before moving on to the next one, because they've run into some type of roadblock with their current item (need a question answered, waiting for the next build, or whatever).

The problem with this is that it increases the amount of context switching people have to - do by orders of magnitude in some cases.    The costs of context switching for people working in highly intellectual jobs like ours is very often grossly underestimated, because we're so used to multi-tasking and often our team culture often promotes it - people with a lot on their plate are looked up to as busy and productive, when they are really just spinning their wheels with lots of activity but little real progress.

A related problem is that this increases the 'cycle time' - the average amount of calendar time it takes for items to be completed, which increases the risk that items will become stale.  For example it is much more efficient for a developer to fix bugs on an item that they coded today or yesterday than even a few days later.

The use of Kanban concepts can help with these problems by putting simple rules or governors on your software development workflow to simply not allow too many work items in any one stage or spot.  For instance: you could have a rule to not allow more than x units of work in the Implementation (coding) state.  If a business analyst is finished with another requirement/story/use case, they're not allowed to send it to the development queue.  And if the size of work sitting in the design queue is already maxed out, they're not allowed to pick up another story and start working on that.  What should they do then?  Perhaps help the testers test some of the items in their queue.  Perhaps go talk with customers about the latest release, or do some usability/user experience testing.  Anything but drop more work on the developers.  The same would go for developers - if the test queue is 'full', they can't drop more coded features onto the test team.  They should go help the testers with their work items, help set up the performance testing lab, help troubleshoot the latest escalation from support.  They could even take a bit of time for professional development by doing some reading or experimenting.

Having people help with addressing the current bottlenecks for the team keeps the work flowing through the system at a more reliable rate, and reduces the amount of context switching going on because there simply won't be so many work items in play at any one time.  It also reduces the cycle time time for items in the system, which means that the work is fresher in people's mind so that things like bugfixing and any rework from feedback are done much more efficiently.

The more subtle benefit that this brings to the team is to bring the 'whole team together'.  It's no longer "someone else's problem" if they're overburdened.  It encourages teamwork and collaboration, and puts the focus on 'finished' to the end of the system (ready for production), rather than just finishing my tasks.

These rules could be put into place by simple declaration of policy (another email from the manager), or implementing some sort of rules in your task tracking system, but the use of very visual mechanisms like a story board can be very helpful in not only enforcing the rules, but making sense of them for the team - they can 'see' that the test team is overburdened, so the decision to go and help them out becomes a natural decision that doesn't require top-down direction.  Jeff's article above has some good examples of how story boards can be used for this.  For distributed teams, that story board may need to become a dashboard on your team's wiki, or you could experiment with tools like cardmeeting.com.

There are a number of variations on this theme that can also be useful - minimum size in certain queues, and maximum sizes for any one person.  Remember when experimenting with things like this to always do a retrospective with your team at the end of the iteration to get feedback and make decisions about improvements.

I know this is a pretty light treatment on the subject, but hopefully this has introduced the concept well enough that you're encouraged to do a bit more research on your own and dream about how this might help your team work together more efficiently.

Cheers,

Allan