Q&A on the Book What Drives Quality

Regular InfoQ contributor, trainer, coach, adviser, and quality expert Ben Linders has recently released a new book. Titled What Drives Quality, the book presents techniques and tools to improve the internal and customer-visible quality aspects of software products. 

InfoQ readers can download a sample chapter of the book and it can be purchased here.

Linders spoke to InfoQ about his book.

InfoQ: Why did you write it – what is the problem you are looking to help address?

Ben Linders: What Drives Quality is a practical book with many techniques and ideas to improve the quality of the products that you deliver to your users.

In this book, I explore how quality plays a role in all of the software development activities. It provides a lean approach to quality by analyzing the full development chain from customer requests to delivering products to users.

Practices and suggestions are provided to improve the quality of the products that you deliver to your users. They can be applied in waterfall or iterative projects that for example use Prince-2 or RUP, by agile teams using frameworks like Scrum, Kanban, or XP, and in organizations that are doing large-scale agile software development with, for instance, the Scaled Agile Framework (SAFe), Large Scale Scrum(LeSS) Disciplined Agile Delivery (DAD), Nexus, or Agility Path.

The book started from the blog post series What Drives Quality which is based on the research that I did with the Software Engineering Institute (SEI) and my experience working as quality and process manager in large organizations. The first editions of this book were a Minimum Viable Product to explore if people are actually interested in software quality. I found out that there is an audience for this book – there are sufficient readers who feel that quality matters. 

Quality is important for every piece of software. For software that is part of an airplane, car, or medical equipment, quality is essential as lives may be at stake. Mistakes in financial software can be very costly (some companies lost millions due to a small bug). Flight control systems at airports should be reliable and available to prevent planes being grounded. The list goes on and on.

Also mobile apps need to have high quality. We’re moving into a mobile world where many people use apps every day for all kind of things. They expect apps to function correctly and do what they expect them to do. If not, then they'll uninstall it, which means that you’ve lost a customer. Apps should be easy to use, fast, and reliable, hence their quality matters. The same is true for webshops; if it takes too long to order a product or when error messages keep popping up, then people will buy the product in another online shop.

InfoQ: Who is the book intended for?

Linders: I’m aiming this book at software developers and testers, architects, product owners and managers, agile coaches, Scrum masters, project managers, and operational and senior managers who consider quality to be important.

Having said that, I'm aware that this is a wide range of roles where there will be different needs. To address this I've organized the book into two main parts with sections: Quality Factors Model and Quality Software with Agile Teams.

In the Quality Factors Model part I explore the technical activities for developing software products and management activities which support software development. Each section takes a deep dive to explain factors that drive quality and provides suggestions for how you can influence them. There are for instance sections on requirements, coding, testing, project management, and senior management, which provide practices from various agile approaches. Readers can decide to only read the section(s) that fit with their role, or (highly recommended!) read all sections to get an integral view of quality and have an idea of what to expect from other roles.

The part Quality Software with Agile Teams contains examples showing how agile principles and practices can be applied to deliver high-quality software; stories and case studies from my experience working with teams and managers, helping them to recognize, face, and solve quality issues, and improve their performance for sustainable and lasting results.

Throughout the whole book, there are many tips where specific practices are described with suggestions on how to apply them. Also, there are many examples and cases from organizations that I have worked with in which I share my experiences. My aim is to support readers with hands-on solutions which they can use in their daily work to deliver high-quality products.

To give an idea how all of this looks, here are some examples from the book: 

• Craftsmanship is essential to deliver high-quality software. Some of the techniques that developers and testers should be familiar with are code smells, static code analysis, refactoring, pair programming, reviews, and inspections.
• Modern leadership approaches exist that enable agile teams to self-organize. Leaders, including Scrum masters, product owners and also CxOs, can use approaches like intent-based leadership, holacracy, reinventing organizations, and sociocracy.
• It's possible to build a business case for quality. You can use data that has been published about agile methods to raise funding for an agile transformation that enables your organization to deliver better products, faster. 
• Some of the main techniques to investigate quality issues and come up with preventive actions are agile retrospectives, root cause analysis, and serious games. The book provides specific techniques which can be used in such sessions to improve quality.

InfoQ: Quality is a word used extensively, and is often defined by its absence (“I know a poor quality product when I use it”), but what is quality in a software product?

Linders: The quality of a software product or system is primarily how it satisfies the needs of the users, customers, and stakeholders, and delivers value to them. This definition puts quality in the eyes of the beholders: the users, customers, and stakeholders who decide if a software product or service has sufficient quality, or not.

If the quality of a software product is insufficient according to the users, then they will not use it. If the customers or stakeholders do not get enough value from the product, then they will not buy or support it. Satisfying the needs of all is crucial for software (or any) products to be successful.

