SAFe Mix-in’s: Radical Co-Location

April 18, 2019


One of the biggest challenges that I often encounter on SAFe transformations is dispersed teams. A dispersed team is a team that is spread across multiple locations and often across multiple time zones as well. I’m speaking specifically of dispersal within the team membership – for instance, a product owner in LA, two developers in Bangalore, three testers in Russia – that sort of thing. That’s a dispersed team. While it’s possible for team like that to get work done, it is also demonstrably one of the slower ways to get work done. In fact, it’s probably the opposite configuration of what’s needed for really high performance. There’s ample evidence to show that high performing teams perform better when co-located.

Often times, when you go into large organization you find that the product owners are in building A, the development teams are in building B, and operations is in building C (or some other horrifying configuration of the above). To make matters worse, there is typically little or no willingness to change that. It costs a lot of money to change that sort of configuration.

Normally, I wouldn’t think of co-locating teams as a big deal. It sort of comes with the territory with agility. However, the reason I’m including co-location here as a mix-in is that for big companies, it seems to be a harder challenge. So, my thought was, “Why not put focus on the co-location aspect during the transformation?” You could also argue that SAFe already encourages this behavior. I would agree, but…we still don’t do it. So, given that I’m pushing boundaries here, I call this a mix-in. You might disagree – fair enough.

You see, all too often, what we do is accept that dispersed situation as the status quo because the customer is unwilling to go any further. However, for those customers that are willing to entertain the idea of improving the performance of their teams then we should look at radical co-location. I call it radical co-location simply because for these organizations it’s a radical idea. It’s a really big deal to them. It’s a huge undertaking. But let’s face it, for those of us in the agile community, there’s nothing radical about it. We’ve been co-locating teams for decades now. So really, the only people that it’s radical for are these large, byzantine bureaucracies that we are trying to encourage, threaten or nudge towards agility. And so, if we have to describe it as something radical or new, if it gets them excited, then perhaps it’s useful. 

All we’re really talking about here is getting all the team members sitting together in the same location. For example, getting the product owner sitting with the team. All of the team members in the same building, on the same floor, in the same pod. This enables them to work together on a day to day basis with no delays in communication at all. That’s it, no tricks, no stunts, just getting everyone together. If that means that some sort temporary seating arrangement needs to be made, whether folding chairs or folding tables, so be it. The communication overhead goes down, delays go down, feedback loops improve. So, with all of that in mind, it really is essential that if a company is willing to go along with this, that we get it in place as quickly as we can. In terms of performance improvement, it would be nearly number one of the things to do in any transformation. 

Let’s take this radical co-location idea a little bit further. After all, SAFe is all about scaling, so the question is, how can we use co-location outside the team? How about a co-located release train? A co-located solution? The same issues with communication delays apply with cross team communication as they do with intra-team communication. 

At the end of the day, it’s important to acknowledge that there are a lot of very legitimate reasons that people can’t all be co-located. This isn’t for everyone. Folks have different learning styles, and different comfort levels with personal proximity. I want to acknowledge that those things are important…and for those who can tolerate it, let’s lean hard on co-location.


  • Teams are dispersed across geographic and time zone boundaries
  • There is pressure for faster team performance/feedback

Framework Impacts

  • None


  • Faster feedback
  • Faster team performance
  • Higher quality (fewer handoffs)

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪ ‬

SAFe Mix-in’s: Dynamic Re-Teaming

April 7, 2019

The next SAFe mix-in that I’d like to address is dynamic re-teaming. Dynamic re-teaming is a relatively radical agile innovation that changes the way team selection works. Let’s take our typical practice of rolling out a SAFe release train, we have our executives and key stakeholders get together and decide who is going to fill what roles. They make all the decisions: Who is the right person to lead this train, who is the right architect, who should be the Release Train Engineer or program coach. Often, they make all of those decisions without consulting the people doing the work. So, you make your top down decisions: these are the people for each role, these are the teams you will have, etc. All of these choices are made by senior stakeholders. To be quite honest, that’s frequently how it’s done in most places. Most organizations are hierarchical organizations and those sorts of decisions are the sort that are only trusted to be made at the top of the organization.


