18 Steps to Quality, Part 2
In my first post talking about the 18 steps of quality, I talked about the first 7 steps we use to ensure quality. Today I’m going to talk about the final eleven items.
8. Iteration Kickoff
9. Estimation
At Menlo both of these exercises happen during each weeklong iteration. Every week the team has two opportunities to come together and discuss the big picture. Unless everyone on the team is focused on a common goal it will be impossible to build a quality product. Spending the time to communicate up front to make sure the team is on the same path, prevents many defects from ever making their way into the system.
10. Continuous Code Review
11. Test First/Unit Testing
12. Continuous Integration
13. Refactoring
We have a tremendously rigorous set of development practices. These are not practices we use sometimes or when we feel like it or remember to. These are part of the code of ethics we live by. An application written without unit tests, continuous code review, continuous integration, and fearless refactoring is an application written to be thrown away. Where there is rigor there is quality.
14. Green Dotting
At Menlo no one is allowed to declare themselves done with a story card. Instead they have to ask their teammates to verify if they are done with the work. We call this green dotting. A simple way to increase the quality of your work is to have someone else check it before you move on to something new.
15. Show & Tell
Every week our client comes in for show and tell. This is a chance for the client to see the working product to make sure it is everything they imagined it to be. If something isn’t quite right, it is only a week spent off course rather than months or even years. Quality is so much more than answering the question of whether or not the application meets the specifications. The earlier you can get someone actually using the software being built, the better.
16. Build Testing
Every iteration we make a build. Every iteration we run a build test. For this we use exploratory testing. The objective is for the build testing team to put their end user hats on and use the application as a user would. There is no list of instructions for them to follow. On the contrary we want them to explore. We want them to be creative and most importantly we want them to run the test differently from the week before.
17. Client Testing
18. Beta Testing
We encourage our clients to also test the application. Since we do not typically have a domain expert on staff, we encourage our clients to designate one to testing the application whenever possible. We also encourage them to find a small group of beta testers within their clients. The earlier you can acquire feedback from real users, the more time you have to make the appropriate changes to the product.
Now you know our 18 steps to quality and why our phones don’t ring with support calls and why we don’t have a bug database full of thousands of bugs. Now you know why the end users of the products we build find them to be easy to use and why so many of our clients find their products quickly gain widespread adoption. Use our 18 steps. Make them your own and believe me when I say, it is fun to build something packed full of quality.