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.
Posted by david at July 20, 2004 01:52 AMVery cool! It clearly didn't take you very long to get the key message in the book.
As for leaving people idle, it isn't a bad thing. It gives you excess capacity to absorb variation in flow/demand or accomodate other exceptions.
Also spare capacity gives your people time to think about how they might improve their ways of working and time to go and implement those changes e.g. developing tools to support better development practices.
David
Posted by: David Anderson at December 8, 2004 06:57 AMGreat THinking David - well i am a TOC freak too- i try to apply it everywhere - it has ben lending me insights too!
keep going-
But i do wanna move on to some serious / GRAND issues to be taken up by the TOC perspective- :)
David, thanks for the comment.
I agree with you that 'idle' time can be put to great use, both as a buffer to absorb spikes and also as an opportuninty for process or code improvement.
I tend to explicitly track significant refactorings or 'tool building' exercises and tie them back to a benefit that I can justify to the client. I find that requiring people to make a case for this sort of activity helps to ensure that it's actually beneficial. I've seen far too many cases where people have spent weeks building a great tool to do a job that was only ever going to be done once ;)
I've since moved onto a new project, which is far different from my previous 'agile-ish' project. In the new project, specialisation rules - we have no less than seven 'silos' within the development team, ranging from one to four people in each silo. The (negative) difference in productivity is astonishing, especially since we effectively have seven opportunities for hitting a critical path overrun instead of one. Not to mention the obvious key person dependencies, (bus-factor? what bus-factor?).
One of the consequences of this specialisation is that it takes a new 'front-end' developer between two to four _weeks_ to become productive. No - I'm not kidding, and these are experienced developers. Essentially the code base has become so complicated that it's virtually impossible to grasp. The complexity can be traced back to precisely one factor - the code was pretty much all written by one person. I've never seen a more compelling argument for common code ownership and pairing. I guess the silver lining is that I now have a great 'real-life' example to reference the next time a client suggests that a silo'd team would be more efficient.
David
Posted by: David Pattinson at December 24, 2004 12:02 AMNow that it's three months later, I'd be interested in how things are going in your new project. Specifically, what steps, if any, are you taking to migrate the team away from silos. I have exactly this same situation on my current project, and am quite interested in the practical aspects of this.
Posted by: mike at March 13, 2005 11:23 PM