Mix-in Constraints

August 20, 2019

I just got done introducing another group to the the idea of agile mix-ins. The conversation was a lot of fun. There were a few takeaways for me that I think made the conversation particularly interesting: When it comes to applying mix-ins, you control how much or how little you do, and you also work within the context of the organization.

Let me back that up a little bit. First, before you try and apply mix-ins, I think it’s important to have established a baseline of working practices. This means that if you have just rolled out SAFe, for example, you should probably give yourself a PI or two to really establish a baseline of performance before trying to muck with the system. Otherwise, you just run the risk of creating a never-ending storm of change. That won’t serve you well. So allow yourself to establish a baseline before introducing a lot of new changes.

Second, Scale the change to the level of of organizational permission or tolerance that you believe exists. In other words, if the management team isn’t really on board with the change, then you probably won’t be able to introduce it much farther than the team itself. On the other hand, if the management team does buy in, then you can apply more global change at the program or portfolio levels. It’s a judgement call. Scale your efforts accordingly.

Risk and Compliance

July 29, 2019

What if you were asked to put risk into some sort of framework in a scaled agile system? How would that work? Well, in many cases, you might start with an existing framework. let’s take SAFe for example, the answer might be that we do roaming in PI planning. So as far as most folks are concerned, all risk is taken care of there. That’s it. That’s all we do for risk. The problem is that in many organizations that are audited for risk management that doesn’t even come close to what an auditor is looking for. 

Why is that? Well, if we look at the rules that many large companies have to operate under, they were written on stone tablets with a chisel sometime back in the 1980’s. Those rules typically specify that an organization should use risk management practices that were originally defined by project management practices at the time, long before agile was commonly accepted. 

Now there’s nothing wrong with risk management per se. It’s really just a fact of life. All projects and products have risk. The question is, are the risk management practices managed in a lightweight and iterative fashion? Those risk management methods from the 1980s are typically heavyweight, if not outright overweight, and require a great deal of overhead and centralized management which I’m not sure anyone wants to do. So if you’re going to provide a system of risk management for a company that has to deal with compliance and that has to deal with auditors, then you’re going to have to put together a system that manages risk, tracks risk, and insure that risk is not idly disposed of, thrown away, or magically disappears. Risk needs to be taken seriously as a first-class artifact and a first-class citizen in these contexts. If you are a smaller company, if you don’t have to deal with audit and compliance, then there’s no reason we would ever do these sorts of things. However, if you are in a financially regulated or government regulated business like healthcare or financial services, then it’s very likely at some point that you will find yourself in a situation where you are asked to show a structured set of risk management practices that are used and have controls so that they can be validated within your organization. The question is, what do you do then?

Just Go Touch the Boat

February 23, 2019

A few years ago, I set out to build a boat in my garage. It was a pretty substantial project. Frankly, it was a lot more than I think I was really prepared for. Nevertheless, I did it. It took me about three years to get done, but I finally realized that particular dream and went sailing on a boat I had built myself. Pretty cool, right?

Well, one of my biggest frustrations was this weird phenomenon that happened right before I got started on the work. I can remember it happening in a very specific place: in the garage doorway. Full of good intentions, and ready to get down to cutting some wood, I would pause at the entry to the garage. There was this moment of uncertainty. Often it wasn’t just a moment though, this could turn into a 10-minute-long, what-in-the-hell-was-I-thinking pause. Often it could completely derail me. I’d spin right on my heels and head back to the couch where a beer and Netflix (and blissful determinism) awaited me. It got so bad that I had a rule: just go touch the boat. I figured doing that much would get me close enough to the problem to create the momentum to figure out the next step.

That pause…what was that?

It was a real killer. Here’s what I think it was: it was realizing that I really didn’t know what I was going to do next. At a high level, I knew I wanted to work on the boat. But the specifics – what part of the boat was I going to work on, what did I need to do specifically? That often wasn’t fully thought out. I had an instruction manual, but that really only described the high-level activities that I had to do. The devil was in the details. I suspect that the delays came down to a few different categories of problem:

  • Setup– Are the requisite materials, tools and plans ready for the next step in the process. Are these preparations in a state where I can easily get started or is there some work I need to do before I can even touch the boat. Often this would be cleanup activities. Often, I had left my workspace a mess after the last session, so I couldn’t get started or find tools until I cleaned up the place. Or perhaps my wife had the audacity to park the car in the garage, thereby blocking my access to my precious…sorry…my boat. 
  • Comprehension– Do I really understand how to solve the problem at hand? I’ve learned that much of woodworking is a series of problems. At a macro level, the work is straightforward, but when you get right down to it, you discover that the tools you have don’t work right. Or you are missing a tool. Or you have no clue how to get the geometry of two pieces right in advance.
  • Drive– There were times when I had things set up, and I knew what to do, but…I didn’t want to. Sometimes the prospect of turning on the table saw, braving the spinning blade of death, and filling the garage with a fine layer of sawdust (over absolutely EVERYTHING) was just too much. Huh…there, I said it. There were these moments when I just couldn’t face the effort after a long day at the office or sometimes even on a Saturday.

