Lesson 8: Quality is an uncommunicated expectation from your customers and stakeholders

Background

During one of my stints as a consultant, I joined a project already in progress at a fiberglass manufacturing company. The project was a custom development project where the team was rewriting the existing software used by manufacturing plants to manage their daily production metrics.

When I started on the project, I remarked to the team about the lack of any kind of automated tests, unit or otherwise. They recognized the problem but felt that management would never give them the permission to take the time to create automated tests against the solution. Does this sound familiar?

Outcomes

I put together some example unit tests against the existing code base and got the developers onboard. The team indicated that the next step was going to be much harder: get management to agree that the extra time in creating tests is worth spending in order to improve the overall quality. So, I put together a presentation in anticipation of the resistance we would experience from the managers and had a conversation with the three managers for the project.

To my surprise, there was no resistance. In fact, one of the managers said, “I thought unit testing was something that every developer did every time. Are you saying that’s not always happening?”

Mistakes

The mistake I made is a common one, and it’s called PWUA syndrome or Proceeding With Unverified Assumptions. The team made two assumptions. The first was that management knew the team wasn’t testing. The second was that management wouldn’t approve additional time and budget to add the testing they weren’t already doing.

For my part, I heard these assumptions and did nothing to verify, or refute, them prior to the conversation with the managers. This inevitably led to the awkward question “Are you saying that’s not always happening?”

Lessons

Certainly, an easy lesson here is to always verify assumptions. However, there is a deeper lesson that I learned in this situation which has been reinforced time and again in various projects and engagements: your customers and stakeholders always expect high quality. As a derivative of that, I suggest that given the choice between high quality and hitting a deadline, having high quality wins every time. Certainly, many people will yell and scream about hitting deadlines, but a deadline that is hit on time with low quality is always received worse than a deadline missed but with high quality. Every time. I guarantee.

Agile Reinforcement

The Agile Manifesto principle “Continuous attention to technical excellence and good design enhances agility” reinforces this lesson very well. Part of technical excellence and good design is making sure the solution has high quality. Testing is a very important part of ensuring high quality. Additionally, much has been written about the importance of writing code that is inherently testable. In fact, many would argue (and I count myself in this group) that part of the definition of good code is code that is easily testable. I can’t say enough good things about the test-driven development approach to writing software!

SAFe Reinforcement

From a Scaled Agile Framework perspective, there aren’t any principles that directly address this situation. However, I believe that the two principles “Build incrementally with fast, integrated learning cycles” and “Base milestones on objective evaluation of working systems” would have helped the team verify (or in this case, refute) their assumptions. In my experience, part of a good demonstration is showing off the build/deployment systems (sometimes called the CI/CD pipeline) along with the results of automated tests. Had the team performed an early demonstration that included a few automated tests, they could have gotten feedback much more quickly as to whether the tests were expected or undesired by management.

I hope my struggles and failures can help teach you this important lesson: Quality is an uncommunicated expectation from your customers and stakeholders.