All about ... a quality product
Improving quality decreases costs. Decreasing costs improves productivity. Improving productivity captures the market. It's easy really, however, we often get distracted from our drive to deliver quality, perhaps jumping into reducing costs or aiming for productivity gains at the expense of quality. How should you go about it?
Earlier this year I was reading Out of the Crisis: Quality Productivity & Competitive Position, by W. Edwards Deming, and I found it interesting reading and very relevant to the world of software development.
The above diagram lays out the simple process for delivering business success, which was practised with religious fervour in Japan from the 1950s, and it's easy to see how this remains relevant today.
Improving quality decreases costs
We've all been there. We've pushed quality aside in order to speed up the latest release, and we inevitably have come up with shortcuts and hacks to do so, which after release will all need addressing in one way or another (refactoring anyone?).
Or we've realised that by focusing on keeping costs down we skip steps in the process, and we're now faced with a technical debt that needs repaying.
If only we'd have focused on quality. If only we'd put this as our leading goal, over time or cost.
Delivering quality will ensure that we:
Reduce the mistakes that we make, as we're constantly on the lookout for areas that compromise our quality
Reduce the re-working that will need to be done to bring the feature up to scratch, sometimes before release, but sometimes after
Reduce the snags we encounter when we least expect them
Reduce the costs, because of all the factors above
As yourselves truthfully whether the quality is your driver, and if not, what the real impact is on your business.
Decreasing costs improves productivity
With a development team of five members pushing to get a feature released every month, and we accept that in order to meet our monthly delivery that we will follow up a release with a week of refactoring and re-releasing, then through focusing on quality, we remove the need to refactor and re-release.
By doing some simple refocusing and ensuring we deliver quality, even if it takes us an extra couple of days per person, we take the productivity of our team from 15 person weeks (5 members delivering productive work for 3 weeks each) to 18 person weeks (5 members delivering productive work for 3.6 weeks), an increase of 20%.
If every person is only touching the work once and then pushes it out in a release, and doesn't have to re-work anything, they be moving directly onto new feature after new feature, as well as reducing the ongoing support overhead that most software companies suffer from.
Improving productivity captures the market
Once we've improved the quality, and then started delivering more features, we're able to approach our target market with a quality product that is always evolving, and at a lower, more attractive price as we're no longer paying for non-productive development time.
Our sales and customer success teams also start to become more productive, as they are now able to focus on delivering value-added services (new sales or upselling), as their time is no longer taken up with firefighting, handling support queries, and reimbursing clients who've been impacted by the poor quality of our product.
How to introduce this chain reaction to success
When you look at it in these terms it all seems fairly obvious, but there has to be a reason why we aren't all doing this now, and that reason is often 'management'. The people who are setting the strategy and leading the business.I'm sure that most people do not want to deliver a substandard product. Developers take pride in their code, and hate having to hack things around to get them to work. They want clear code that focuses on its task, is easily understandable, and is extensible. They don't want spaghetti code, with no real structure, and that runs the risk of failing if you touch even one line.
However, they're being driven by others in the business who want something for client X by this time, or who need sales figures to grow by 10% this month which means focusing on getting leads through the sales funnel at the expense of how we do it, or shareholders who need to see a better return on their investment over the next quarter.
We therefore need to have an environment where the management are on board with the quest for quality. We also need an environment where the team are able to question and challenge management when the focus starts to drift, without worry about a risk to their own roles.
Quality is a top-down strategy, which those at the delivery level are only more than happy to adhere to if given the chance.
Conclusion
The journey towards quality is a long one, and one that won't be completed without a few challenges on the way, but that doesn't mean we shouldn't try.
Whatever it is that we can do then we should start doing today.
As product managers, we should:
Ask more questions of our users about the why, what, when, who and where of their needs
Consider our feature in more detail, and from more angles, so that we've thought through more scenarios
Write clearer users stories, with more acceptance criteria, so that there's no ambiguity in what quality looks like for our new feature
Further information
Out of the Crisis: Quality Productivity & Competitive Position, by W. Edwards Deming
W Edwards Deming interviewed on his 14 points of management and the need for quality