Dynamic re-teaming takes all of that and turns it on its head. In dynamic re-teaming, instead, what we are going to do is let the individuals decide who they work with and what they work on. Basically, the product management or the key stakeholders go before the group as a whole, whatever your program group or release train is, and describe the challenges that we have. They talk about the features we want to deliver and why. Bottom line, they make the most compelling case they can for the work. In essence, it is a sales pitch to the developers. Then we allow the group to choose what they are going to work on and who they are going to work with. You allow these people to align or ally with given functions and product owners on their own. They make their own decision about who and what they will work on. That allows people to dynamically decide where they are going to be. 

You can find out more about dynamic re-teaming here:

So, with dynamic re-teaming, you get together and your teams form in a truly self-organizing fashion – and off you go. You work together for a quarter or so on whatever it is, using whatever process you see fit (scrum, kanban, xp, whatever), and at the end of your quarter you show what you’ve delivered. Then you rinse and repeat. This means that product management and stakeholders have to put a new set of ideas and hopes for customer value in front of everyone once more. Again, we are going to do a brand-new team selection. If I worked on a team on a feature last quarter, I can turn right around and work on a different team on a different feature this quarter. Whatever tickles my fancy or feeds my needs. 


Now as you might imagine there is a lot about this method that makes some people uncomfortable. For instance, there’s the possibility that maybe nobody would find your feature attractive enough to work on. Well, perhaps that’s telling you something. Rather than blaming the team for avoiding the work, perhaps your work just isn’t that interesting to begin with. I suspect there are those who would find this an injustice, but only at the risk of sounding like mocked mad scientists. There is always the possibility that nobody wants to work on something. Folks might come back and say, “But we know there is value in this work.” And that may be the case, but you still may not have conveyed it well enough for others to see the value in it too. So perhaps it’s just as well that feature didn’t get touched.

At the other extreme, what if everyone wants to work on the same thing? Well, that’s great! That one thing hopefully will get done much sooner. And with all of that attention it’s probably something of real value. To a certain degree, we are relying upon the wisdom of the crowd here. So, to recap, the two extremes of nobody working on a feature or everyone working on a feature are not necessarily negatives. Although I doubt either extreme happens all that often in practice.

At the end of the day dynamic re-teaming also jeopardizes a few sacred cows like managerial control and their ability to strictly dictate what happens within their own fiefdoms. I’m not really sure there is much to be said about that other than, “Ouch!” That’s gotta hurt. Losing that control is one of the consequences of empowering teams. Now there can still be reporting hierarchies, there is no problem with that, but the idea is that no matter who you report to, you can choose the work and the people that you work with. This is an enormously powerful way of proving to teams that you do believe that they can make the best choices for themselves. After all you hired the best and the brightest, right? Therefore, they should be perfectly able to make the best decisions themselves. They don’t need you to hold their hands for them as a manager. 

So dynamic re-teaming is something that SAFe makes no provision for. You won’t find any instruction or guidance on how to use it in the SAFe documentation. There’s nothing in the building of a release train that says that you have to dictate who the players are from the top down. In fact, you can build a release train any way that you like. Using dynamic re-teaming is basically building it from the bottom up. Allowing the people who are doing the work to decide where they are going to work next. There’s absolutely nothing in SAFe that says that can’t work. The only thing that SAFe really does say is that you will maintain a group of people for the duration of a quarter or program increment. SAFe says that if you have a 150 people working for the that quarter, that they will stay together for the entirety of that quarter. Whether they work on one team or five teams, SAFe doesn’t care. And so, within that framework, we still keep all of the rituals, two-week increments (or whatever turns you on) within the PI planning increment. The reporting, transparency, and collaboration mechanism all are still honored and preserved. 

Now if we look at dynamic re-teaming from the perspective of changes that are easy to implement (say like mob programming), this requires a broader level of acceptance from the group. You’ll need to get your middle and senior managers on board in order to make dynamic re-teaming work. It’s much more disruptive to the status quo and therefore requires a commensurate level of buy-in from management in order to succeed. On the other hand, dynamic re-teaming is potentially extremely powerful in terms of liberating the teams and helping them to feel as though they are invested in the process and have some hope of achieving their own goals.

We can’t really talk about empowerment unless we are willing to give people the ability to make their own decisions about what they work on, who they work with, and where and how they work. If we can summon enough confidence in them to say, “Here are the challenges we face, organize as you see fit to tackle these challenges.” Then perhaps we can get much more passionate engagement from people. That’s the promise that dynamic re-teaming holds.


  • Teams seem lackluster, not engaged
  • The management team is open to creative new options (and can tolerate giving up some control)

