The Agile Advocate is a series of thoughts or musings on the agile movement and DevOps in particular. It was motivated by the seminal work of social philosopher Eric Hoffer, "The True Believer" (1951) — at least in structure. It's not meant to be a manifesto, but simply a series of thoughts and reflections coming from over three decades of developing and delivering software and systems of a wide variety to an even wider variety of users and customers. My aim is not to evangelize or convert, but to provoke and stimulate discussion.
“We need more product!” “No, we need more quality product!” How many times have you heard that? But do we really need more product? Or more importantly, does our customer simply want more product, even more quality product?
Or does our customer want a product that improves their ability to perform their job? A product that makes a significant and substantial improvement in the way they work on a day-to-day basis. Something that provides a positive outcome, not simply another shiny rock they can pretend to use and simply put on the shelf — next to the other shiny rocks.
More and more organizations claim to be pushing product at ever-increasing rates with daily or even hourly deployments. But what are they really delivering?
What I’ve seen, and even been a part of myself, is geared more toward product and volume rather than being customer and outcome centric. Here’s some of the primary impediments I’ve observed hindering organizations from providing outcome that positively impacts their customers lives rather than simply more shiny rocks.
Degrees of Client Separation
It never ceases to amaze me how organizations, both public and commercial, with direct access to their customers fail to take advantage of it. As a former product manager, I worked very hard and even paid for customers to provide feedback and share their priorities through focus groups and product conferences. And the reason was very simple: This feedback was our guiding light along the path to delivering not only a quality product, but more importantly, a product that made a significant and positive outcome in performing their job.
If you’re developing a product or system for an end user, identify a customer or customers who can serve as a point of contact and provide representation for the customer target. Develop real, substantive relationships with those individuals — no matter how painful it may be for either side.
If you can’t get a one-on-one relationship, then strive to keep the degrees of separation from your customers to an absolute minimum. When the degrees of separation start getting to two and even three degrees, then you stand the risk of losing touch with the customer’s real needs and priorities. And when that happens, you're forced to guess and speculate and the ability to course correct based on real customer feedback is significantly hampered, if not eliminated.
Pretend and Arrogant Certainty
We love certainty. And why not? It provides us with a sense of security and well-being. When a manager stands up and confidently proclaims her certainty in the outcome of a particular endeavor, we applaud her leadership. But if we really dig into that proclamation, you’ll see her certainty is some mix of arrogant and pretend certainty.
The pretend certainty comes simply from the fact that we expect those in leadership and management positions to “know” or be certain about where we are going and where we are going to end up. Because to say you don’t know would question your ability to lead.
Arrogant certainty comes from just that, arrogance. The perception that somehow you know more than the customer and you’ve figured it all out from the beginning. You’ve stated the end product and charted a course, and will proceed along that course be damn of where it takes us or if it results in an end product that brings any real value to the customer.
No matter where this certainty comes from, it’s in complete contrast to an agile mindset. You need to put aside the desire for certainty and instead adopt a discovery mindset. A discovery mindset understands that while you're starting with a plan, it’s just that — a plan. It’s a starting point with a vision of where you want to go — or at least where you think you’ll end up — as far as you know right now.
With a discovery mindset and agile practices, you’re constantly learning and discovering where your customer wants to go and can react to their changing, shifting requirements and priorities. The discovery mindset is not bogged down by certainty but embraces the idea that plans change and we are never as certain as we claim to be. As a product manager, I was always amazed after delivering some functionality to my customers or releasing another version of the product how different the end product was from what I and the team had original envisioned.
Lack of Feedback Loops
But the discovery mindset is useless if one lacks the proper feedback loops to capture your customer’s assessments. In a previous article, “The Agile Advocate: Vectoring Development Toward Success” I talked about this exact kind of feedback loop in the software development process. It talks about continuous feedback from user interaction with demonstrable, functioning software provided by continuous integration and continuous deployment processes.
Issues and feedback are captured and routed directly back to the development teams to be incorporated into the next build at a cadence and rhythm that supports the customer — whether weekly, daily or hourly. It’s with these continual, fine-grained course corrections we move from an initial vision along a path to a product shaped by the customer. In doing so, we stand a much higher chance of delivering not just a product, or quality product but a product that provides a positive outcome for the customer.
And these feedback loops aren’t limited to the development phase. They should be incorporated all throughout the idea pipeline — from the recognition of an idea through to the retrospective after delivery. Each feedback loop allows an organization to apply a discovery mindset in vetting, crafting and delivering positive outcomes for the customer.
Outcome over Output
If an organization is truly interested in delivering outcome over output, then it first needs to adopt a true agile posture. This starts with ridding itself of the pretend and arrogant certainties and instead adopting a discovery mindset. Accept the fact that while you may have a plan, it’s simply a starting point along the eventual path to a viable outcome. Remove the degrees of separation between you and your customer. Embrace the customer as the source for course corrections ensuring your product is not just another shiny rock but something that provides a positive outcome instead.
And finally, create the feedback loops at each phase along the idea pipeline that will allow you to course correct to your customer’s real needs.
