Ah you’ve bought a shiny new tool for your developers, they all wanted it and now it’s theirs 🙂 6 months later, nobody is using it 😦 and someone comes to you with another new tool to buy hmm. Where did this all go wrong?
Engineering has focused on continuous improvement as a standard part of its activities for a long time, the software industry is often behind in this respect. The focus should be understanding what is wrong before you try and fix it. Match the tool to a problem and make sure it’s actually doing what you bought it for. A3 which was invented by Toyota focuses on this and we use it for all our initiatives. See A3thinking.com for a full book on the subject. Here’s a simple example of an A3 approach using unit testing:
What’s the background to your issue, i.e. if you had to describe unit testing without discussing the problem what would you write?
- Current Problem:
What’s wrong? Try to quantify what is actually failing. Not enough unit testing could mean only 10% of the system is under test.
Why is it wrong? Are your developers trained sufficiently, do they have access to the right tools, do they know they are supposed to be unit testing?
What do you want to achieve? How do you measure success, is 50% of your system under test your aim?
What’s your strategy for achieving the improvement? What does your milestone plan look like? Can you get your system under 50% test in one month or one year? WHAT TOOL DO I NEED?
- Follow up:
How do I know I’m on track? This is very very important, you can put everything in place and then just leave it to fail. We use milestone plans and report on the success of those. It’s useful to have a delivery owner too so you know who “owns” the problem. No best endeavors please.