I mention all of this because I find myself in a similar position now. I’m not building a boat. Instead, I’m building a business. Just like a boat, there are plenty of instruction manuals. The problem is, just like with the boat, the details are often different from what they describe in the books. And I find myself eager to get started. And yet I pause…

So, I’m re-using a mantra that served me well when building the boat: just go touch the boat. I’m not sure what to call this pause. This moment of uncertainty before committing. But I’m willing to bet big money I’m not alone. 

Dev + Friends

February 15, 2019

I was introduced to a new concept a while ago: Dev + Friends

Apparently it works like this: the only truly productive people in an organization are developers. They are the only people who actually put hands on code. Everyone else in the org is just overhead…ahem, friends. Managers, release engineers, Admins, QA, Project managers, in short anyone who doesn’t write code. Full stop.

I’d like to pause for just a second to express my utter horror at this concept. I think I get where it comes from. Organizations, especially large organizations, can become bloated. Executives looking at the composition of teams see that some teams are less than 50% developers and…Oh jesus I can’t even begin to paraphrase this bullshit. It hurts just repeating it. Well, I’m going to grit my teeth and try anyway.

I was part of an organization where the CTO introduced this concept. I suspect he felt that the developers didn’t have enough voice in the organization, so his answer was to make them the most important role in the organization. Everyone serves the developer. There is a certain justice in this. Teams had indeed become bloated with required roles that increased expense without necessarily increasing productivity. One particularly suspect role was the scrum master. To some degree this was a backlash against introducing agile to teams that wanted nothing to do with it (and were given no choice). Then there were product owners, who were often new, and had no domain knowledge. In fact the teams often knew more about the domain than the product owners. On a team with 7 people you just introduced 20-30% overhead without writing a single new line of code. And those scrum masters and product owners don’t come cheap.

So, apparently to combat those issues the CTO told everyone in the organization that the only valuable people are developers. Everyone else only exists in service to development. He called it Developers+Friends. Coders are the only people who are valuable to the organization. I remember feeling like a third class citizen almost immediately when this was announced. It was the most demeaning thing I’d heard in my professional life. Apparently, the work I did wasn’t important because I didn’t write code.

Just in case you’ve missed it, the fallacy lies here: developers aren’t the only people in the organization who contribute value. Part of the problem lies in the explosion of job types in larger organizations. This rarely comes up in small organizations for the simple reason that in a small organization, everyone contributes no matter what their job description is. In fact, their job descriptions in small organizations are almost irrelevant. Everyone is scrambling to help out so frantically, that the question of strict role responsibility never even comes up.

For the record, there are constructive ways to deal with these issues that don’t involve demeaning everyone who isn’t a developer. Involving the teams in the selection of their roles and processes. Insuring adequate training for people filling key roles. Focusing on flexible roles that don’t map directly to job descriptions. It’s really not that hard. You just have to treat people with respect.

Want More?

I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.

To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com

The Living Organization

November 19, 2018


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.


