Why I Joined LeadingAgile

People who know me well might be surprised to learn I’ve accepted full-time employment. I’m sort of an independent-minded person. So, here’s why. (It’s characteristically long-winded, so skip it if you wish.)

Backstory

In 2002, I was working as an enterprise architect at a mid-to-large-ish financial services holding company that operated banks, mortgage lenders, investment firms, and so forth. That was my 25th year in the information technology field.

I had reached such a point of frustration with the growing bureaucracy of IT organizations that my wife and I were looking into alternatives, like franchise businesses (Main Event, etc.).

Then a colleague at the company approached me. He said he knew I was on the way out the door, and asked me if I would be willing to work with him on one last thing before I changed careers. He wanted to assess the cost and value of the IT function of the enterprise, and then, based on lessons learned, see what could be done to improve it. I agreed.

Within a few months our small group had learned:

• The main problem was the existence of functional silos with numerous cross-dependencies. These dependencies caused so much delay that the organization might be likened to a set of interlocking gears so arranged that they couldn’t turn.
• Every January, the department launched 300 projects at the same time. Staff spent the next seven to eight months waiting to see which ones would crash and burn. Then they scrambled to complete the surviving projects before the December code freeze. January through August was “endless meetings season.” September and October was “death march season.” Then the annual code freeze. Time to recover before the next January.
• The cost of going through the formal bureaucratic process to request services from the IT department was so high that line-of-business leaders didn’t even bother to request things they wanted. Besides, if they requested something they couldn’t be sure it would ever materialize.
• Individual contributors had no idea of the context of their work. From their point of view, there was no coherent activity in the IT department; everything was just a series of disconnected requests for small tasks (add an index on this database table; open such-and-such a port on this internal router; add a field to this COBOL copybook; etc.).
• No one ever received any feedback about the downstream impact of their work. Were the architectural designs sound, or did people have to revamp them? Was the code okay, or did operations have to mess with it to get it installed? Did customers like the user experience, or was it horrid?

In today’s terms, you’ll recognize some of those symptoms as high WIP, dependencies, context-switching, overloaded queues, big-bang delivery, and matrixed organizations.

It was during this effort that we discovered the Agile Manifesto. We recognized in it the same values we were seeking. We reasoned that if there were enough people out in the world who were thinking along the same lines to have published such a document, then someone out there must know how to do this stuff. We looked for help and found ThoughtWorks. We went from there.

I said at the time that if “this stuff” didn’t stick, and the industry reverted to the status quo ante, I would bail. There are other ways to make a living besides the slow death of bureaucracy. I began my Agile journey with one foot out the door. In some ways this has been a Good Thing; it has kept me actively focused on value every day.

Did I bail? No: 2016 is my 39th year in the information technology field.

Here we go again

Ah, but there’s trouble in River City. Today, Agile seems to be all about peddling frameworks. You can become certified to teach a framework certification class by passing a framework certification class. It isn’t necessary to have worked in the IT field at all, let alone to understand how Agile thinking can apply to enterprise IT. There are some 400,000 Certified Scrum Masters, only a few of whom have ever written a line of code, worked as a tester, in operations, or in production support.

Some frameworks are meant for scaling team-level Agile methods. They operate by re-introducing traditional governance methods, and killing agility in the process. (See “Every Agile Scaling Framework in the World“)

Other frameworks are meant for de-scaling the organization. They operate by insisting upon radical structural changes on Day One; changes that are impractical in most cases.

The alternative, Kanban, (as defined by Lean Kanban Inc.) is a business organized around selling training courses. It’s more realistic and practical than any of the Agile frameworks, and yet it stops short of providing concrete guidance to clients. The approach is to train leaders (and coaches) and then let them chart their own path forward. Change their thinking, and then get out of their way. Not a bad approach, actually, but it may not go quite far enough.

Agile conferences are 99% about playing board games, sticking notes on the walls, bending pipe-cleaners, and constructing things with little plastic building blocks; and 1% about addressing business needs through Agile thinking or advancing technical excellence through sound software engineering practices.

Agile consultancies that used to help clients solve problems and achieve goals have devolved into sales organizations for “frameworks.” It’s easy money. I know a number of people involved, and they know better than to do this. It really hurts my heart to see them selling their ethics this way. I guess that sounds maudlin, but at least it’s sincere.

Maudlin or not, I’m far from alone in this assessment of the state of Agile.

Four members of the ScrumAlliance board resigned within two months of the date I wrote this. They gave generic reasons, but two of them mentioned that the organization was going in a direction inconsistent with the values expressed in the Agile Manifesto. (I don’t know how long this link will remain valid, but here’s their letter of resignation.)

More than a few people are disappointed with the way things have been going. Here’s an excerpt from a piece by James Grenning on Quora.

Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They tell me agile is horrible. I ask why. Reasons that stand out are:

• We’re being micromanaged
• The pressure is constantly on for every two week deliveries so quality suffers
• All they care about is the date

