Skip to main content

Don’t Sell me Agile, Solve my Problem

Tim Wise
Reading: Don’t Sell me Agile, Solve my Problem

Sell

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.
snakeoil_trimmed
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.

Next Managing Risk and Uncertainty in Agile

Tim Wise is an Enterprise Agile Coach, speaker, and avid Agile practitioner. He grew up in large, corporate America and start-ups programming on multiple technology stacks with a focus on .Net. Although Tim honed his skills in development shops, he never saw IT as being isolated from solving real business problems.

Comment (1)

  1. Michele
    Reply

    Thank you! I’ve started to see that every level of the organization is sick to death of hearing the agile buzzwords, including ‘agile.’ While we as practitioners use these words as a short cut to mean so many different things, we’re alienating our audience. We need to turn this to the users perspective (sound familiar?) and come at it from their POV to get their buy in. The practices and techniques we use are merely what we have in our ‘tool belt’ that have proven effective – with roots in Lean, Agile, or PMI – doesn’t matter. Excellent points made!

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

What is the Worth of a Good Product Owner? w/ Tim Wise

This week, on SoundNotes, we’re featuring another question from a student in one of our Certified Scrum classes. The question came from someone who’s working in an organization that doesn’t see value in the role of Product Owner and isn’t convinced that it’s needed as part of the Scrum Team. The question: What is the […]

How Do I Use Scrum on Data Warehouse Projects? w/ Dave Nicolette

In one of my recent Certified Scrum Master classes, I had a number of students who were working on projects involving migrating from a legacy data warehouse to new data warehouses. Figuring out how to apply Scrum to the work they were doing presented a number of challenges and left some open questions.  Here are […]

Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.” Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly. Consistency Between Lean and Agile Principles Without coming at the […]

Prioritizing the Work to Maximize Return w/ Dennis Stevens

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return. During […]