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.


Transformation Journeys

February 11, 2019

I was talking with a customer today about a transformation. Like most folks, they wanted to know what the start of their transformation journey would look like. That’s usually a pretty easy question to answer. I might suggest that we start with basic agile training for the leadership team, then engage with them to co-train the teams in work groups. Maybe we work with product and other teams to help get them engaged. I might even suggest chartering and kickoff events of one kind or another. It’s all pretty standard stuff, but it usually ends with “…and then you advance from there.”

There’s nothing wrong with that. We don’t really know where a given customer will take their transformation once we, as consultants, have left the building. However, it doesn’t give people much of an idea of what comes next. In fact, it does nothing at all. It strikes me that we as an agile community have collectively acquired enough experience with agile transformations that we can start to articulate at least rough trajectories of agile transformations.

Here are a few transformation journeys that immediately occur to me:

  • The Pendulum – You adopt an agile framework, run into impediments, pain, etc. and drop the framework. Then you realize that you need agile, so you start all over again and adopt another agile framework. Rinse and repeat.
  • The Requirements Black Hole – you like the new agile process, but you missed a few things in your last plan. So you add more process to catch those things in planning next time. But you miss a few details next time, so you add some more process. Repeat until the requirements process becomes so inconceivably heavyweight that not even light can escape the organizational event horizon.
  • Spotification Syndrome – You want to skip the learning bit and just use a successful system that someone else has already taken the time to invent. You change all the names of your process artifacts to match (Let’s call them tribes!). Of course, nothing meaningful beyond the names have changed, so there is no real change.
  • De-scaling – Maybe you adopt a framework and that was an improvement over the chaos you had before. Now, based on thoughtful experiments, we continue to remove processes rather than add it. Ultimately we have a unique, very lightweight framework that works the most efficiently for our culture.
  • The Inverted Bureaucratic Pyramid – We slap additional roles and processes on the organization. This has the consequence of creating an army of new managers and middle managers. The organizational hierarchy balloons, with there being more roles than people actually doing the work.
  • Bright Shiny Frameworks – We start with one manager attending a certification class for a framework. He comes back and pitches the new dream framework to the organization which decides to adopt it. They get into it for a year or two and realize that they still have problems, so they send a manager to another framework certification. They come back and pitch the new dream framework…ad nauseaum.
  • Fossilized – We adopt a framework and never change again. Ever.

None of these is guaranteed, but I’m sure folks have seen varieties like these. Looking at the list now, I’m a little disappointed that I didn’t have more success scenarios. I must be feeling a little cynical today. I’m sure there are many more (and I’d love to hear what you think they are).

I think we need to pay more attention to describing what the journey might look like for our customers long after we have left (both good and bad). It could give us a sort of pattern language to describe the challenges that they will face down the road on their own agile journey and help them to make better decisions, or at least better informed decisions, when the time comes.


Building a Scaled Agile Framework for Dummies

February 10, 2019

Scaled Agile Frameworks like SAFe are all the rage these days. You can go out now and get training, certification and a shave from a bevy of consultants that for a mere two grand per head (not really sure about the shave part). That’s a perfectly legitimate approach. However here’s a dirty little secret: anyone can do it. Here’s an example of one that I made a few years ago.

I had taken a look at SAFe and there was a lot that I liked and there were some things that just didn’t seem to fit our context. With those qualifications in mind. I decided I could make my own version. I got out my notepad and my colored sharpies and I went to town. I knew that I liked the three layer model, but I found a lot of the SAFe Big Picture had too much complexity in it. So you can see that in the first level, I simplified things quite considerably. The second or program level was also quite simple. I mixed in some things like agile chartering which I felt would be beneficial and were not found in the SAFe diagram. What about the third (Portfolio) level? Well, at the time I really didn’t have a clear idea how that would look. It was at this level that I was looking to integrate the model with our existing PMO practices – which in hindsight was probably a mistake (hey, make your own model and you make your own mistakes). So then I started to iterate.

