What Drives Quality – 1st edition (paperback)What Drives Quality – 1st edition (paperback)

What Drives Quality – 1st edition (paperback)

(5 customer reviews)

17.49 (Excl. VAT)

With plenty of ideas, suggestions, and practical cases on software quality, this book will help you to improve the quality of your software and to deliver high-quality products to your users and satisfy the needs of your customers and stakeholders.

Author: Ben Linders
1st edition
116 pagina’s
Self Published
January 18, 2018

10 in stock (can be backordered)

SKU: 9789492119179 Category: Tags: , , , , , , Created by Ben Linders

Frequently Bought Together

What Drives Quality – 1st edition (paperback)++
Price for all:   31.47


The book What Drives Quality explores how quality plays a role in all of the software development activities. It takes a deep dive into quality by listing the relevant factors of development and management activities that drive the quality of software products. It provides a lean approach to quality by analyzing the full development chain from customer requests to delivering products to users.

The book is intended for software developers and testers, architects, Product Owners, agile coaches, Scrum masters, project managers, and operational and senior managers who consider quality to be important.

If you buy the paperback edition you get a free copy of the What Drives Quality -1st edition (eBook)!!!

Note: This is the 1st edition of What Drives Quality. A 2nd edition of the book is in progress. Until it’s released you can only buy What Drives Quality- 2nd edition on Leanpub as an eBook.

About the book

The book starts by explaining what driving quality is all about. Next, it describes factors that drive quality in software activities done by development teams and explains what senior managers, operational managers, and project managers can do to support teams in pursuing quality.

Practices based on the quality factors are described in each section, with suggestions on how to apply them. The aim is to help you to improve the quality of the products that you deliver to your customers and end users.

The book provides stories and case studies showing how the quality of software products can be improved. They are based on my experience working with teams and managers, helping them to face and solve quality issues, and improve their performance for sustainable and lasting results.

A small but powerful book which, just like my successful first book Getting Value out of Agile Retrospectives, provides many ideas, suggestions, and examples that you can use in your daily work.

From the Foreword

This book is a succinct summary of what we know about software quality and how to apply it. It can be read in “agile time”, and delivers a solid overview that can set readers on course to higher quality, lower risk software. This book is a valuable contribution to professional software engineering practice. Half of the book is devoted to agile quality techniques. Ben’s objective is to make sure the speed of delivery is matched by the speed of assurance.
Bill Curtis, Director of the Consortium for IT Software Quality

Additional information


