Agile Culture Part 2 - Strive For Quality

Last time we looked at supportive leadership and how that can really let people in an organisation become empowered.That feeling of empowerment will vanish pretty quickly if they feel that they just aren't achieving good results. Nothing is more demotivating than feeling that you have worked all day and achieved nothing, or made things worse. This is where quality comes in. People need to feel that they are doing a quality job to be really happy. Pride in your work is one of the biggest motivating factors out there. Quality is also great for an organisation. After all, if it's not producing quality, how likely is it to stay in business long term?

Now, when I mentioned quality, I'm betting a bunch of you immediately thought about things like defects, and testing, That's what most people associate with quality - building the thing right. But that's not all there is to quality. By itself, building the thing right only ensures that what you build is defect free. Is it the right thing? Building the right thing is an even more important aspect of quality. And what about the way we build it? Is it quality if our processes are bad so that what we build is late to market or too expensive? An organisation needs to consider all 3 aspects of quality before they can really say that they are producing a quality product. 

The first aspect of quality is building the thing right. This is the one we always think about when we are talking about quality. We are generally pretty good at this one. As long as we do all the right things - automated testing, treating quality as everyone's responsibility (not just the testers), move testing to the left, all that stuff. Essentially, the question we should be asking ourselves here is not "did we build it right" and testing until we are satisfied that we did, but instead, "are we set up to build this right" and looking at our processes until we are satisfied that we can build something with no defects. It's pretty obvious these days and we should all have this down pretty well but it's surprising how often this basic stuff gets overlooked in the rush to get stuff out the door. Ignore the obvious stuff at your peril.

The second aspect of quality is building the right thing. Often this is completely ignored, or treated as someone else's job. It's the product folks who tell us what to build, they need to get it right, we just build it. That's rubbish. Ensuring that what you are building is the right thing is the responsibility of everyone in the organisation. Product folks, support folks, development folks, everyone should work together to ensure that what is being built is the right thing to build.

This is where an organisation can really become agile. The key to understanding whether a product is the right thing or not is feedback. From real customers. As early and often as possible. Coming up with a product concept, spending 2 years building it, releasing it to market and only then getting feedback from customers is a sure fire way to produce poor quality. Get feedback from real customers as early and often as you can.

Back in the 90's, Kodak established a consortium to develop the next generation of consumer cameras. It was called APS (Advanced Photo System) and was intended to replace 35 mm and Instamatic films in the consumer market. The program came in ahead of schedule, exceeded every one of its technical goals and was millions under budget. Was that a quality product? There is no doubt APS cameras were technological marvels. Small, feature-rich, superb image quality. But no-one bought them. APS went on to become the shortest lived film format ever produced. It was dropped in under 10 years. Why? Because it still required taking negatives to be developed. Right at the time APS was launched, the first generation of affordable digital cameras were launched. They were large, bulky and had poor image quality, but you could see and use the images instantly. That's what consumer photographers really wanted. Instant snapshots. Had Kodak (and partners) got feedback from real customers instead of forging ahead with their pre-defined plan, maybe Kodak would still be in business today.

You don't even have to build anything to get feedback. Just asking your user base (if you have an established one, that is) what features they would like to see is a great place to start. Show friendly customers paper prototypes. Set up a booth in the street and ask passers by what they think of your concept. Your staff are often customers as well. Ask them. If it's possible, use early builds internally to see what works and what doesn't. At Microsoft, the first thing people do every day is install the previous night's build of whatever product they are working on. The Windows team installs the latest Windows. The Visual Studio team installs the latest Visual Studio. If it's broken, it become really difficult to work so it gets fixed pretty quickly.

The organisation needs to get really good at identifying a proper, minimal, MVP and getting that in front of customers as fast as possible. They also need to be able to change when customers tell them to change. Many organisation are so set on their clever plans and strategies that when customer feedback comes in, it is routinely ignored.

The third aspect of quality - build it the right way - is almost never considered as part of product quality. The quality of the processes used to build the product are seen as a separate thing to the quality of the product. They aren't. The two are tightly linked. Poor quality processes build poor quality products. They may be defect free (unlikely with poor processes) but are likely to be late, expensive, have the wrong features, be hard to use and so on. The quality of the processes used to build the product are an essential part of product quality.

Organisations need to embrace all three aspects of quality - build the thing right, build the right thing and build it the right way. To do that they need to be able to learn and adapt. That's what we will look at next time - building a Learning Organisation.