The bitterness of poor quality
Recently I came across a picture online and posted it on twitter. I thought the quote made a lot of sense in an agile context, since in agile product development, quality should be considered in all stages, from early feedback from your customer to continuous integration on software teams.
I am not a very active twitter user, so I was quite amazed it was retweeted over 200 times! Apparently the quote on the picture resonated with a lot of people, which inspired me to write this post. I also did some further research on the origins of the quote. It’s not clear who was the original author, but some sources attribute it to Benjamin Franklin. In the picture the quote seems to be hanging in an old saw-mill, but it turns out that around 1930 many companies had this statement as their motto, to emphasise they were building products to last.
Product Quality
The statement still holds true today, maybe even more in the current age of globalisation, where customers have easy access to social media and online reviews. Although good quality is no guarantee for success, products and services with poor quality won’t stand a chance.
One of the Lean Principles states “Build Quality In”, meaning quality should be considered and validated in all stages of the process. Unfortunately many organisations still consider quality something which is only required at the end of the product development process. There are different aspects to quality to be considered during the product development cycle. Quality is more than just preventing defects. A product with no or few defects will not automatically be considered a quality product by your end users.
When using an agile approach, the result of each iteration should be a ‘shippable product increment’, which we can inspect and validate against acceptance criteria and non-functional requirements on a User Story level. But we are also able to assess how the product holds up against the Product Vision we are trying to realise.
There is a good reason product backlog items are defined as User Stories in agile approaches, it emphasises the need to focus on User Value. Yet many organisation do not involve actual end users at all in their product development process, or if they do it’s only at the end. So try to involve users in early stages of the process, and focus on shipping minimal viable releases of your product to end users to validate it in the market.
Technical Quality
Next to validating product quality, we need to assess if our product conforms to our internal quality standards. For example browser or device compatibility, load and stress the product should be able to handle, connection and session handling, etc. When these aspects are validated only at a late stage of product development, the consequences can be quite severe.
Imagine you have delivered 10 iterations of functionality, if you discover some components added in the first few Sprints are not able to handle a certain load, you will have to go back and rethink the approach you took months ago. At the same time the functionality which was added later, may have been dependent on these components and thus will also be affected, introducing a lot of unexpected rework.
Regression
Regression in software is considered to be the introduction of defects by changes in code, configuration or libraries. When you are only focussing on validating the new functionality added in an iteration, you will not discover regression defects in existing functionality.
This is one of the biggest challenges when teams move to an agile approach. In a waterfall project you had a big test phase at the end where all the integrated code was manually tested. But when you are delivering integrated code every iteration, you can’t really afford to run all manual tests every time. The only real option you have is to automate your tests, so you can run them continuously without much manual effort.
When your code is well covered by unit tests and integration tests there is another advantage, in stead of finding the bugs at the end, you can discover them quickly, it’s a good practice to run unit tests often from your IDE, allowing you to quickly see if the few lines you changed are breaking any tests. And when they do it’s usually obvious how to fix it.
Quality is Free
Another quote I love is one from Philip B. Crosby: “Quality is Free”. This quote is from the sixties, and wasn’t really intended for Software projects back then, but it actually does apply there too. What he meant with the quote was that any investment you make to prevent defects will pay itself back.
When you consider the cost of resolving defects and the time of discovery, you will find it is quite worthwhile to invest in unit test and integration tests.
How to get started
When you are dealing with a legacy code base without unit tests, it’s usually not an option to stop adding value and write unit tests for months. To get started you can start small, for example, agree to add one unit test this Sprint, the next Sprint cover a full story, until the team is ready to cover all new functionality with unit tests. Integration tests can be started the same way. Your velocity will be lower in the beginning, but you will soon see the amount of time teams spend on fixing defects drop, thereby increasing and surpassing your initial velocity.
Teams can also consider to write unit tests for defects found after the Sprint is complete. The reason these are found is usually because parts of the code are not covered by tests. You can start by adding tests for blocker and critical bugs, thereby making sure these particular situations will be covered by unit tests from now on. Next to unit tests, teams can also add automated integration tests in the same way.
Developers should get used to the habit of running unit test suites often from their IDE or command line. But it is also quite useful to have a continuous integration server, which monitors your version control system and validates all tests pass and build are successful.
No time to waste, start investing in your quality and productivity now! Your customers will love you for it.