[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.

Agile Management Northwest 2018

September 15, 2018


We held the second Agile Management Northwest Conference yesterday. We had a small, but diverse group of people attending. Of course, there were managers from various software and non-software disciplines. But there was also a district attorney, A dance teacher, a Gregorian chant singer, and a few consultants for good measure. As I opened the space as the facilitator, I was thinking to myself, “Prepare to be surprised.”

I wasn’t disappointed. Linda Merrick hosted the first session of the morning. The topic was “Organizing for Scale” and she used a lean coffee format to structure our conversation. We discussed customer value streams, shared services, tribes, and the fear of restructuring. The topics were wide-ranging and everyone was engaged.


After that, I joined a session hosted by Brent Barton. Brent shared his recent experience as part of a jury in a large civil construction lawsuit. He spent months sitting through this trial learning more than he ever wanted to know about the legal system and the intricacies of construction contracts. However, he also came away with some interesting parallels and insights into the similarities of the practices we preach in agile and the work done in construction. Where we often use (or misuse) construction metaphors as classic waterfall examples of fixed planning, Brent offered that there were ideas like Value Engineering, and Fast Track Construction that were rather agile in their intent and orientation. I came away with the sense that construction is far more uncertain than most people give it credit for.


This conversation also left me with my first surprising insight for the day – having teams evaluated by a “jury of their peers” as part of promoting a form of self-organizing governance for large programs. Rather than having managers externally assessing performance and handing down changes (or punishment), the teams should appoint individuals to a group responsible for self-assessment of the program and capable of levying changes to teams that are performing poorly. It’s a pretty good idea and something that deserves a little further consideration.

Then we had lunch. Folks gathered around the fireplace in the common room to eat together. It was a typical cold, rainy northwest day outside, and sitting by a fire was a cozy way to hang out and share a lunch. I absolutely loved the space we had for the conference. The Brightwater Center building has wooden floors, a fireplace, a pretty stained glass-style window, big bay windows that look out over a nature preserve, and breakout rooms. With plenty of natural light and room to expand as we saw fit, it was a truly delightful place to hold a conference.

After lunch we jumped into our next session. I attended a session called, “What does Music-Making Teach us about Team Dynamics?” Joe Alexander, who has rich experience with singing Gregorian chants, led the discussion. And that’s exactly what he asked us to do! Chant. Our small group stood up, and he led us through a series of exercises, each adding subtly to the next, where we sang a chant together as a group. It was a little challenging, but the group sounded surprisingly good. And Joe used the singing to give everyone a visceral feel for what chanting together can do to create a feeling of alignment and focus. It was a pretty intense session. I’m not sure how I will use that experience in practice, but it led to my second surprise of the day – I never would have dreamed I would be singing Gregorian chants at this conference.


After that, I hosted a session myself to share some of my recent ideas about using organizational batteries as a metaphor for understanding how work is stored and flows through organizations. I’m still playing with the ideas, and I got some good feedback from folks. It was interesting to see how they reacted to the ideas – it definitely makes folks a little uncomfortable. That’s probably a good sign.

Finally, the last session of the day was one that I co-hosted with Skip Angel. The subject was about “Team Toxins and Antidotes.” It was a lively conversation about the things that tend to poison teams and what we can do to remedy that.


After this, we wrapped up the conference with some appreciations and a quick retrospective. Everyone was pretty energized and happy with the outcome of the conference. They all agreed that they loved the space and the food. Some of the conversations had been pretty esoteric, but everyone felt like they were interesting and engaging. I’m looking forward to doing it again next year.

Silos & Value Streams

September 12, 2018


Last night I did a repeat of a talk for a local agile group that I had first done about 5 years ago. The topic was “Silo Busting” and it was all about the nature of organizational silos and how to deal with them. The first time around it had been pretty popular and well received. Like many of the talks that I have done over the years, eventually I put it down to pursue other ideas.

But recently it occurred to me that perhaps I wasn’t done with this topic yet. I went back and looked at the original presentation. My understanding of things may have matured a bit since I had originally delivered the topic, but the fundamental ideas still held up well. In fact, if anything, I felt that organizational silos are perhaps more relevant today than they ever have been before.

So I decided to blow the dust off this particular presentation and try it out with a small audience again. In this case it was the local SEASpin group. They were a great group to talk with. I found myself relaxed and able to cover the material with comfortable pauses for discussion. And I suppose it was no great shock to find that folks had a lot to say about the silos in their organizations. That by itself was gratifying, but as we continued to talk, there were some new ideas that I hadn’t considered before.

For instance, five years ago, there wasn’t a whole lot of conversation about value streams and the dynamics of how they work. In some cases, value streams are organizational silos (or vice versa). Our collective understanding, largely due to the evolution of scaling frameworks, has matured considerably in the last few years. Now we talk about dependencies, optimal sizes, and the correct composition of value streams. These exact same concepts can also be applied to organizational silos.

The other thing that I realized was that we have a lot more ways to understand what is happening in silos than perhaps we used to. This is a bit more speculative, but given some of the recent ideas about emotions and thermodynamics I’ve shared, perhaps these offer us additional ways of thinking about how silos interact. When you look at examples from sociology like the Sherif experiment, it’s quite clear that emotions play a primary role in the creation and interaction of silos. Maybe it’s time we gave the emotional roots of silos more thought.