Framework Impacts

  • Teams must persist through full PI


  • Improved morale and engagement
  • Additional selection pressure applied to new features/initiatives

In the broader spectrum of SAFe mix-ins I think that dynamic re-teaming holds a lot of promise. SAFe has been rightly accused of being too hierarchical and too top down in its typical implementation – and not introducing real change. Well if you use dynamic re-teaming you don’t have to change anything in the SAFe big picture, but you fundamentally alter the way that people are working together. It’s much more empowering than the traditional models that we typically roll out.

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪ ‬

Let Your Freak Flag Fly

March 4, 2019

I find you can learn a lot just by walking around and looking at the spaces that teams occupy. Sometimes, a workspace is full of personality. I used to work with a friend who would put an enormous wall hanging of a dragon over his desk. I don’t know where he got that thing, but it screamed “I’m into fantasy RPGs!” It didn’t matter where he was, that dragon hanging went with him everywhere. He was awesome, probably one of the best developers I’ve ever worked with, and that dragon was just part of the package. I could literally orient myself in the building based on where the dragon was.

I can’t criticize though, in my office at the time there was a full size head of a warthog mounted on the wall. Beneath it was a tiny little sign that read, “Mini-me.” That mount truly was the ugliest thing you had ever seen, but it made people laugh. Looking back on it, obviously we worked in a culture where we weren’t shy about expressing ourselves. I’m sure my friend still has that dragon wall hanging. I’ve still got the warthog head, but no office anymore (my wife makes me keep it in the garage).

However, if you look in some offices, there are no dragons and warthogs. In fact, there are rows of cubicles with the same monitor and keyboard in each one. There might be the occasional concession to personality with a small framed picture of the family, but that’s it aside from some pens and a notepad or two. I’ve worked in these more corporate environs as well. I have to confess that the relative sterility of the environment leaves me a bit cold. However, I did find that I could move around and “hotel” wherever I pleased. So that was good. I guess, strictly speaking, that there are benefits to each type of space. Personally, I prefer an environment where people express themselves. I guess I can’t navigate without some sort of exotic wildlife pinned up on the wall.

Don’t even get me started with those corporate motivational posters. I can feel a tiny portion of my will to live draining out of me every time I see one. It doesn’t help if the company has paid big dollars for designer furniture either. It still doesn’t feel warm to me. Frankly it’s kind of embarrassing how much money is spent on office furniture for some companies. I guess other people find it attractive.

I would look for an environment that provides the following key elements:

  • Keep it alive – bring your personality
  • Do it for real – no fake stuff like motivational posters
  • Setting – pay attention to the layout
  • First start obvious, stay obvious – don’t hide things
  • focus on flow – enough said

These are from Willem Larsen and Diana Larsen’s Quickstart Guide to the Five Rules of Accelerated Learning. If we are trying to create a learning environment, which I would argue is exactly what product development is all about, then we should be thinking about these five rules.

Make it Yours

March 2, 2019

A few years ago you could walk into just about any high tech company on the west coast and find teams, divisions, and release trains. Perhaps you would stumble over the occasional program or project if they weren’t agile. In all of these cases the terminology was and still is pretty consistent. Consistent is good, right?

Along comes Spotify and they introduce squads, guilds and tribes and everyone goes wild. What a bunch of rebels! It was hard not to walk into a company and have someone mention that they wanted to use the Spotify model. Some of this was admiration for the innovation exhibited by Spotify. And I suspect that some of what attracted people may have been the terminology.

I can help you out with that. I’ve got a thesaurus handy, so here are a few terms to spice up your otherwise boring organization descriptions:


…and there is a lot more where that came from. I think it’s time that we started to use names that work for us in our environments. Scrum and SAFe have their stock labels for things. That’s a nice starting point, but there’s no reason that you can’t change them. Go ahead, call your team a Moiety (you know…a moiety: In organic chemistry, a moiety is a part of a molecule which is typically given a name as it can be found within other kinds of molecules as well). Yeah, I had to look that one up. Why would I do something silly like that? Because my moiety is unique. Our teams work on tools for chemists? Because we’re all former chem majors?

Look, to be honest, you really don’t need much of a reason to call your teams something different. Go ahead, grab a thesaurus and have a little fun. Don’t be afraid to express yourself. Make it yours.