The easiest way to find out if the quality is sufficient is to ask the users and stakeholders. Agile teams use the product review/demo for this; it's a great opportunity to get feedback, provided of course that you facilitate it in a good way.

Teams can only deliver quality if they know and are driven by the needs of the users, customers, and stakeholders. But how can you ensure that you are able to develop products that meet these needs? This is where an internal view of quality helps us. An internal view looks at the architecture and design of the software. It explores the processes and practices that are used to deliver the software. It focuses on the culture of the company, leadership, goals, and reward systems that drive the right behavior. All of these factors drive quality, but depending on how your company is doing and the context it is in, some of them may be more relevant than others.

As an example, one of the suggestions provided in the book is to throw old smelling software code away. Isolate the software modules that are costing you lots of time and money to maintain, delete them, and rewrite the code in a proper way. You may also use sampling or static code analysis to measure the quality and know what to keep and what to delete. Ok, maybe you cannot simply throw away whole modules; then refactoring may be a solution to remove bad code and replace it with better code. My advice is to dispose of bad code as soon as possible and not waste time and money on it.

InfoQ: You talk about a wide range of factors that contribute to the quality of a product, much more than just the developer’s skills.  What are these and why do they matter?

Linders: When you view software quality from an engineering, management, and social perspective, there are many factors that influence quality. Based on my research and my experiences I organized them into technical and managerial activities. 

Some examples of factors that drive quality are:

• The quality of user stories which teams use to communicate with users and stakeholders. Suggestions to improve them include INVEST, acceptance criteria, and a Definition of Ready.
• DevOps practices like automated testing, continuous integration, and continuous deployment. These practices help you to establish a development pipeline that enables smooth delivery and quick customer feedback.
• Managers can implement a quality culture; the first step is to recognize how the existing structure and processes discourage quality. Suggestions provided in the book are to remove barriers and impediments, break down walls that hinder collaboration, use modern leadership approaches, and give professionals room to do their work in a good way.

End-to-end collaboration is essential to deliver high-quality products. There are many great books that zoom into quality aspects in different domains of software development. Think about defining customer needs/requirements/user stories, software craftsmanship, QA/testing, DevOps/continuous delivery, and managing agile teams and organizations. But until now there wasn't a book that ties it all together. 

In my book, I explore practices from the different domains using an integrated end-to-end quality framework. This book enables professionals working in different areas to build a shared view of software quality and work effectively together to deliver high-quality products.

InfoQ: One whole chapter is named “Quality is Free” – surely it costs more to build a higher quality product?

Linders: We know that building the product is only a small piece of the investment; far more money is spent to maintain or enhance software. This was true when waterfall was used, and even more with agile. The intrinsic quality of software has a huge impact on the total lifecycle costs of software. Building quality in from the start is much cheaper than incurring and paying off technical debt.

In 1980 Philip Crosby wrote the book Quality is Free. In his book, he explained how investing time and energy in building the right products with good quality will save money and time, and how it also makes you cheaper and faster than your competitors.

Agile teams know how important software quality is. Debugging software and solving defects is expensive. Writing software using good engineering practices doesn't have to be expensive; in the long run, it's actually cheaper.

Money is wasted by putting pressure on teams and expecting them to take shortcuts. My book provides "ammunition" for teams to convince their managers and other stakeholders to get time and space to focus on quality and do their work in a good way. Better software, cheaper, and faster, what more can you ask for?

InfoQ: What are some ways that quality can be improved in software products?

Linders: High-quality software is built by people. To improve the quality of existing products, they may need to develop additional skills, both technical and social skills. A combination of workshops to practice their skills and coaching on the job often works well.

The book provides many techniques that help to deliver high-quality. You don't need to learn all of them- it's like being chased by wolves where you don't need to run faster than the wolves; beating the other people is enough. The trick is to know which techniques are most effective given the situation/problem at hand and be better than your competitors in applying them - then they will be the ones that the wolves will kill instead of you :-)

To find out which techniques might be suitable I suggest applying problem-solving approaches, like root cause analysis, agile self-assessments, and retrospectives. Every Scrum master, tech lead, and manager should learn how to do that.

The book provides new retrospective exercises on top of the ones described in my first book Getting Value out of Agile Retrospectives. Retrospective facilitators should know these exercises and have the skills to apply them to help teams to explore causes of bad quality and define effective actions.

About the Book Author

Ben Linders is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of Getting Value out of Agile Retrospectives, Waardevolle Agile Retrospectives, What Drives Quality and Continuous Improvement. Creator of the Agile Self-assessment Game. As an adviser, coach and trainer he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Linders is an active member of networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English) and as an editor for Agile at InfoQ. Follow him on twitter: @BenLinders.