The test phase of a programme is never a straightforward experience: The complexities of the data, the processes, user permissions, the need for subject matters experts who have day-jobs and the set-up of environments all combine to make it one of the most challenging phases, and it comes usually at a point where time is short, corporate patience is thin and the programme team are tired. None of these things are ingredients for a happy ship. However, there are ways for a programme to make it easier, as an experience with a client three years ago illustrated.
The client finally entered UAT (User Acceptance Testing) after programme delays of more than two years. The pressure to meet the target launch date had resulted in the commitment of a very large team – 50 subject matter experts – to conduct the testing, representing the different roles within the system. The team were set a target to complete 10 test scenarios per day.
Two weeks into UAT, the run-rate had only reached three scenarios per day, but the test manager was struggling to pinpoint why, suggesting an accumulation of issues; everything from bad data and testing script issues to incorrect user permissions – all factors that explained the run-rate but no clear pathway to raise the overall velocity of testing. So we asked a different question: How many roles exist in the system? Answer: Eight. Okay, could the test manager pick the eight most suitable people to fill those roles, and we’ll run them as a separate team and see how they compare to the remaining 42?
Initially, the idea was resisted. In fact, the programme steering committee wanted to throw even more subject matter experts at testing to try to accelerate, but they were eventually persuaded to try the eight-person experiment. Within a week, the team of eight were completing 13 scenarios per day – well in excess of the original target of 10. The remaining 42 testers had carried on as they were and were still delivering three test scenarios a day.
So what was going on?
There is a phenomenon known as the Ringelmann Effect, often talked about in business schools. The classic example is a tug-of-war. Every time a new team member is added to each end of the rope, the pull force exerted on the rope increases, but the pull-force per person decreases. It’s a phenomenon that has been studied and has spawned many theories over the decades, but the most common theories attribute the decrease in pull force per person to two factors: The first is the loss of motivation as each individual’s ability to influence decreases with the arrival of a new team member, but the second (and probably more relevant) factor is the coordination overhead associated with ensuring that all members of the team exert the maximum pull force at the same time.
What this translated to in the UAT was a more coordinated effort. The team of eight could organise, schedule and problem-solve in a way that a team of 50 simply could not. The result? Much higher productivity, plain and simple.
So, the morals of the tale:
1.
When it comes to programme teams, less really can be more.
2.
Sometimes, problem-solving requires a bit of experimentation.
Dedicated to John Falconer, a former client from whom I’ve had the pleasure of learning many things, including the Ringelmann Effect.