Simulating variation in work

As part of my side project to write a software development team simulator I have had to work out how to represent how long a piece of work takes to complete.

What I have so far

The first version of the development simulator started with a very simple capability set on each team member denoting the amount of work the team member was able to complete in a day. This allowed me to quickly build other parts of the system but it’s far from the truth of what would really happen in a team.

Items of work do not always take the same amount of time to complete. So firstly I needed to represent the size of the story with an estimate and ensure that a team member always took that long to complete the work.

What I have added

There is a flaw with this, how many times have you gone over or under and estimate? There are two factors at work here that need to be accounted for. Firstly estimates are just a guess, we could be totally wrong. Secondly when human beings are involved there is always natural variation in the time taken to complete a piece of work. To simulate this I have chosen to allow for an item of work to vary in its duration based on it’s estimate.

What I want to do in the future

This leads me nicely on to talking briefly about the work of Edwards Deming. He acknowledged that there is variation in the work that any human being does and that a system in a stable state would have variation between a calculated upper and lower limits.

The role of a team that acknowledges variation in work is to measure it, understand why it happens and attempt to reduce is with incremental measured changes. One key effect on variation in software development could be quality, the worse the quality, the more times it may need to be tested and worked on by a developer. By finding ways to improve quality (perhaps TDD or Pairing) then variation may be reduced and the probability of completing on time is increased. For now I am happy that there is variation in my simulator and in the future I will introduce ways of effecting quality to reduce the variation in work.

Another key point that Deming raised was that normally people only account for 6% of the overall performance of a system. The other 94% comes down to how the system of doing work is structured. In the future I would like to add experience levels to the team members to account for this 6%, having senior to junior team members that may effect variation by a small amount.

Finally Deming talked about any work that falls outside the upper and lower limits called special case variation. These are type of variation that are not normal and should be investigated as events like these have a more significant affect of productivity. In the future I would like to add random events that cause these type of variation, some that can be resolved and some that cannot.

Getting the latest version with Batching and Work based variation…

You can clone the code from my git hub repository…

git clone https://github.com/chrisabird/Development-Team-Simulator.git
git checkout v0.2

You can run the sample with…

Rake sample

The sample now include a column for variation against each completed work item. In the future I would like to get these into a graph showing the upper, lower and median lines. There are now three examples in team_spec which show different configurations of a team using batching (push, iterative and waterfall).