Now I was starting to think about how things related between the three layers. Those interactions between the team level, the program level, and the portfolio level seemed to be very important. I was also experimenting with different ways of visualizing the processes on each level (with what I must confess are varying degrees of success). My color repertoire had expanded too.

Finally I started to look at the processes as a series of prescriptive steps that I needed to be able to document and describe to people. You can see that I added numbers and then I took each of those interlocking blocks and documented them. I made poster sized copies and put them on the wall outside my office with a sharpie hanging next to them. The request was simple – please change it to fit your needs. After a few days, I had more feedback and iterated from there.

Building your own scaling model isn’t for everyone. However, it’s not rocket science either. If you have a modest understanding of your own business domain, AND you understand the basics of the agile frameworks, you have everything necessary to build your own scaling framework. I’m sure there will be folks who are appalled by the arrogance of doing something like this, but personally, I think we all should feel free to make our own Big Picture. When we can customize our processes in ways that work best for us, I think we win. We learn along the way and we don’t inherit a bunch of cruft from someone else’s framework.


Test Driven Transformation

January 28, 2019

The introduction of agile methods has brought a wave of innovation in the business world that some might argue has revolutionized thinking about how organizations should be structured and how people work together. However, as it stands today, much of the promise of agile methods is wrapped up in preconfigured frameworks that offer a one-size-fits-all solution for every business challenge that a company may face. This is despite the fact that the modern organization is a highly complex structure, bordering on chaotic, that is often not best served by the application of frameworks. We see this manifested most commonly today in the failures to scale agile methods within large organizations.

The conversation about failure rates in the world of transformation is similar to prior discussions about the failure rates of projects and programs: both are notoriously vague and poorly defined. Almost all of the surveys that you find (PMI, etc.) use an embarrassing amount of anecdotal evidence to back up their assertions. The very definition of failure is usually so broad as to be completely meaningless. So, with that said, I think it’s important that we are careful with any assertions that transformations are failing or succeeding. In fact, my experience is that when we are talking about transformations within organizations, we are working at such a high level, that it is never clear what is entirely successful or failing. After all, In a good transformation, there is a lot of failure. You experiment, try things out, and find out that they don’t work. I’m not sure I trust anyone who tells me that 100% of their efforts are always successful. That tells me that they aren’t really changing much.

When I speak of frameworks, what exactly do I mean? Well, I’m thinking globally. I’m not just talking about those large scaling frameworks like SAFe and LeSS (that’s easy), I’m also pointing the finger at small scale, team level frameworks like Scrum and XP. And it’s not that these frameworks can’t work or can’t be useful. In fact, I’ve seen them applied and applied well. However, more often than not, they aren’t applied well. I know there is bitter and acrimonious debate on this subject. I’ll leave that battle for others and simply say, “We can do better.”

We need to step back and reassess how we engage with organizations from the very earliest stages of the engagement. It’s no longer sufficient to make prescriptive, framework-oriented recommendations and have any reasonable expectation of those proposals having any kind of success. In fact, I think we may well find they are often more harmful than helpful. Framework oriented approaches give the false promise that their solutions will solve every problem, and when they fail, they leave the customer having wasted tremendous time an energy, without anything to show for it. To make matters worse, consultants implementing such transformations will simply say that the organization didn’t have the right “mindset”, effectively blaming the customer for the failure of the transformation. This allows the consultant to wash their own hands of any responsibility for the failure as they move on to the next engagement with yet another set of pre-packaged proposals.

It’s time that we brought an end to such thinking and begin to focus on how we can properly understand the problems in the organization before we even begin to make recommendations. Then, like with any prescription for a complex system, we need to apply trial experiments not broad frameworks to address the specific problems that we find. Of course, in order to do this well, we need to have reliable means of assessing the health of the system. We need to treat the system like what it truly is, a complex organic structure, that lives and breathes, composed of living elements interacting with each other and participating in flows of ingestion, respiration, and value production for customers. This requires a first principles approach to understanding organizations. We need to understand exactly what organizational health looks like before we can make any kind of decent assessment of the system. To make any recommendations without that sort of understanding is irresponsible.