Pernicious Escalation

February 21, 2019

I found this lovely pairing of words in Yves Morieux’s book, Six Simple Rules. He was talking about the corrosive effect that problem escalation can have on teams and management. I’ve seen this before and I know how hard it can be to deal with. On the one hand, as a manager you are there to help and you may feel somewhat flattered when the team comes to you with a problem. On the other hand, as Morieux suggests, an escalation represents a failure of the teams to find a way to arrive at a solution themselves.

First, an escalation often reflects an inability to cooperate on the part of the parties involved. The problem with cooperation is that one group or another usually has to give something up in order for the problem to be successfully resolved. And the thing they are being asked to give up or forego is usually something that they really want. I see this all the time in product management decisions. Two teams are working on features that have been stressed as of the highest importance to the organization. One of the teams falls behind and asks the other for help. It is clear that a choice has to be made. There are three options, Feature A, Feature B, or both (we’ll just leave neither out of the picture for now). One team or the other has to either work extra hard, or drop a key feature. All too often, both teams throw up their hands in frustration and escalate the problem. Why? Because they can’t find a way to solve the problem together.

Second, escalation defeats attempts to empower people and teams. If you give teams the power to make their own decisions, what you have really done is give them the power to make their own compromises. Compromise is hard and my observation is that it’s just human nature to try and avoid it if we can. Of course escalations’s just putting the power back in the manager’s hands. So it defeats the very purpose of pushing decision making power down in the organization – to move the decision closer to the people doing the work.

That brings us to our third and final reason that escalation is harmful. Escalation removes or distances decision making from the source of the problem. This is based on the premise that the best informed people to make a decision are the people who are closest to the problem. The further that you remove someone from the work or the source of the problem, the less likely the decision is to be well informed and useful.

So Morieux recommends that the first thing a manager should do when they receive an escalation request is to lock the two parties in a room and explain that they have to work it out together. They need to learn that the correct answer is some form of cooperation. If they can’t cooperate, then the manager should let them know that cooperation is essential to their performance and as such she/he will keep this in mind when reviews come around. That’s pretty tough…but I like it.

Painting The Spots

February 16, 2019

If you do a little reading about Scrum one of the first things that you learn are the 5 basic values of Scrum:

  • Courage
  • Focus
  • Respect
  • Committment
  • Openness

I’d like to examine one of those values that I watched a team wrestle with recently: commitment. These were really great folks. They were bright, energetic, friendly and passionate about the work they were doing. Within the team they took a lot of pride in their ability to “be agile.” They seemed to be doing a lot of good stuff.

However, I was hearing some disconcerting things from other parts of the organization. Other teams characterized this team as flakey. Managers expressed frustration that they didn’t deliver. I wasn’t sure what the story really was. Was it a cultural thing? Was it petty jealousy at work? I really had no idea.

An opportunity came along to do a little coaching with the team in question, so I was eager to find out more. Here’s what I found:

  • Optimism at the start: So the team said that they were prone to overcommitting to the amount of work they could handle in a sprint. During sprint planning, they would realize the balance of the work was unequal and that there would be team members left idle. So they would take on more “overflow” work to make sure that everyone on the team has something to do during the sprint. It’s great that they were aware of this problem. This pattern of behavior was leading the team to consistently overload their sprints with more work than they could achieve. The team told me that their typical velocity was 27-29 points per sprint. When I asked them what they had committed to in the last sprint, the answer was: 44 points. When I pointed out the obvious discrepancy, they admitted that they had overflow work from the previous sprint that they felt they had to get done. So then I asked them if they were going to deliver on all 44 points. And the survey says: No.
    The good news? This injury was self-inflicted. The bad news? It didn’t sound like they were entirely convinced they had a serious problem. A pattern of failing to reliably deliver sprint objectives can lead to a crisis of trust with a team’s stakeholders. The stakeholders start to doubt whether or not you will deliver on your sprint commitments. This can be a corrosive influence on the relationship with the very people who are signing the team’s paychecks. The solution? Stop overcommitting. This means that the team has to face some awkward issues about how to manage balancing work within their ranks. These are issues they were able to hide from by overloading the team with work. I got some grudging buy-in at this point, but I could tell that there was still work to be done.
  • Carry over matter: Since they are overloading the sprint, they are almost guaranteed to have items that are not completed and those get carried into the next sprint. I took the time to point out that this sort of issue is a problem, but you can skate by when you are simply going from sprint to sprint. However, when you are trying to work to a release plan with multiple teams and multiple sprints, then carry over is a total deal breaker. If you are working with other teams and you have a pattern of failing to deliver stories, the other teams are very quickly going to learn that you are not a good partner to work with.
  • Transparency: So I asked about this because I wasn’t sure what the problem was. Apparently they were concerned that they were being asked to track their time and their tasks in a time tracking tool to a level of detail that was making them uncomfortable. As we talked about it someone said, “I don’t think they trust us…” I could tell that this person was a bit upset by this perceived lack of trust. Of course I put on my Mr. Sensitivity hat and replied…Of course they don’t trust you! You don’t deliver committed work on time!

