I’ve come across two useful numerical methods for thinking about software development. You can stop reading if numbers frighten you (but then what are you doing reading a coding blog anyway)?
It’s 148. Let your organisation size grow larger than this number, says primate researcher Dunbar, and you’re going to have serious communication problems. Not a current or near-term problem for youDevise, though I’ve recently chatted to someone who runs an organisation of 180 who has exactly the communication headaches the theory predicts.
What’s bugging me is that I’m sure there’s a similar theory for much smaller teams, which I learnt as “split as soon as you grow larger than a cricket team (11 members)”. I keep hoping someone will tell me where this idea comes from and what the theory is behind it (pretty sure it won’t involve gorillas, anyway).
Little’s Law says
L = λW
where L = number of items in process, λ = arrival rate, and W = average wait time. It dates back to an original publication by Little in 1961 but a recent paper by Little and Graves explains it very nicely including the mathematical justification.
Those of us who just want to use the law find it useful when you know two of the figures and not the third. For instance, you may know the rough arrival rate of bug reports, and it’s usually pretty easy to check the number that are open (and you probably know if that number is stable or not). So to estimate the length of time it takes to fix a bug, divide number open by arrival rate.
I also like the law because it helps explain the lean software development theory of limiting work in progress. If your goal is to reduce L, the number of outstanding items (say bugs in the backlog) then you quickly see from the formula that you have to reduce arrival rate (by improving quality) and also bring down wait time (by improving efficiency). So among other things, limiting work in progress encourages two good behaviours on your team.