The concept of whole team quality is a good one. Everybody on a project should be responsible for quality. Unfortunately, there are often holes in our whole team quality approach. Here are a few I’ve seen:
No definition of Done – It’s difficult to achieve quality if you don’t define what it means! So many agile teams don’t spend the time necessary to agree on what quality criteria must be met for success to be declared. Also, it’s important to define not only what it means to be done with a Sprint but also what’s necessary for User Story’s to be marked as done as well.
Dysfunctional developer / tester relationship – Developers are from Mars and Testers are from Venus. Let’s face it, developers and testers inherently see the world differently. But that’s a good thing! One is in the business of creating beautiful, awe inspiring architectural wonders. The other is a demolition crew. Both are necessary to produce a quality product, but if developers and testers can’t figure out a day-by-day, hour-by-hour, or even minute-by-minute working relationships, quality is in trouble.
Siloed organizational structure – Agile doesn’t care what the structure of your organization looks like. However it’s critical that teams are afforded the opportunity to work together on a minute-by-minute basis AND be rewarded consistently across roles. If working together isn’t reinforced by senior management through clear direction and consistent incentives, it’ll be difficult to get everyone on the team rowing in the same direction.
Some ways to fill these holes in whole team quality:
Do all planning together – A team that plans together, stands together. There’s no reason why all planning activities shouldn’t be done as a team. I’ve heard the argument that this is an inefficient use of time. Really? How many times have untestable designs cost your organization weeks of rework? Test plans been poor because the testers didn’t understand the product well enough to effectively test? Requirements been vague and the programmers have made assumptions that turned out not to be true? These thing happen every week on most project. Doing planning as a cross-functional team assures that needed and necessary information regarding design, programming, and testing are discussed and agreed to by everyone involved in the process.
Allocate time for developer/tester pairing – There is no better way to build one-on-one relationships than to pair. Why not pair up developers and testers for periodic sessions? The tester can help the developer understand how to write better unit tests so implementation defects are caught early in the process. Developers can help testers understand the functionality being developed so effective testing of both features and their integration is performed.
Hold periodic bug bashes – Allocate time during each Sprint to get the team together for collective bug hunting. This is a great end of the Sprint activity to reinforce the notion that everybody is responsible for quality. Besides an effective mechanism for identifying bugs, bug bashes can be a lot of fun and help the team gel. But remember, APP is a must. Always Bring Pizza!
Filling the holes in whole team quality will not only improve the quality of your software but will produce a strong, productive agile team.
2 thoughts to “Holes in Whole Team Quality”
Excellent post on the potential pitfall of Whole Team Quality (and probably in regular SDLC). However, you probably mean ABP when you say “Always Bring Pizza!”
Good catch! Thanks Charles.