I saw the following question in the group on LinkedIn:

As an Agilist, what kind of constraints do you use to ensure quality?

There were quite a few thoughtful comments, for example:

• Definition of and adherence to a – Definition-of-Done
• Collaboration and pairing
• Unit, integration, and regression testing
• Sustainable pace
• Measuring defect and process “escapes”
• Appropriate testing as EARLY as possible
• Having retrospectives – focused on continuous quality improvement
• Gaining quality feedback in the Sprint Demo
• Designing in Quality – at the beginning
• Metrics, measurement, and measure visibility
• Focus on getting the “right people”
• Establishing a DevOps culture
• Communities of Practice around Quality – establishing standards
• Writing test cases aligned with each User Story
• Pull metrics derived from the teams
• Focus on Value, not Quality, and

All of which sound like fine suggestions surrounding the question. But an ex-colleague and a friend of mine, , added this to the thread:

Culture has more to do with quality than anything else. You can measure number of escapes, try to enforce policies of defining doneness criteria, but none of those individual things are going to really do what you want, which is make your customers happier. Creating a culture that loves the customer, strives to get to know them better, and wants nothing more than to make their lives better is going to improve your “quality.” So long answer short, in my opinion you should focus more on building empathy between your team and your customer than you do on finding constraint.

Customer Engagement, Empathy, and Love

First I must say I was incredibly proud of Lee’s comment. I’d worked with him at a company called iContact for approximately three years. We were an agile shop and I believe some of his council is coming from his experience there.

One of the things we did at iContact that truly connected our agile teams to the customers was pair every team member with a customer support person on a periodic basis.

We were lucky enough that all of our ~70 customer support folks were in the same building as our cross-functional Scrum teams. Somewhere along the line, a policy had been established that everyone in the Technology & Product department would spend 2 hours a month tethered to a customer support engineer taking live customer calls about our products.

Was there whining and complaining about it? You bet. But the policy was firmly reinforced.

I must admit, I don’t particularly care for these sorts of prescriptive actions within agile organizations. But in hindsight, the policy had an incredibly positive impact.

It forced everyone in the Technology & Product departments to:

• Face our customers; listen to them
• Face our Product reality in the Real World
• Face the challenges another team faced every minute, every day
• Face the true level of quality of our Products
• And finally to Eat our own dog food

Ultimately it built empathy, gave us information so we could improve, and to Lee’s point – apparently it helped build a culture around loving the customer.

In hindsight, I think that’s what ultimately drove our client successes at iContact.

Thanks Lee for sharing!

Stay agile my friends,

Bob.