How Can Our Scrum Team Improve Product Quality?


Quality dial turned all the way upThank you for 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. Test automation enables the team to move much faster and make improvements 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.

Code Reviews

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.

Testing Bashes

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.



Share it!

5 thoughts on “How Can Our Scrum Team Improve Product Quality?

  1. Xiaoshu Zhao

    Hi Chris,
    Thank you for the detailed explanations!

    Our team is trying Code Review now. However it is the first time I hear “Frequent Testing by Real Users
    ” and “Testing Bashes”. They are very new to me, and I will have a try with these in our team.
    For “Whole Team Ownership of Quality and Testing”, yes, sometimes the developers also involve in testing when QA request the support. It is a good way to set up the whole team’s ownership.

    Yesterday I took a long time to think about this question.
    Your training has changed me a lot. Now I think actually Scrum is a way of developing software: The team runs for a while, and stop. Think about how can we improve. Then run again to implement the change to get the improvement…
    That’s the key, and “Code Review”, “Automation Testing” and “Pair-Programming” are the tools.
    As long as we have the key, we can use different tools to reach the goal (The team become more productive and the quality of the product is good –> Team provides more values to the company)

    Please correct me if I am wrong.

    Happy New Year!

    All the best,

    1. Chris Sims Post author


      You’ve got it! Scrum provides a framework that helps a team continually learn, and continually improve. Exactly how the team improves, is up to the team.

      Good luck!


  2. Elisabeth

    Great suggestions!

    Whole team ownership of quality is a particularly huge issue. Any time the people who are responsible for creating something think that it’s someone else’s job to make sure the thing works, there will be quality problems. And any time there is a group of people assigned to check on the work by a different group, there will be team dysfunctions. Making the whole team responsible for the result — no excuses, no blaming the other guy, no “the hole is in your side of the boat” — is one of the most important things that organizations can do to improve quality.

    Though I will confess that I favor paired programming over code reviews, and continuous testing throughout the sprint (collaboratively, in pairs even) to big-bang-bug-bashes.

    Thanks for a great list…


  3. Dale Emery

    Your first three suggestions are great ways to find problems. To these I would add: Look not only for problems, but for patterns in the problems. Are there parts of the code that are buggier than others? Are there logic problems that happen repeatedly (e.g. off by one errors)? Are there more problems interacting with certain third-party packages? If you can identify patterns, then perhaps you can reduce whole categories of problems with a little bit of training, or even simply a little bit of awareness.

    Before starting development of a feature, create a set of concrete examples of the feature in action. Many defects are caused by people interpreting the requirements differently. A set of concrete examples helps everyone understand the common goal, and can go a long way toward reducing misinterpretation.

  4. Pingback: Technical Excellence in Scrum - Chris Steele on Agile

Leave a Reply

Your email address will not be published. Required fields are marked *