So what’s our target? Achieving some hypothetical state of agility is not a meaningful or useful target for a transformation. Agility has no objective meaning that a business person finds useful. Instead it is an end state in search of a meaning. In short, it has none.

Alternatively, there are those who propose that we should start from a place of experimentation. That also is an insufficient starting point for working with organizations. A company is not a consultant’s toy to be experimented with. And no one wants to be the subject of experiments. The experimental approach, while well meaning, signals rather strongly that you not only don’t understand the problem, but also that you have no idea what the real solution is. This experimental approach should be considered by any business owner of integrity as completely useless.

What organizations need is a clear eyed and objective assessment of what the problem is. It should be the sort of analysis that allows us to measure our effectiveness against that of our competition and our customer market in some meaningful fashion. Furthermore, based on that data, we should know what the prescription for change should be with a very high degree of confidence. Organizations are not looking for your best guess. They want to have confidence that any change or transformation effort has some reasonably provable possible outcome.

Another way of putting this is to think of it as test driven transformation. We must have some idea of a reasonable set of tests for assessing the relative health of a system. The results of those tests should give us some clue to the different kinds of problems that may afflict the system. They must be quantifiable, and like a doctor, we must have some notion of what the results of the tests imply. It doesn’t mean that we know for sure what the outcome will be, but it also doesn’t mean that we are taking a random shot in the dark. A good doctor will use multiple diagnostic tests to build a picture of the problems with the patient. Based on the results of those tests, the doctor is able to narrow down the treatment to a subset of commonly recommended approaches. Nothing about this is random experimentation, but rather it is a systematic, data-driven approach to understanding the nature of the problem.


Scaling Self-Organizing Systems

January 27, 2019

I was reading Geoffrey West’s book, Scaling: The surprising mathematics of life and civilization recently and something interesting jumped out at me. Where networks, whether they are biological or man-made, are concerned, there appear to be some efficiencies as the network grows. Generally speaking, fewer resources are required for the same amount of effort as scale increases two-fold or more. That applies when we are talking about networks. However, when West reviewed corporations he noticed that the same benefits of scaling did not apply. Surprise!

Hold my beer. I’ve got this…

The organizations that West examined were very likely hierarchies. Hierarchies are the worst performing sort of network. So, it is no surprise at all that scaling doesn’t work well for hierarchies. As hierarchies get larger, communication and the flow of resources tends to get less efficient. Living systems are self-organizing, cities are self-organizing, hierarchies are definitely not self-organizing.

If West had looked at organizations that were founded on self-organization like Morningstar, W.L. Gore, or Semco, I suspect he might have found a different result.


Your Framework Sucks

January 16, 2019

We can learn the art of fierce compassion – redefining strength, deconstructing isolation and renewing a sense of community, practicing letting go of rigid us-vs.-them thinking – while cultivating power and clarity in response to difficult situations.

-Sharon Salzberg

Recently I’ve seen a lot of negative comments on social media criticizing SAFe and other scaling frameworks. Some of it can be chalked up to the Agile community’s typical aversion to change (ironic, isn’t it…). You hear it whenever somebody says, “That’s not agile.” That’s just another way of saying, “That’s different.” This isn’t anything new. I remember people used to say the same thing about Kanban when it was first introduced. They’ll probably say it about the next new thing that comes along too. Some of it is the usual competitive “My agile-fu is stronger than your agile-fu.” There are a bunch of agile scaling frameworks now, and curiously, none of them has anything good to say about the others. Despite all that, there are some criticisms that I think are pretty legit. I’d like to address a few of those here.

