Don’t Sell me Agile, Solve my Problem

Last Updated on Wednesday, 16 April 2014 02:18 Written by Tim Wise Tuesday, 25 February 2014 08:08

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.

Don't Sell me AgileWe 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 decrease 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.

webinar ad

Learn More

Big Agile Book Structure

Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Monday, 7 September 2009 12:27

I’ve been consumed lately thinking through the story our book is going to tell. Great stories have a beginning… something that gets the reader hooked. They have a middle where the reader gets some background and begins to develop a relationship with the characters… they begin to care. Great stories have a climax and a resolution… that place where the drama reaches its peak and everything gets packaged up neatly in the end.

When I’m reading a good book… I always wonder if the author knew exactly where they were taking the characters when they started… or if the whole thing was just an emergent stream of consciousness? I’d have to figure it can go either way… depending on that writers individual style and approach to book writing. Since this is my first book… I don’t know that I have a style yet… but I am definitely gravitating toward the more purposeful approach.

If you spend more than a few minutes with me… you’ll find pretty quick that I am a big picture guy. I’ll do the details with you… but only after I have a framework to hang them on. I have to understand the big picture first so all those details have a place to live… an anchor point… in my brain. My learning style is heavily dependent on pattern recognition so I get impatient if I don’t have a pattern to understand what is relevant and what isn’t.

Just a quick aside… if you write a blog post and I can’t tell what you are talking about within the first few sentences… chances are I won’t finish your post… just sayin’ ;-)

Images Courtesy of Jeff Patton

Anyway… because I will probably assume that everyone else’s brain works the same way… or maybe just because I need to be able to understand my own book… the structure of the book is really important to me. I’ve gotta have a place to hang all the details. To that end… I see three primary sections in our final manuscript. The first section will tell the entire adoption and scaling story. If you read these first few chapters… you’ll have the big picture… all you need to give the details a home.

Next… we’ll get into the real meat behind our model. There will be a subsection for each of the five adoption phases. Each section will describe the problem… the common challenges… and who will likely care about the things we are going to talk about. After that we’ll explain the relevant capabilities in pretty good detail and suggest several practices that might be effective developing the capability.

We want to address how the organization facilitates the conversations by talking through a pretty detailed capability analysis model. We’ll then deal with common risks and impediments that might get in your way. I imagine that each subsection will end with a discussion… maybe a case study… that ties everything together and highlights the key learning outcomes for the manager and the organization. We might add a few tables explicitly mapping capabilities to practices to help out all those folks out there that like to think in pictures.

Finally… we’ll close the book with a section that wraps up the entire story. I think we’ll have a few closing chapters… maybe appendices… that talk about several tooling approaches we’ve used to enable these kinds of conversations… and maybe even some discussion around advanced applications of our approach.

So there goes… a beginning… a middle… and an end. Any feedback?

Learn More