Well, I don’t think I said it exactly like that, but it was some polite variation on that theme. Now people were upset, and finally my message was getting through. The product owner for the team, gave me loud and vigorous support at this point. You could tell that we had stumbled on a fundamental assumption that people on the team were realizing was dead wrong. The scrum master articulated the invalid assumption for me: The whole purpose of having a sprint goal means that you can achieve the goal without having to deliver specific stories. You focus on the goal rather than the stories. That is an interesting, but completely incorrect interpretation of how commitment works. Apparently much of the team was operating with this model in mind. Once I pointed out that other people were depending on those specific stories being delivered, not some abstract goal, then you could feel the resistance immediately start to evaporate.

The other thing that was a little disturbing about this situation is the blind spot that the team had when working with other teams. They had explained away their inability to deliver as due to their own superior understanding of what it means to ‘be agile.’ No one else understood how awesome they were because the other teams weren’t as agile as they were. Now there is no doubt that they were doing a lot of things right. Like I mentioned in the beginning, they had a lot of good things going on. However, they had managed to paint over the ugly bits of their process without examining them and addressing them. Their ‘agility’ was their excuse for not delivering commitments. This sort of failure is not unusual – I’ve seen it happen in plenty of other teams. Dealing with these sorts of issues is hard for a team to do. Sometimes it takes an outsider to see them and point them out. So be careful about declaring your own agility. Doing so can sometimes hide some ugly spots.

This is What I Do

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

Maxims and Manifestos

February 13, 2019

My Dad has always been a passionate outdoorsman. For him, when it comes to spending some quality time, nothing beats hunting and fishing. So as a kid I spent a lot of time on the banks of rivers and streams with a fishing rod in hand or marching through fields of tall grass with a dog and a 12 gauge. It’s just how I spent many of my weekends growing up.

Hunting and fishing are complex activities. First, there is knowing where to find the fish or birds. Then there is selecting the right gear. Then there is an element of skill in using the gear to actually catch what you are after. That is actually a very broad set of skills and tools required to be a successful hunter or fisherman, and I’m not even getting into some of the woodcraft required to simply survive in the outdoors, let alone catch food.

I hope I’ve made a reasonable argument for hunting and fishing as a complex activity. After all, if it was easy, they probably wouldn’t call it hunting. That’s actually a little maxim that Dad used to share with me when I got frustrated. 

He had a bunch of maxims: 

  • “If it was easy, they wouldn’t call it hunting”
  • “You won’t catch a fish unless you have your hook in the water”
  • “Always use enough gun”
  • “Never wear red in a duck blind”
  • “Shoot it ’til it’s dead”
  • “Never pee on an electric fence”

OK, admittedly some of that advice was perhaps less useful than it could have been, but that’s how maxims work. It’s kind of left up to the reader to decide how to use them and whether or not they are worthwhile.

When the Agile Manifesto was created, there were 12 principles that were part of it. Each of these twelve principles expressed a key way of thinking about or viewing the world from what we would think of as an agile mindset or agile philosophy. At their simplest the agile principles form a set of reminders or guideposts on our journey through a complex environment that help us find agility or perhaps just remember where it was. You could think of each of those principles as really just a set of useful maxims – just like those maxims that my Dad used to share.

