Taking a Quick Step Back…

A few posts ago I mentioned that I roughed in some 20 plus articles I intend to write over the next few weeks. By the time this one goes out, I think you’ll have seen two or three of them. It was interesting to take a step back and see where my head has been these past few weeks.

There was a clear pattern emerging.

In any movement… and yes, I see agile as a movement… you have lot’s of different constituencies.

You’ve got consultants with something to sell. You have evangelists interested in advocating their particular point of view. You have thought leaders interested in advancing the state of the art. Each bring their own set of biases and their own unique perspective to the conversation.

(For the record, I fall into all three of these categories in some form or fashion)

As folks consume our collective wisdom on all things agile, many of them are not as well informed, or as well read, or even have the time and inclination to dissect, understand, package, or repackage these ideas to make them work in their organizations.

Many… not ALL of course… are operating from a partial playbook.

Given that…

I believe the principles behind agile are inarguable. I believe that many of the patterns and practices that make agile work are inarguable. I think agile fails when we implement these principles and patterns and practices in an inappropriate context.

Everything written by anyone that has ever written anything on agile is from their own context, their own point of view, and based on their own experiences. To assert otherwise is nonsense. When we package our agile experience up into a thing, all that context gets lost.

That said, the market demands a simple, pre-packaged solution. It demands a two-day training course. It demands an easy to read one-pager describing the process. The market wants agile to be simple and understandable. Something that can be purchased off the shelf.

The reality is that it’s nuanced. It’s unique to the organization. There are no simple answers.

As I started looking through my notes from the past few weeks, and in all honesty… my last few years of writing… my last few years of company building… and my last few years of consulting… it’s all about discovering language that helps people understand without pretending its easy.

Themes that emerged were around safety, leading change, dealing with resistance, failure modes, and success patterns. My brain is absolutely centered around the fundamental base patterns that work and how to break down barriers to their application in real companies.

My brain is focused on how to package all this stuff up into something that is marketable and meaningful, not necessarily by describing the end state, but by describing how to package all this up into a safe and effective model of iterative and incremental change management.

In other words, what’s the process of transformation. What do the intermediate states look like and how do we get there? There is so much noise in the system… so many competing points of view… how do we cut through the bullshit and get to something that works for us.

Shifting gears, a little…

This morning I woke up to series of blog posts and tweets lamenting the fall of agile. How agile doesn’t work. How we are post agile and that agile has failed. One of my favorite bloggers was debunking the latest agile myth in an attempt to bring some sanity to the conversation.

To some extent, I think we are experiencing a pendulum swing in the industry. On one extreme, we have the waterfall boogeyman, that for the most part has been roundly marginalized in the industry. Still there, but not very popular right now.

On the other extreme, we have a total anarchist view of agile based exclusively on empowering people to decide, telling managers to back off and leave folks alone, but failing to give the people spending the money any assurance they’ll get any value for their dollar spent.

The answer isn’t extreme control over every detail. The answer also isn’t total lack of control over time, cost, and scope constraints that give our investors some reasonable assurance they’ll get something of value for their money. For most companies, the answer’s in the middle.

So…

If you decide to pay attention as I get all this stuff typed out, what you are going to see is an exploration of the thinking tools, the organizational patterns, the failure modes, and processes I think are necessary to really lead change in large enterprises.

I’m not talking about the squishy, feelings related stuff, around change… but the hard… how do you actually do it kind of change. How do you form teams… specifically? How do you create a governance model… specifically? How do you measure stuff… specifically?

I believe there is a bunch of good that can be had by adopting a team-based iterative and incremental approach, out of helping people get clarity around what to build, and helping people understanding what to measure. I also think it’s okay to tell people how to get started.

If that’s too prescriptive to be agile… I’m good with that.