How Can Our Scrum Team Improve Product Quality?

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 that the answer would be of general interest, so here it is.

Hi Chris,

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 setup, yet. Without automation of the regressions tests, unit test and pair-programming, how can our scrum team improve the quality of the product?


Dear XZ,

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.

Code reviews
A code review is a meeting between 2 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 worth-while 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 any time 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.



This entry was posted in agile, scrum, software, teams, test driven development. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Xiaoshu Zhao
    Posted December 28, 2011 at 1:45 am | Permalink

    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,

    • Posted December 28, 2011 at 8:38 pm | Permalink


      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. Posted December 28, 2011 at 6:27 pm | Permalink

    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. Posted February 2, 2012 at 10:08 pm | Permalink

    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.

One Trackback

  1. By Technical Excellence in Scrum - Chris Steele on Agile on November 25, 2012 at 3:16 am

    [...] team as the person who ensures that the framework is being implemented correctly – there are a number of ways that we can refine Scrum to improve quality and increase the level of technical [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>