A manifesto can also be beneficial to teams. Of course, you can just point at the Agile Manifesto and use that, but I’ve actually found that teams can benefit from writing their own manifesto. Writing manifestos is actually good fun. There are a variety of them out on the Internet that you can look to for inspiration and examples. Aside from the Agile Manifesto, there is the Declaration of Interdependence, the Craftsmanship Manifesto, and more. If you want to have some geeky fun, check out the communist manifesto. There are hundreds of manifestos out there! Most manifestos are an attempt to declare a shared set of values. They are also usually expressing those values as a break from the past. If you look at them closely, most manifestos are usually a statement of values perhaps with some guiding maxims. That’s perfect for a team. 

My experience has been that teams have a lot of fun writing their own manifestos. It helps them to discover where they are empowered and where they have some autonomy. Being able to describe their own unifying vision goes a long way toward accomplishing that. However, you will find teams that struggle with this exercise too. From a coaching perspective, that struggle also represents an opportunity. There can be a lot of reasons that folks might struggle to write a manifesto. For example:

  • Not everyone is equally good with writing. Text based exercises like manifesto writing tend to fall flat for people who are very visual or physically oriented. Providing some visual tools, like a stack of magazines along with scissors and glue would be a good way to offer folks an alternative medium for expressing themselves if words aren’t their thing.
  • If there is significant dysfunction within the team. For instance, if they are being driven by a micromanager, then you typically don’t see a lot of independence and free thinking from groups like this. They might struggle with a creative exercise like this. These teams are often afraid to act without permission. There’s no quick fix for this, short of identifying the manager and starting to work with them.
  • Sometimes the team isn’t really a team. The reason they are struggling to come up with a common manifesto is…they have nothing in common. A team that is really just a group of independent actors will struggle to come up with a manifesto. They may manage to do it, but what they end up with is usually a watered-down mess that doesn’t feel like it’s very useful.

A good manifesto makes you feel something. A good manifesto smells like rebellion. It often feels a bit joyous too. Like something was unleashed. And when a team’s manifesto includes the customer, you know you have hit pure gold! If you read a team’s manifesto and the hair on your arms stands straight up, you’re on to something good. 

Running manifesto writing workshops is one of my favorite things to do. I’m always surprised at the outcomes. When people find the words that describe themselves as a team, they feel differently. Declaring that unifying theme to the world has power. Who doesn’t love that?

We Need a Map

February 12, 2017


“I have an existential map. It has ‘You are here’ written all over it.”

-Steven Wright

I happened to be in a cabin one evening after a long day of hunting. The wood stove was blazing and we were all chilling after dinner. The guides were off to one side hanging out together sharing their experiences from the day. It was fun to watch them as they described where they had been and what they had seen. The dialog would go something like this:

“We were down trail X off of the old logging road Y near the fork in the road and we didn’t see anything”
“You mean down past road Z near the bridge, right?”
“No, no, no. We were down logging road Y.”

Around and around they went.

At this point in the conversation they usually resort to hand gestures to further supplement the conversation. This goes on for a while and pretty soon it’s hard to tell whether you are looking at guides trying to tell each other where they were, or perhaps you are looking at a pair of fighter pilots describing their latest dogfight. There are hands waving wildly in the air. It’s Top Gun in the hunting cabin. Voices are raised, and expressions are animated.

And still they can’t seem to simply tell each other where they were. I’m watching all of this and I’m thinking, “These guys need a map.”

I’d laugh, but I see it all the time in software teams. If I’m honest, I catch myself doing it all the time. It seems that even with all the software that we have today, visualizing what we do and sharing it with each other is still a significant problem for us. How often do you find teams working together and trying to describe something – hands waving in the air and all. I guess we’re all future fighter pilots.

Like I said, I think sometimes what we really need is a map. I challenge you to go take a look at the walls in a second grade classroom. You’ll see nothing but maps. Maps of the US. Maps of the parts of a sentence. Maps of numbers. Everywhere there are maps of the knowledge that second graders consider important. What you see on those walls is the cartography of the eight year old mind.

Now go back to your office and look at the walls. What do you see? I’m betting that the walls are completely bare. Maybe you have some of those crappy motivational posters. If you are really lucky there is a map to the fire escape. There are no maps in the office of the typical knowledge worker. Why is that?

All too often we are like the guides in the cabin. We’re struggling to communicate simple concepts with each other – playing Top Gun. Maybe it’s time for a map.

The Corn Maze Strategy

October 10, 2016


