Don’t Sell me Agile, Solve my Problem

A while back I was invited to the AITP Atlanta Chapter for a CIO roundtable discussion that involved questions on agile. The event was a great success and I came away with a bunch of great insights into what topics are on the minds of today’s CIO. One statement that night has really stuck with me.  A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.”

That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.

We don’t sell vials of snake oil.   Here’s why that may be the perception.

Let’s consider the state of affairs for a moment.  When I get the opportunity to have a discussion with a new organization, the person I am talking to needs me to solve a problem.  They might not know anything about agile, scrum, kanban, or any other process.  Alternatively, they may have experienced a poor implementation and have an immediate bias to any of the “agile” words (i.e. sprints, daily scrums).

If I am selling them something, I genuinely want to solve the problem, not implement agile.  That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer.  It breaks down zealotry and keeps me honest.

In the end, I am directly and intentionally not talking about agile, scrum, kanban or lean or anything else that is under the agile umbrella.  I simply want to know, what is the most impactful issue that their enterprise is facing right now in their unique context.  Can I solve it?  No, but we (myself and the enterprise) can.  It must to be a partnership though to be an effective sustained transformation.

Here’s the catch.  Most, but not all, issues will fall into one of several categories.

• Time To ROI
• Predictability
• Quality
• Adaptability
• Economics

Though categorically these problems are recurring across many business enterprises, the underlying causes can be a complex, interwoven gobbledygook of methods, procedures, and people.

That’s why it’s important to listen and offer up expertise when you understand the problems. It’s an engaged dialog that I am targeting to create a shared understanding of their problem so we can work to create a vision of our solution.  I’m not there just to lend an ear.  That’s why I need all this experience stuff.

Speaking of experience, I have found commonality among the solutions for each of the categories listed above.

Let’s take Predictability.  In order to become predictable, most organizations will need to learn how to systematically decrease batch size, reduce WIP at the enterprise and team levels, and stabilize teams.  Inherently, this will increase quality and decrease Time To ROI.  To further improve those, I will need to run experiments on their unique context.

How do they begin to get predictable?  That’s what they need help doing. It’s what scaling agility is really all about. Getting more value out of the system to increase time to ROI and predictably make and meet corporate goals.  Informed, predictable returns on investment.

At my core, I believe a predictable system is one that we can run experiments on and get most other problems solved.  That’s my key to unlocking the shared potential of both parties.