Different Roots, Same Tree

May 1, 2019

Recently, at conferences, in social media, and even informal gatherings, I’ve heard statements along the lines of “[X] scaling approach is absolutely not agile for [Y] reason.” I use the word approach to avoid the question of whether we are talking about a framework or a methodology. I really don’t care about that distinction and much of the subtlety that lies there is beyond me.

Admittedly, there is a long and rich history of critiquing each others ideas in the agile community. Some examples include:

  1. XP vs Scrum
  2. Kanban vs Scrum
  3. Lean vs Agile

To my knowledge, none of these debates has ever really reached any sort of meaningful conclusion. In fact, the more I watch (and even sometimes participate in) these debates, the more I feel like they are mostly a reflection of a sort of core philosophy. What I mean, is that there seem to be some common starting points or assumptions that characterize how people approach these debates.

Let me give you an example. Let’s take SenseMaking and the Cynefin framework. We can use a tool like Cynefin to help us navigate important decisions based on the assessment of contextual complexity. The beauty of this system is that you can use it anywhere. It doesn’t matter whether you are agile or not. Cynefin is simply used to help assess and navigate the environment of simple, complicated, complex and the chaotic. What decisions you make within each context will lead you to healthy outcomes. With Cynefin, you can start with absolutely no framework or required processes at all. In essence, you are building from scratch, and evolving only as necessary. Frankly it’s a beautiful and elegant system. Conceptually, it’s founded on the notion of sensing your environment and making decisions based on what you uncover. It’s a radically empirical process that starts wherever you may be. There is no default starting point for applying Cynefin. You simply use it to help you grow from wherever you are.

The interesting thing is that Cynefin isn’t the only framework that uses this “start wherever they are” approach. Kanban is also very minimalist in its rules. In fact, Kanban usually starts by simply making the existing process visible. You don’t need to change your process at all, just make it so that everyone can see it. Starting from there, the Kanban approach recommends that we consider applying WIP limits and working to understand the constraints of the flow through the system. There are no pre-defined required processes. You don’t have to do standup. You don’t have to hold retrospectives. You basically start Kanban from scratch and add those elements wherever they make the most sense. You build your agile process from scratch based on the feedback you get from making the process visible. Again, it’s a very elegant and powerful system, that’s founded on the notion of visibility (or transparency) and allows you to evolve however makes sense for your environment.

So I see both Cynefin and Kanban as sharing some important conceptual roots (while each is very unique). Both methods provide us feedback to help make good decisions in whatever context we may be working. Both also make absolutely no assumptions about what the starting point may be. You could start with a very rigid, waterfall style, process. Alternatively, you could be using Scrum. Neither Cynefin, nor Kanban care about where you start. In fact, what they really care about is not blindly applying process without some sort of feedback. So I think of Cynefin and Kanban as the “build it from scratch” or “consider context first” methods. Actually, I really like to think of these as the Buckaroo Banzai methods, you know, “Wherever you go…there you are.”

Now this also implies that you are really committed to this learning journey, with all of its joys, discovery, false starts and dead ends. Building your process from the ground up is not for the tentative or the faint of heart. Why do we have to go through all of this learning pain and discovery, when others seem to have found some practices that seem to work? Well, the argument, and it is a very valid one, is that you need to discover what works for you in your context. Trying to apply solutions that may have worked well in other places often leads to disappointment. In the Toyota way, Toichi Ohno warns us of exactly this. If you want to build a world class process, you can’t rent it. You need to build it and find out what works for you.

But what if we really could rent our process? Wouldn’t that save a lot of time and wasted effort? Let’s face it, this is business, not rocket surgery. We can’t all be so unique that we have to waste time rediscovering the wheel. Let’s take a look at another very large branch on the agile tree: approaches based on starting with a predefined set of practices or processes like Scrum, or XP.

Scrum is based on a very fundamental set of practices that creates the infrastructure (or framework or method) for continuous delivery and improvement of small units of work. Depending on who you ask, XP and scrum came into being around the same time. As I remember it, XP was the first to really land hard on a required set of practices that defined the process as truly being XP. These twelve practices were non-negotiable. You had to do them, and if you didn’t, well, then you weren’t doing XP. You’re probably familiar with many of these practices. They are foundational practices like pair programming, continuous integration, test driven development, and so on. Part of the reason for requiring these practices was that they supported each other. It’s hard to do continuous integration without some form of test driven development. The two together are kind of a magical combination – they help reinforce each other. Often, what we see happen in the real world, is that teams will struggle with and perhaps drop practices. When that happens, keeping the other XP practices working gets harder.

Scrum does something similar, but different. Scrum has a default set of non-technical practices that are required. You must have sprint planning, daily stand-ups, and sprint retrospectives. That’s non-negotiable. To do otherwise is to do “Scrum, but…” and to be mocked mercilessly by your peers. Both scrum and XP could be loosely described as having a default set of “best practices” that are required in order to use the framework to its best advantage. Now I personally hate the term “best practice” but that’s exactly what they are doing. We’ve identified the best, minimal, set of practices that you must use as a starting point, no matter what your context is. It’s a package deal and we defer to the wisdom in the package. Unlike Cynefin or Kanban, you have a very well defined starting point, and you aren’t given the option to do differently. Now, both XP and scrum are based on empirical process control (at least in theory) and they both claim that you can evolve and change the framework as you learn to use it. However, in practice, I’ve rarely seen it actually happen (Spotify being one very notable example). When you start with a predefined set of practices, it seems harder to evolve to anything else. Well, I guess Darwin never said evolution was easy.

