Summer Read Along: A Seat At The Table | Chapter 11 – Quality

In this series of blog posts, follow along as we revisit Mark Schwartz’s book A Seat at the Table: IT Leadership in the Age of Agility. Five years after its publication, it’s still highly relevant and chock full of tips, tactics, and learnings. Join us as we follow along with Online Marketing Assistant Lucy Softich as she reads through the book for the first time. Make sure you start with the introduction post!

Today we’re talking about Chapter 11: Quality. If, like we touched on in the previous chapter, we expand quality to include the security of a feature or process, does that change how we judge the objective “quality” of a product?

Failure as a Necessary Step

Mark begins this chapter talking about the role that failure (and defects) play in the natural lifecycle of IT. Failure isn’t seen as a problem, it’s seen as a step in the process to launching a successful product. It’s a part of testing, a marker that helps you focus your energy; a “canary in the coalmine,” as Mark puts it.

But, maybe we have become too used to this relationship with failure. Afterall, he explains that it is difficult to explain this acceptance of failure to other parts of the business, where failure is grounds for reprimands or even termination.

As Mark says:

We have to raise the bar on impeccability. Just because we accept failure doesn’t mean that all failures are acceptable. We owe it to the enterprise to approach closer and closer to impeccability, and we have room to do so.

Tracking and Catching Defects

Mark has a lot of suggestions for improving our quality goals, and he starts with revising or outright removing defect-tracking systems. The idea of these systems is to record defects so that someone can go in later and address those defects, starting with the highest priority defects.

However, Mark argues that this system is often so cumbersome that it creates more work than just dealing with the defects immediately. He has a different recommendation.

There are only two types of defects: those that will be fixed immediately, and those that will never be fixed….There is no “later” when it comes to defects.

In other words, either defects are worth fixing the moment you find them, or they aren’t worth the time and effort of fixing at all.

The Power of Peers

Mark also has suggestions for discovering as many defects as possible, namely, peer reviews. These reviews can happen independently or as part of pair programming, but the important part is having a knowledgeable engineer addressing defects immediately instead of an engineer having to come up to speed with the project and manage the defects down the road. This philosophy of immediate action saves money and time, and probably some engineers’ sanity. 

Trust the Process

Mark suggests that the best way to cut down on the amount of failure we expect in IT is to reframe what we consider failure.

Part of our Agile approach…is to turn what would otherwise be quality issues into process: defects cease to be defects if they are just a normal part of how the sausage gets made.

In other words, if we’re moving through the DevOps process, testing our own code, and handling our own deployments, detecting defects is just a natural part of the process. It’s not a failure if it serves a purpose.

Next, we look at the last chapter in Part II: Chapter 12 – Shadow IT. (Sounds ominous)

—

Jump to a Chapter

Introduction & Chapter 1
Chapter 2: Kept from the Table
Chapter 3: A Nimble Approach to the Table
Chapter 4: Planning
Chapter 5: Requirements
Chapter 6: Transformation
Chapter 7: Enterprise Architecture
Chapter 8: Build Versus Buy
Chapter 9: Governance and Oversight
Chapter 10: Risk
Chapter 11: Quality
Chapter 12: Shadow IT
Chapter 13: The CIO’s Place at the Table & Chapter 14: Exhortation and Table Manners 

- About The Authors

Lucy Softich

Lucy is the Marketing & Social Media Coordinator at IT Revolution. She has a background in writing, marketing, and business.