The whole team approach

Posted by Elizabeth Harrin

At Øredev, the software development conference last winter, Lisa Crispin spoke about the whole team approach and how important this is on projects. “The whole team approach is a meaningful commitment to quality,” she said. “How good do you want to be?” The three pillars of the whole team approach are:

  • A meaningful commitment to quality
  • A shared vision of the product
  • Diversity of skills, experiences and viewpoints.

Committing to quality

“Standing up for quality, especially in some corporate environments, takes a lot of courage,” said Lisa.

She gave an example from one of her projects. The team were seeing a lot of user errors when users came to type in their bank account numbers in the software. The software did not produce an error message, so when customer services tried to process the details, they failed. This led to the customer support team having to call back the customer to get the correct number. The overhead was significant – both for the company’s telephone service operators who had a lot more calls to make, and for the customer, who didn’t get the order in a timely manner because this step held up the process.

The solution was to create ‘type-ahead’ lists that would offer a selection of banks to choose from. Unfortunately, the team could not find a way to test this feature in an automated fashion so they couldn’t use it. Their commitment to quality meant that they were not prepared to have a feature in live without the support of adequate testing.

Fixing the test problem

However, that didn’t stop them. They decided that they needed the feature, so they needed to change the way they did automated testing.

Together, the team found two new test tools. They did a ‘bake off’ where they tested the tools against each other. After a short amount of time they realised that the test result reporting was not very good, so they stopped the trial of both these tools. While it might seem wasteful to throw away all that work and start from scratch, Lisa’s team knew that they needed not only the ability to test the new bank look up feature accurately, but also to report it properly too. They decided it was better to test another two tools than implement something that was not quite right through laziness.

Reducing calls by 75%

The team went back to the drawing board and found another two test tools to try. This time, they did have some success and they took one of those tools forward to a proof of concept. Once they had been able to test the feature successfully and implement it in live, it had a huge impact on the software overall. The new bank look up feature cut down the number of calls by 75%, so this was a massive win.

Next steps

The next steps are to further embed this new testing tool in the software project methodology in use by the team. That means more training for the developers on the testing tools. “The point is that we tried several different approaches until we found the one that was right for us,” said Lisa. The time invested was worth it because the team now has maintainable tests and it gave them the confidence to experiment. As a whole team, they worked together to find the best solution for them which will help them going forward with new improvements for the software, with the aim of further reducing user errors.

By involving the whole project team and not just the testers, the team built consensus. “My advice is to get the whole team together and have a couple of different smaller teams go off and try different solutions,” Lisa advised. Finally, she recommended making time to solve the problems the team is facing for the long term. While they could have pressed ahead, it would have cost them more time and money later, so the team and the project could go faster overall if they made the time commitment to trial the tools earlier in the project.

Tags: ,

Post comment