5 reviews for What Drives Quality – 1st edition (paperback)

  1. Shirly Ronen-Harel, Co-Founder & Agile / DevOps Coach – WeChange

    I like the fact that, finally, requirements practices are recognized in the book as part of quality. As an agile coach I give a lot of attention to them. And of course, the concept of the team as described in the book, which is an important driver for quality. i will recommend the book for sure.

  2. Scott Duncan

    In the early 80’s I worked for a small company doing mainframe 4GL product development. One year, it was decided to do a major overhaul of the query/reporting side of the product. It would be shown to customers at the annual customer meeting the next Spring (about 10 months away).

    There were four of us (developers) working on this. We had our own office but were no more than about 30 feet away from one another. There was a lot of back and forth each day and sharing of code/ideas, but something different from other work was that the four of us met each week with the tester for the effort, the tech writer doing the user documentation, and the marketing lead for the work. This was a review of what we had accomplished that week, a discussion of our next steps, and information from the marketing lead about feedback from customers based on release of information about the high-level plans for the release.

    We ended up basically rewriting everything in the query/reporting part of the system and finished a couple months ahead of schedule (no significant overtime was involved) allowing us to add some further features the customers weren’t expecting. It was my most memorable development experience (though I had other good ones). After doing some natural language query work, I left that company and got back into a couple strictly phased-sequential (waterfall) environments.

    About 20 years after that early 80s experience, I read “eXtreme Programming Explained” by Kent Beck and encountered the Agile Manifesto that had been released the year before. That prior experience suddenly clicked with me. We weren’t really practicing XP or all of what the Manifesto recommended, but it seemed like a lot of it. My first experience really trying to apply Agile ideas was with a marketing team not doing software at all because where I worked (as a traditional process/metrics consultant) didn’t want me messing with the actual software process.

    One year later I left, started working for a very small consulting firm doing regular software quality training/consulting, and began studying Agile frameworks and practices. A year after that I got my CSM by taking a class given by Ken Schwaber and Mike Cohn. I’ve never looked back after that so it’s been 14 years of taking an Agile approach to my training and coaching enriched by many of the good things about traditional quality and development ideas I’ve learned throughout my 46 years in software.

  3. Shane Hastie, Director of Agile Learning Programs at ICAgile

    Ben’s book is a reflection of his deep knowledge and experience helping teams and organisations identify what quality is in software, why it matters and how to optimise the right qualities for a product. He explores how quality is impacted by the organisational processes and from the perspective of the individual contributor, and gives concrete, tangible advice on how to make better products which meet customer needs effectively. He does this in an entertaining and interesting writing style.

  4. Shiv Sivaguru, Advisor and Coach at PM Power Consulting

    Congratulations on putting together a veritable index of various resources related to understanding aspects that drive quality in a software development lifecycle. This is a must-read for all persons contributing to the development or enhancement of software.

  5. Jens Woinowski

    TL;DR: Great book on software quality, whether for application in agile teams or others. Short and comprehensive, yet useful and challenging.

    This book is a resource for anybody who wants to understand software quality and is looking for practices to achieve it. It is a comprehensive overview of the challenges on the way to quality software products and how to tackle them. Ben Linders’ long experience as a software and quality professional is clearly visible throughout the whole work.

    The two main sections are a “Deep Dive into Quality” and “Quality Software with Agile Teams.”

    In the deep dive section, Ben Linders introduces general concepts of software quality and the Quality Factors Model. This part also contains a lot of references for even deeper discussions of any quality related topic. This makes the book a starting point for further learning for people new to software quality and a memory refresher for experienced readers.

    As remarked in the foreword by Dr. Bill Curtis of the Consortium for IT Software Quality, the book “is not a compendium of everything known about software quality. Rather it is a succinct summary […].” The only downside to this is that people completely new to software quality may be shied away by the sheer amount of things that are covered only briefly.

    Thus the book simply reflects an old dilemma of software quality: many IT professionals intuitively know what it means but they do neither fully grasp the holistic challenges it creates nor do they understand the lingo of quality professionals. This professional language may also make the book a little harder to read if one is not a quality expert or at least an enthusiast.

    The second main section – about agile approaches – is the true heart of the book. It contains a large amount of practical experience, applicable examples and real-life case studies. It bridges the gap between the complex challenges of quality outlined in the deep dive section and the hands-on world of agile practitioners.

    The two biggest assets of this section are rightfully at the end of it: agile retrospectives and root cause analysis. The retrospectives discussion wets the appetite for Ben Linders’ earlier work about agile retrospectives (if one does not know it already, that is). The root cause analysis addresses a potential weak spot of less rigid ways of working, namely the fixing of first order symptoms instead of systemic, deep rooted issues. Root cause analysis is also a gentle introduction to true systems thinking, which is sometimes forgotten over the agile strive for simplicity.

    Because the agile section is easier to consume, a reader new to software quality might consider to read the agile section first and the quality deep dive second. This gives a more bottom-up approach to the topic. Similarly, agile practitioners may like this reading order better as well. It appeals more to the empirical mindset than the theory first approach of the book.

    There are two things missing that could make the book an even more valuable resource. Firstly, it might benefit from some graphical elements, e.g. overviews of the Quality Factors Model in various degrees of detail. Secondly, there is one thing not discussed in any detail that drives both software engineers and quality experts: the passion for quality, including the personal and professional commitment to deliver it. This intrinsic motivator is the one thing that can make people tackle the obstacles on the way to quality.

    The latter is addressed by the bonus Agile Quality Cards game which Ben Linders offers on his homepage. These cards help software teams – and not only those working in an agile mode –approach quality from a more light-hearted angle of attack.

    Final remark: this is not a book to read once and then to forget. It deserves a deeper study and that one tries out the practical approaches in real life.

    • Ben Linders (store manager)

      Thank you very much Jens for your extensive review of my book What Drives Quality and the Agile Quality Coaching Cards.

      Writing the deep dive chapter posed challenges, one being that there are so many things that I wanted to have included. I’ve been working on a second edition of the book that actually goes deeper on some of the stuff in this chapter (making it feel less of an overview and more practical), it’s available on Leanpub: What Drives Quality – Second Edition.

      Very happy to see that you include the Agile Quality Coaching Cards in your review. As you mentioned, they make it easier for teams to discuss quality aspects and practices. They can be used stand-alone or can be combined with the Agile Self-assessment Game to add gamification which enhances engagement and involvement.

      Again thank you very much for the book review!

Add a review

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.