I've just started reading Agile Management for Software Engineering, by David J. Anderson. In the very beginning he talks about the Theory of Constraints (TOC), which he characterises as finding the constraint in your process (the slowest link) and tuning the entire process to that speed. The effect is to minimise inventory by achieving a continuous flow of production.
I started to wonder how this could be done in my current team. Actually I started to wonder if we were already doing it. It occurred to me that we have a fixed number of people, split into broad categories of analyst, developer and tester. If analysis is our constraint, then by the TOC I should reduce the flow of work to accomodate that. The problem is - what do I do with my developers and testers? If I just leave them idle then I'm realising no benefit, since I have to pay them the same amount anyway (fixed cost). I'm assuming that I don't have the capacity to loan them to other projects (partly 'cos I'd never get them back, and partly 'cos of the return ramp-up cost). Then it dawned on me that if I had developers who could act as analysts, or somehow shift some of the analysis work to the developers - then I'd be able to speed up and keep everyone busy.
Now this isn't really much of an insight - and in fact we already did this when we had a pinch in analysis for a few iterations. We're currently moving some of the work back to the analysts since our new constraint is developement . The insight (and this may be old news to you guys), was that this may be the underlying reason that teams of generalists seem to have better success rates than teams of specialists*. Simply put - you can manage your constraints better if you have people who are able to be moved around. I can't be stuffed doing the maths - but I'm pretty sure you could prove this mathematically. It might very easily end up that a team of average generalist people would massively outperform a team composed largely of skilled specialists - if for example the developers were skilled specialists and the analysts were unskilled specialists or vice verca. (This is amusingly affirming for me, since it's generally recognised by my peers that I'm no specialist - however I do seem to add value ;)
So, it may be that on page n+1, this is what Mr. Anderson is going to tell me - but I was so taken with the idea that I couldn't wait to read on - so someone else can tell me if this is the case.
(It seems to me that there may be some meat in the book with respect to tuning a software development organisation, not just at the project level)
Regards, David.
* I'm pretty sure I read a post about this recently, but I can't find it now - maybe someone could help me out.