So we have two very different schools of thought about how to think about approaching agile:

  1. Start “where you are” and use a decision making model or visibility model to evolve to where you need to be (Cynefin, Kanban).
  2. Start with a fixed “starter set” of best practices and then evolve to where you need to be (Scrum, XP).

I think that these two philosophies or approaches explain a lot of the conflict I see in the agile community today. The “start where you are” folks seem to feel very strongly that “starter set” approaches run the risk of being applied in a cookie cutter fashion and often incorrectly. To them these approaches are likely to lead to poor outcomes and are therefore to be avoided or even wrong headed.

On the other hand, the folks who take the “starter set” approach” are appalled by the waste involved in the “start where you are” engagements. Why in the world would you waste your customers precious time and energy on rediscovering the wheel when you already have a very capable set of practices to start with? It’s folly! These practices are tried and tested and there are very few exceptions. To ask the customer to invent their process on their own is just a high risk recipe for disaster! Therefore, to do anything other than the “starter set” approach is to be avoided or…well, you get the picture.

I think the argument only gets amplified when we start to include scaling frameworks in the conversation. As I look more and more closely at the scaling frameworks, I start to think that I see their roots in each of these different approaches. For example, SAFe has its roots firmly in the “starter set” camp. SAFe is most definitely a framework of prescribed “best practices” that are intended to be applied universally. There is some allowance made for the size and scale of the organization, but the gist is that everyone does SAFe. On the other hand, there is LeSS which seems to share its roots much more closely with the “start where you are” approaches used by Cynefin and Kanban. In LeSS there is more emphasis on using tools like systems diagrams and root cause analysis to discover the right means to change the system for scaling. So LeSS feels to me like it leans a bit more toward the “start where you are at” approaches.

Of course, the adherents of each approach think the others are nuts. I think some of that is due to how each sees the world. They are coming from very different starting points. I’m not sure they’re ever going to agree with each other. Fortunately, I’ve seen both approaches work well for people. And I’ve also seen them both fail miserably. Often it had little to do with the frameworks, and a lot to do with the people. So I guess we count ourselves lucky and try to remain calm when they point quivering fingers at each other and proclaim loudly that the other is “Not Agile”.

Of course they aren’t.

That’s OK.


The Poor Neglected Impediment

February 28, 2019

I wrote a book a few years ago about dealing with impediments on agile teams. It’s right there on the upper right of the page (I’ll give you a minute to make your purchase). Well, the industry has continued on since those heady young days, and two things are still true: people still underestimate the impact of impediments, and impediments are bigger than ever. 

Where agile was largely a team level affair not much more than a few years ago, now it is much bigger. Scaling is all the rage. Now we work in teams of teams or in things called release trains. Entire divisions of major corporations undergo mind-bending enormous agile transformations. We now have many different kinds of frameworks that we can use when making those transformations. One of the most popular is SAFe. If you haven’t seen it before, you should check it out scaledagileframework.com

The first thing you will see is the “Big Picture.” It is an enormous diagram that attempts to portray all of the processes and practices that you can apply to use the framework. They’re not joking about the ‘Big’ part either. That diagram is downright intimidating. Go ahead, grab a magnifying glass (you’re going to need it) and let’s take a closer look. You see all sorts of things that we are familiar with in the agile world in that picture: user stories, features, scrum, kanban. All of my favorite technical words are in there. It’s a process management smorgasbord! Did you notice anything missing in that diagram? I don’t know about you, but it seems like they threw in everything but the kitchen sink! Oh…wait…hold on a second…where are the…impediments!

THEY FORGOT ABOUT IMPEDIMENTS!

I’m outraged! Shocked! Shocked I tell you! The nerve of some people. Oh, I’m sure they make some passing mention of impediments deep in the smelly bowels of their documentation. Someplace dark, where no one will find it. Impediments are certainly not a first-class citizen in SAFe’s world. I’m so depressed. Well, I guess that’s it: SAFe sucks. 

But then again, If I go look at some of the other scaling frameworks, surely, THEY will have impediments, right? Let’s go take a peek at LeSS (less.works). AAAAARRGH! Again, no impediments! But…maybe one of those more disciplined frameworks like DaD (Disciplined Agile Delivery) will make some passing reference to impediments. OH NO! Not again! None of these frameworks makes mention of impediments. They all suck.

Well, fine. Be that way. Go ahead. Ignore impediments (You fools!) See how far you get. I’m not bitter. Go ahead, call me when your precious value streams are tied up in knots. When your teams are blocked from delivering to production. You see, now, perhaps more than ever, impediments are increasingly relevant, especially when we start talking about scaled agile development. Risk management doesn’t go away just because your agile got bigger. 

In all seriousness, I think that it’s worth considering where risk management does fit in the popular agile frameworks (or perhaps why it doesn’t). All too frequently I think it is lost. To some degree that is not a surprise. Many of these frameworks are so top heavy with processes and practices that it’s a miracle they don’t collapse under their own weight. Why pile on yet one more practice to the mountain that is already there? It’s just one tiny little process. Wafer thin mint anyone?

Alternatively, perhaps it’s time some of those frameworks went on a bit of a diet. And rather than trying to cram in the latest fad like continuous delivery, devOPS, etc. perhaps we should toss out a few things and try a little risk management. It could be a real lifesaver.