Today was our annual family visit to the pumpkin patch. We go to a local farm that is a sort of pumpkin theme park. In addition to the fields of U-pick pumpkins, they have a petting zoo, pumpkin launchers, halloween themed play structures, hay rides, and a corn maze. It was a beautiful early October afternoon, and the kids roamed through all the usual activities. Finally we got around to the corn maze.

Now you should know that as these things go, this corn maze is pretty decent. I have no idea how large it really is, but my fitbit tells me that it’s at least a few thousand steps or so. I would guess it’s a walk of a mile or two to get through it. You should also understand that it’s relatively robustly built. You really can’t see any nearby landmarks, and the paths are kept far enough apart that you can’t see other adventurers in the maze. So it’s really quite easy to get good and lost.

So I followed the family in and tagged along behind as we made our way through the maze. I was tired, so I was perfectly happy to let the kids make all the decisions and accept the consequences. The pattern usually went something like this: We would come to an intersection and pause. We would look for clues on the ground. Was one path better travelled than another? Did the curve of the path look like it might actually form a loop? Did the path head in a direction that we thought might be the correct destination? We would ponder these questions and consult as a family before moving onward. So some sort of consensus was arrived at as we reached each intersection.

As I stumbled through the maze following my family, lost in my own thoughts, I started to observe how we were making decisions as a team. At each intersection there was usually some sort of debate. Arguments were made for and against different options. The group would informally arrive at a decision. We had the advantage of multiple brains rather than just one, so you would expect some sort of multiplier effect from using those additional noggins. But it really didn’t feel that way.

Instead we were bouncing around the maze, wandering into loops and blind alleys, and as far as I could perceive, we were not much more successful than someone walking the maze and flipping a coin to decide which direction to go. It was quickly becoming apparent that our success rate was hard to discern from a completely random performance. In fact, at some point I joked that we should be using a 20 sided dice to determine our next move. Geek family.

As we came around a bend I saw another family just standing at an intersection expectantly looking down the path like they were waiting for something. The father came running into view from further down the path and I heard him say rather breathlessly, “There’s nothing down that way guys.” We moved on and I couldn’t help but wonder about that approach. That family was using an interesting strategy. They were obviously making an effort to collect some information about the maze before moving on. That seemed to be one level of effectiveness beyond what we were doing. They were trying to look ahead and gather some intelligence that they could use to help make a better decision about the direction to go in the maze.

We continued to ramble about, but it was soon apparent that the kids were starting to get tired. My wife indicated that it was time for us to bring the adventure to a close before we had a riot on our hands. Dad, stop being such a slacker, it’s time for you to make a few decisions! So that’s when I had an idea.

At the next intersection, I sent a child down each avenue with the instruction to continue until they come to another split in the path and then to report back to me. Off they went. I figured I had two children, so I could afford to lose one with this experiment and still call myself a parent.

At the first junction, the kids came back and one reported a dead end, and the other reported yet another junction. Well that made the decision easy, so off we went. At the next junction however, both kids reported the same thing – there was another junction, but no indication beyond that. So it appears that my look ahead strategy had it’s limitations. There was only so far we could see ahead in the maze using my one intersection strategy. So we flipped a coin and moved on.

At the next intersection, we had a choice between an intersection and an obvious milestone, so we continued toward the milestone. A few more choices like that and we found the end of the maze.

As we celebrated and headed back to the car, it occurred to me that wandering through a corn maze is not all that different from the way that we work on projects as teams.
A project has a lot in common with a corn maze. In principle we all know how they work, but the path from start to finish isn’t all that clear when you start (oh you may THINK it is clear, but let’s face it, there are a lot of unknowns). So you kick off your project and get started and before too long you have to make some decisions. All too often when we make decisions as teams, we do it on the spur of the moment, using only the information that is immediately in front of us. Just like me and the family in the corn maze. We are only using the information that is immediately at hand. Decisions are made quickly with a minimum of information. It’s little better than a coin toss. But there is an alternative.

We can be gathering information to help us make better decisions. There are various names for this kind of look ahead strategy, personally I’m thinking of “set based decision making.“ In set based decision making you explore multiple alternatives. You look down multiple paths, but you don’t go too far. You are gathering just enough information to help you make a good decision now before you proceed onward. Just like with the kids running forward reconnaissance in the maze. This is how you improve the information you use for decision making, and this is how you give yourself a chance to make better decisions.