Unfortunately, none of those activities are part of Agile, though I can see how it comes to be. The usual starting point is one of mistrust (note they above). Then you get a Scrum Master with two-days of training and pressure for two week deliveries; engineers will get the idea they are the Scrum Slaves.

Another of the Manifesto’s authors, Ron Jeffries, has had occasion to question the direction in which the ideas have been taken. Here’s an excerpt from an article on his site entitled “What I wish we had done…“.

As a faithful reader, you’re probably aware that I believe that the word “Agile” should mean “consistent with the Agile Manifesto”. And, of course, it doesn’t mean that at all. Instead it means whatever the word’s user means at that moment. There’s great confusion as a result. Ah, well, life is tough, then you die. Quickly, I hope, but not soon. But I digress…

An important contributor to the confusion is the proliferation of branded or named methods and frameworks. At the time of the Manifesto, if I recall, there were Scrum, XP, Crystal, and DSDM. Anyway right around that time, Jim Highsmith came out with Adaptive Software Development, Mike Beedle began a series of names like XP@Scrum, and it went on and on. It continues to this day.

…Point is, there are a lot of them. I don’t think we really need a “method” at all. I feel quite sure we don’t need a dozen…

Dave Thomas wrote, in a 2014 piece entitled, “Time to Kill Agile”.

The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.

Another Manifesto author, Brian Marick, has recently reanimated his 2009 idea, “Artisanal Retro-Futurism Crossed With Team-Level Anarcho-Syndicalism.” The name is designed to be descriptive of the underlying concept while simultaneously hard for people to cargo-cult. It’s intentionally non-catchy. The catchiness of the word “agile” has backfired.

Those comments come from authors of the Agile Manifesto. They aren’t alone. There’s a lot of disillusionment going around these days. I sympathize. Sometimes it feels as if the entire Agile movement is going in a direction inconsistent with the values expressed in the Agile Manifesto.

The whole thing with “scaling frameworks” has gotten totally out of hand. On a recent subcontracting engagement, I was tasked with helping the prime contractor’s client adopt the Scaled Agile Framework, a.k.a. SAFe. It didn’t take long to observe that the framework was a poor fit for the organization’s transformation goals. They were wasting massive amounts of time, effort, and money on it. But I couldn’t say so, as the prime contractor was pushing SAFe to the exclusion of any other ideas or approaches; and they were only pushing the outward appearance of compliance with SAFe’s “rules.” They were doing nothing of substance. I didn’t last long on that engagement, and that’s okay with me. It made me feel soiled.

That’s not an isolated example, or an aberration. It’s the norm when it comes to companies trying to adopt one “scaling framework” or another. It’s all about the “rules.” There’s no attempt to learn to think in a “lean” or “agile” way. And middleman companies are all too eager to stand under the rain of cash, arms wide and mouths agape, soaking up the profits. People who know better are hawking frameworks like stereotypical used car salesmen. Ethics, anyone?

By January of 2016, I had one foot out the door…again. The reason for the long gap since my last contract is that I’ve been taking a real estate training course, to become a licensed real estate agent. “This stuff” didn’t stick. Time to leave.

Enter LeadingAgile

Then a colleague in the Agile community approached me. He said, hey, before you leave, take a look at this. He pointed me to his company’s website: leadingagile.com.

Within a couple of months I learned:

• There are still people in the Agile community who are genuinely interested in helping clients solve problems and achieve goals.
• There are people in the Agile community who understand an established company can’t abruptly restructure itself and “go agile.”
• There are people in the Agile community who recognize the value of a framework when it adds value, but who do not “push” a framework.
• There are people in the Agile community who have a realistic model of organizational transformation, a way to craft a practical roadmap tailored to a client’s situation, and the willingness to guide the client along a path to improvement over the long term.

Many of those people work at LeadingAgile.

LeadingAgile has a very pragmatic and results-focused approach to organizational transformation. Some people think the word pragmatic implies backing off from Agile principles; actually, it means something like practical and realistic. Moving an organization toward business agility means defining a rational system of delivery built around teams. It means paying attention to flow, by which we mean the flow of value, not just “busyness.” Ideas from Lean Thinking are key to the approach, including high visibility and paying close attention to delivery rate and, by implication, anything that impedes value flow or delivery. This practical-mindedness has great appeal for me.

I discovered several people I knew were working at LeadingAgile. Some I had worked with in the past. Some I knew through Agile community events. Some I knew through their work. Mike Cottmeyer, Dennis Stevens, Chris Beale, Tom Churchwell, Rachel Howard, Derek Huether. A who’s who. An all-star team.

For me, then, joining LeadingAgile is like coming home. Home to people I know, whose views about Agile are aligned with my own, and whom I respect professionally and personally. Home to the core values of Agile, which have become so watered down and corrupt over the years.

That’s why.
Now, if “this stuff” doesn’t stick…