First, the rollout plans for SAFe and other frameworks seem to be pretty static. That could just be me, after all, but I don’t see a lot of variation in the approaches to rolling out frameworks. It’s often top down, and dictated largely by the management teams or key stakeholders in the organization. I’m not arguing that isn’t the right way to do things, but I am arguing it’s not the only way to do it. The agile community at large has been experimenting with how to introduce agile to groups in a fashion that is more bottom up for a long time. This bottom up approach has many advantages. If we can get the people doing the work to have a voice in how they are organized, then we are much more likely to get their buy-in and engagement with the new organization. Those folks also know more about the work, so they are probably better suited to make key decisions about who works with whom. Bear with me here, because this is some pretty radical stuff. There are folks who are experimenting with self-selecting teams that are making impressive progress. Imagine being able to work on whatever team you like? Amazing.

For example, we should be able to introduce team self-selection into SAFe as one of multiple options for creating release trains. There is nothing about self-selecting teams that breaks or somehow violates the 9 fundamental principles of SAFe. In fact, I might argue that self-selecting teams are perfect for SAFe. I truly believe that they are much more likely to be high performing teams than teams that are selected in a top down fashion by managers. There could even be a hybrid model where the management teams define the capacity – the overall size of the release train according to funding allocation, and the teams self-select to match that capacity. It would be a combination of top down and bottom up.

The other area where I see rather dramatic over-control from the top is with the emphasis on the top down epic-feature-story elaboration. Often this process can be so rigid that teams can feel as though their feet have been nailed to the floor. Everything is so tightly defined by the time that it comes to the team, that the team doesn’t feel like they have any options. All of the key decisions have been made. In a very real sense, if everything has been decided before the team sees it, then the epic-feature-story elaboration process is indistinguishable from waterfall from the teams perspective. It’s especially bad when the teams are asked to commit to delivering those features and stories for a planning increment. Suddenly you have teams wondering what, if anything, they are contributing to the process. There certainly doesn’t feel like there is much room for learning.

I think there is a hybrid approach here where the teams take the epic-feature-story breakdown as inputs for negotiation and conversation, but they don’t commit to them. To me, epics, features, and stories are a useful language or model that product owners use to describe what they think the customer or marketplace wants. Epics, features, and stories are not actual value. They are a description of what we think value might be. They are an input to the team design process, not an output. This is important and probably bears repeating: epics, features, and user stories are an input to the design process, NOT AN OUTPUT. We want teams to commit to outputs. Specifically, something valuable. Software that does something useful is valuable. So we want them to commit to delivering some software that we can use to do something valuable. So we should stop asking teams to commit to the inputs, and instead ask that they commit to outputs. Commit to value. That would cure a whole lot of dysfunctions that arise from asking teams to commit to delivering inputs.

There is a transformation that needs to take place between a request defined by epics-features-stories and the resulting useful software that is produced. This is where the sausage gets made. The team uses features and stories to try and understand in simple terms what is being requested of them. Then they integrate that model with their own understanding of the domain and the working system that they have before them. Even that is an incomplete picture of the world. To really do well, they have to use all of this incomplete information to test their assumptions against the system and the customer to get some feedback. They find unanticipated problems, and they have to have the freedom to change fundamental assumptions in order to arrive at what is hopefully something very useful to the customer. That’s never a given, there are always lots of unknowns, and we have to allow for that.

These are a couple of examples of how we can experiment and play with how the framework actually gets rolled out. There is lots of room for variation – that’s why they call it a framework to begin with. There’s a roadmap for rolling out SAFe. If you are just starting out, that’s probably the best place to begin. However, I think that as experienced practitioners, we need to be exploring many different ways of rolling out SAFe (or whatever your framework of choice happens to be). Not all customers are alike, especially when it comes to scaling agile. We need to be flexible and creative in the manner in which we implement our frameworks. In and of themselves, frameworks provide a set of overlapping ideas that can help us start to deliver value amid the chaos that is often the norm in so many places. However we need to implement those frameworks using all the creativity and imagination at our disposal. This is how we can best serve our customers.