You see, projects have many important decisions to be made. You bump into them daily. Go the right direction and you are increasing your project’s likelihood of success, go the wrong direction and the project is that much closer to failure. These are high stakes decisions with lots of money on the line. So using the corn maze escape strategy is a good one. A small qualification is probably in order here: The look ahead doesn’t give you a crystal ball or a guarantee of success.

The point is that we all might benefit from using a conscious strategy to acquire knowledge that can inform our decisions. It doesn’t have to be very much additional information in order for there to be a substantial benefit. So the next time you find yourself on a complex project where you have to make tough decisions, remember the corn maze. The strategy you choose can make your journey a whole lot easier.

Roles Considered Harmful

December 27, 2014


“Man’s role is uncertain, undefined, and perhaps unnecessary.” – Margaret Mead

So there I was talking to a team that was split across two locations. There was the usual set of complaints that you might expect from a scenario where a team is divided across geophysical locations: miscommunication, delay, misunderstandings, etc.

In this case, the QA folks happened to be in one location and the development folks in another. As we talked through some of these issues, I couldn’t help but point out that the root cause – that separation between the two groups, could easily be solved: just split into two teams by location. Of course, that would leave us with a team of developers without any QA. Working with dev only teams doesn’t bother me (been there, done that, got the merit badge), but it was a different question altogether for this team member I was talking to. For them, the entire idea of removing a role from the team was completely untenable.

The first objection was, “If we don’t have QA on the team, who will keep developers under control? ”

Whoa! What? Back up the truck!

Who will keep the developers under control? Seriously?

At this point, I shifted gears and started asking questions about the team roles. I was concerned with this QA role that ‘controls’ cowboy developers. Why do we need to ‘control’ anybody in the first place? How exactly do you exert this control? What would happen if you didn’t control them?

It was quite an eye opening conversation. The more I looked at it, the more I realized that the roles of QA and developer had an astonishing amount of baggage associated with them. The QA role is the only role that can test code. The developer role is the only one that can write code. One can’t possibly be trusted to do the other’s job. It would be a lapse of ethical integrity!

Oh my God! Do people hear themselves when they utter this tripe?

Apparently not. No wonder we avoid creating roles or minimize them in some processes (i.e. Scrum, or better yet, swarming). It’s awfully easy to come to the conclusion that roles carry as much dysfunction as they do benefit for a team. They invite definition and structure, but in doing so they also create walls and barriers to effectiveness and efficiency.

As soon as you create a role that is entirely responsible for quality (or anything else for that matter), you do three things:

  1. You define their job, and by doing so, you make a distinction between “the things that I do” and “the things that you do”. It starts to define what you can and can’t do. That’s useful if you are trying to subdivide work. But not so useful if you are trying to create dynamic, flexible teams that adapt themselves to unanticipated changes. You know…Agile?
  2. You create an in-group and an out-group. In psychological terms, you are creating an “us” vs. “them” distinction which almost inevitably leads to conflict.
  3. With these foundations, our thinking is constrained about how the process of value creation should work. The distinctions that we hold in our heads are what we use in order to create the boundaries of our processes. We find these boundaries between Dev and QA, sales and product, managers and teams, and yes, even Scrum Masters and coaches. They’re everywhere.

Obviously, roles can have profound impacts on how people think about their relationship with the people they work together with. So what can we do about it?

As I asked further questions, it became apparent to me where I might go. Talking to the team would be a complete waste of time. They didn’t define the roles. They were hired for the roles that their managers defined. So step one is talking to the managers.

Of course managers are people too. They are only trying to fit in the hierarchy and culture of the company. Eliminating roles would be a very threatening thing to a manager whose whole career has been based on making and supporting such roles. So we can’t expect a whole lot of help from there either.
Of course you could just show them…

There are some talented developers I know, coaches really, who are very good at working side by side with teams and demonstrating by example how to blur the distinctions between roles. You can even do it yourself with other managers. Build those relationships. Help them out. Show them how it feels to have someone else help out that doesn’t have the same role as they do.

In the end, I think it comes down to people being able to experience what not having hard defined roles is like. You can’t talk them into it. You just need to roll up your sleeves and demonstrate with them.

“I’m not playing a role. I’m being myself, whatever the hell that is.” – Bea Arthur

Scrum Masters Considered Harmful, Paul Hodgetts
Us and Them: The Science of Identity, David Berreby