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.


Moon Shot

February 3, 2019

I was moved recently by a post from Tobias Mayer entitled, Rethinking Transformation. In this post, Tobias is pretty tough on the agile community. He asserts that we really haven’t managed to move the ball in 20 odd years of agile agitating. Instead, we have blended into the status quo rather than effectively challenging it. It’s quite a damning indictment. I believe that in many important ways he is right. 

Now I suppose one could let something like this get you down, but I felt differently: I was excited! Tobias highlighted where the boundaries of our success are. Those boundaries are closer than most would want to admit. He’s arguing that we haven’t gotten very far in 20 years. And beyond those boundaries lies the unknown: the edge of the known world. That unknown territory is full of many frightening challenges. These challenges are things we have never managed to deal with successfully. However, that’s also tremendously exciting. For all of the amazing work that we have done, it’s thrilling to know that much more awaits us. We’ve barely scratched the surface of this opportunity.

Is there any room left for a moon shot in agile? Or have we accomplished all that we reasonably can with the paltry methods we use? What would a moon-shot look like? A challenge so significant, so meaningful, so dramatic, that no one believes you can do it. Would it be a company that is so effective that it blows away the competition? Would it be employees so happy that they want to work there for the rest of their lives? Would it be a process that is so intimately customized to the organization that work flows effortlessly?

What does it look like? Is it Joy Inc.? Is it Google? Is it Semco? Is it a form of hybrid consulting that merges the distinction between the consultant and the client to the point where they are indistinguishable? Is it a spin-off organization designed from the ground up? Or a boot camp where you join the consultants and return to your company a year later, utterly transformed?

And perhaps that’s what it needs to be. A personal experience that is so powerfully transformative that people come out of it feeling changed forever. Do we create that environment ourselves and invite others into it? Perhaps…


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.


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.


The Living Organization

November 19, 2018

close-up-environment-flora-1151418

I should begin this with a brief explanation: I read a book recently called “Design in Nature” by Adrian Bejan. It’s a physics book – he’s a thermodynamics guy. I don’t know much about physics, but one of the things that intrigued me about this book, was that it started with a definition of what life is from a pure physics perspective. That beginning, starting from first principles, was enough to get me thinking. I started to wonder, what would it be like to start with a definition of organizational life? Would that uncover some interesting insights into how organizations work? So I took Adrian’s definition of life and I hacked it a bit to work for organizations. Something like this:

For an organization to live, its structure must evolve so that it provides easier access to the work/ideas that flow through it.
-Derived from Adrian Bejan’s Constructal Law, Design in Nature [1]

Let’s take that statement and break it down step by step. First, all organizations are living systems. Living elements, namely people, make up organizations and they have some sort of discernible life-cycle of birth, life, and death [2]. For example, most organizations have some sort of entrepreneurial origins or birth. Some never get any further than that. They never find a foothold in the business ecosystem and as a result, they never reach a viable, sustainable state. A lucky few find their way to reach a profitable niche. These businesses are able to form a stable enterprise that capitalizes on this success. These businesses often optimize for their domain, transforming from groping for opportunity to maximizing the profit they can make from that opportunity. In essence, they evolve to maximize the benefit they receive from the success they have found. However, markets, like any living ecosystem, are subject to change and disruption. As these changes take place, the profit that once made the company thrive may disappear. At this point, to survive, the organization needs to evolve again. It needs to find a new niche in its ecosystem where it can thrive. Otherwise, the only alternative is death.

So, every organization is a living system that is changing or evolving to survive within an ecosystem [3]. It follows that the organizations that are fastest to evolve are most likely the organizations that survive in any ecosystem that is subject to ongoing change and disruption. All living systems require the capacity to change, potentially very rapidly, in the face of new threats. If we change too slowly, we can’t keep up with disruptions in our environment and subsequently die. So the advantage goes to the swift when it comes to change.

This brings us to the third and final attribute of living systems: flow [4]. The thing that all living systems have in common is flow. It is the flow of water, or blood, or even information. In its most abstract sense, flow is the fundamental characteristic of any living system. Systems with better flow change faster than systems with poorer flow. So the ability to change or evolve is directly dependent on the efficiency of the organization’s flow.

So if organizations are living systems, and living systems have flow, and the system that evolves to the best flow wins, how we structure our organizations to optimize flow is the most important question we can ask.

Notes:

[1]”For a finite-size flow system to persist in time (to live), its configuration must evolve in such a way that provides easier access to the currents that flow through it.” Adrian Bejan, Design in Nature
[2]Koshland, Jr., Daniel E. (22 March 2002). “The Seven Pillars of Life”. Science. 295 (5563): 2215–16. doi:10.1126/science.1068489. PMID 11910092. Archived from the original on 28 February 2009. Retrieved 25 May 2009.
[3]Futuyma, Douglas J.; Kirkpatrick, Mark (2017). “Mutation and variation”. Evolution (Fourth ed.). Sunderland, Massachusetts: Sinauer Associates, Inc. pp. 79–102. ISBN 160-5-35605-0.
[4]Mihaly Csikszentmihályi (1990). Flow: The Psychology of Optimal Experience. Harper & Row. ISBN 978-0-06-016253-5.