XZ, a participant in a public Certified ScrumMaster workshop that I gave in Beijing last week, asked me how his scrum team could improve their software product’s quality. I thought the answer would be of general interest, so here it is.
Thank you for giving us the certified scrum master training last week in Beijing. Your training is very impressive, and I appreciate it a lot. I asked you a lot of questions; may I ask one more? In our company, the automation for regression tests hasn’t been set up, yet. Without automation of the regressions tests, unit test, and pair-programming, how can our scrum team improve the quality of the product?
First, let me encourage you to keep up the work to automate your regression tests; few things have as big a return on investment. It enables the team to move much faster, and make changes and improvements in the code fearlessly. The other practices you mention: unit testing and pair-programming, are also great practices, and I encourage your team to try them too.
Having said that, your question was what else could your team do. Additional practices I would recommend your team consider are: code reviews, frequent testing by real users, testing bashes, and whole-team ownership of quality and testing.
A code review is a meeting between two or more developers where they look at some code and talk about how it could be improved. This isn’t about finding fault, or showing how much better or smarter one developer is. The simple fact is that all code can be improved, and having multiple people look at it can lead to improvement. It also leads to learning. The participants in the code review share and learn techniques that will make them all better coders. Thus, all future code will be improved, not just the code currently being reviewed.
By the way, one more reason to consider pair-programming is that it gives you continuous real-time code review. I’ve seen a few teams adopt code reviews, and then move on to pair-programming, so that they could speed up the feedback loop, and learning, that their code reviews were providing.
Frequent Testing by Real Users
If you want a reality check on the quality and usability of your new functionality, just grab a real user and ask them to accomplish something with it. This doesn’t have to be a big deal; 10 minutes might be all you need. If you don’t have a real user handy, get as close to real as you can. A team I was on had one of the customer support people try to use new features. They were close enough to ‘real’ to know how a real user would approach the task and what they would expect the software to do. Note, I’m not talking about full-blown user acceptance testing here. That’s good stuff too, but I’m talking about ad-hoc testing, as soon as possible. Just added the ability to make text bold? Grab a user (or support person, or your mom) and ask them to make some text bold, without explaining to them how to do it. You will probably learn something about the usability and quality of what you have built.
A testing bash, or testing party, is time set aside for the whole team to get in a room and test the product, in any way they can think of. The idea is to make it a fun, interactive, and social event. Who can find the most edge cases? The most unusual input? Let’s explore the edges of performance with big input, or on a machine that is running very slowly, or with low memory. Are there configurations we haven’t thought of? The idea is to encourage creativity. The testing bash should not replace your regular testing techniques, and alone it won’t provide sufficient testing to ship with confidence, but you may find it a worthwhile addition to your testing regiment. One of the things I like about a testing bash is that it gets the whole team involved in testing the product. Which leads me to…
Whole Team Ownership of Quality and Testing
In my work with new scrum teams, I often find that ‘the team’ is really two teams: the coders and the testers. A team is a relatively small group of people working interdependently towards a common goal. For a good scrum team, the common goal is a shippable product. Of course, the product isn’t shippable until the coding and testing (and probably other stuff too) is done. If we allow the coders to think that they’ve done their job as soon the code is written, we are undermining the team and reducing our chances of shipping a quality product anytime soon. We want the whole team to be responsible for creating shippable product. That means writing code, and testing it as well.
Very often, I see teams that can write new code at a much faster rate than they can test. In these cases, if the coders only code, the testers will never really catch up. Better that the coders stop coding and help the testers test! Several powerful things happen when coders do this. First, they start to take ownership for delivery of product, not just code. Second, the coders often find ways to accelerate the testing. You want to see good test automation come together quickly? Get your production coders to write the automation code! They will be motivated to do so if they don’t get to move on to new code until the current code is fully under test.
I hope some of these ideas are helpful to you.