My Personal Andon Cord

April 29, 2019

Have you heard of an Andon Cord? On the assembly line it’s that cord you yank on to stop the entire line when a problem is found. The idea is to stop everything until the problem you encountered is fully understood and fixed. That way we take the time to improve the function of the assembly line so that those sorts of problems never slow us down again. It’s a little example of that “slowing down to go faster” that those crusty old software curmudgeons blather on about.

But who listens to those old cranks anyway?

I was thinking about a recent Product Owner training I was running where I was told that the product owners didn’t actually sit anywhere near the team (that was assuming they had a product owner to begin with, but I digress). It turns out that the product owner for a given team was very likely located in another building or even perhaps another state or country altogether! This kind of colocation issue is fundamental to improving a teams performance. Address it and you will see meaningful improvement quite quickly. Fail to address it and you will be wrestling with the side effects and consequences forever without dealing with the underlying problem. 

So what did I do? Well, this was just the start of a two day training, so I had at least a day and a half more of training that I was expected to deliver. So I tossed that issue on the mountain of other issues that I was uncovering and moved on. Trainers gotta train, kids gotta eat. I raised concerns, told the right people, and moved on. Everyone kept moving.

Now in hindsight, I’m not sure if I should be proud of dismissing something that important. However, I know it happens all the time. But it makes me wonder, is there an issue sufficiently important that I would call the whole class to a stop in order to address it? What would cause me to stop the line as a trainer? Where is my trainer Andon cord?

If a fist fight broke out in class, I’d certainly stop the class. So there’s that. But what else? If someone was crying, I’d stop the class. If I found out someone was being hurt, I’d stop the class. But if I found out they were doing something stupid…I wouldn’t necessarily stop the class. I might pause long enough to mention that I wouldn’t recommend doing that. Maybe I’d hand them a Darwin Award (oh, now there’s an idea…). But stop the class? No.

Let’s look at that example of the product owners in a different location than the team. Colocation of product owners or customers is pretty fundamental. You would stop the line if you found out that the car’s tires are missing. If someone told you,”It’s OK, we keep them in another building.” You would probably be well justified in insisting that the tires get brought in pronto. There’s not much point in leaving silliness like that alone. So I’m asking myself, if the customer has paid me a few thousand dollars for the training, but instead of delivering the training, I stop the training to focus on that one problem…what would happen? Fixing that problem could probably mean a huge return on investment for them. Something far beyond the paltry amount they have spent on the training. It’s food for thought. 

On the other hand, typically these types of organizations are not in a place where they are accepting or tolerant of radical change. Usually few if any folks in the room are actually empowered to do anything to change the situation. Furthermore, even the folks who hired me may not have that power. You have to have a lot of credibility in an organization before you can even start talking about that sort of change. Credibility takes time, and that’s something that most trainers don’t have. You’re in, you do the training, and you’re gone. Poof of smoke. Vanished.

So in the big picture it probably depends on your context. If you are just in for a quick one-time training, then you really don’t have the credibility to stop and attack problems like this. On the other hand, if this is part of a long term engagement, then there is the real possibility of being able to deal with problems like this in real time. To be able to pull your Andon cord and stop the line. What a marvelous thought.

A House for Hermit Crab

April 23, 2019

One of the wonderful things about being a parent is all of the children’s books you get to read. I never fail to be amazed at the simplicity, grace, and sheer storytelling genius that I find in many children’s books. I’m thinking of amazing books like Where the Wild Things Are. It’s stories like these that seem compelling no matter what your age. One of my personal favorites is a little story by Eric Carle called A House for Hermit Crab.

In this story, our hero the hermit crab has grown out of his old shell and it’s time to find a new one. So off he goes and finds himself a nice, brand-spanking new shell. He’s pretty pleased with the fit, but to be honest, it looks a little plain and could use a little decoration. So our hero ventures forth in search of a little bit here or there to decorate his new home with. Each time he meets a new character (a starfish, an anemone, a coral) he greats them with great joy, compliments them on their beauty, and invites them to share his house with him. It’s a long journey, and at the end of a year he has a magnificent shell covered with many dazzling creatures. Just as he feels happiest, he realizes he’s growing out of this shell, and with some regret moves on to a new shell.

This story speaks to me on a couple of different levels. Like the hermit crab, I have adopted different process frameworks (call them shells) over my career. Early on it was XP. Then it was Scrum. Then SAFe…and God only knows what the next bright shiny framework is that I’ll wear. And with each one, I discovered unique practices that seemed like useful additions to my process house. These were practices like test driven development, pair programming, mob-programming, and so on. Each one I held up to the light and thought, “You’re awesome!” And invited my teams to try them. It took years, but I collected quite an array of decorations for my shell. Usually, just when I felt pretty confident with it all, I started to outgrow that shell, and with some regret, moved on to a new shell. So the process repeats itself. I know that my journey has been metaphorically very similar to that of the hermit crab. I adopt a model, modify it to make it mine, and eventually grow out of it.

There’s another reason A House for Hermit Crab speaks to me. It’s the delightful open and inviting attitude of the hermit crab as he meets each new creature. I feel the same way about a lot of the people, practices and processes in our agile community (…and beyond). I guess I tend to err on the inclusive side. I think of it as a “play first” approach. Extend the open invitation and see what happens. All too painfully often our community tends to do the opposite. There is far too much, “That’s not agile” and far too little invitation to join and explore together. I think that our little Hermit Crab has an admirable way of approaching novelty.

Ultimately, I think I like the way that A House for Hermit Crab makes me feel. Not to get too precious about it, but this feeling of open invitation is what I long for the most. It’s what originally drew me to agile in the first place. We all will likely have many different shells (or models, or frameworks) that we will inhabit at one time or another as we grow. We should invite each other to decorate those shells to reflect what we think is beautiful, and share them with others. That is what motivated me to write my recent series of articles about SAFe Mix-in’s. SAFe is the shell in this case, and we can decorate that shell any way we please with many interesting practices. If you are curious, like me, and want to decorate your own shell, check out the following Mix-ins:

Perhaps my SAFe shell is starting to feel a little cramped, so maybe it’s time I shared it with someone else.

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: Open Space

April 22, 2019


One of the interesting things about SAFe is how it has evolved over the years. The story there is very interesting. More so than any other framework that I’ve witnessed, SAFe has very definitely changed since its beginnings through what it has become today. For example, early on, it didn’t have the levels of work that it does today, and certainly the terminology has evolved. Furthermore, many of the roles have been added and changed. To a very real degree, things like DevOps and Continuous Integration and deployment have been added as well. These new additions were nowhere to be found in the early years of SAFe. 

So, all of this is to say that SAFe has evolved in terms of its framework and structure quite dramatically from its early beginnings. And in fact, it continues to do so, which is what I find so beneficial about it. Furthermore, the way that we perform certain ceremonies in SAFe has changed. For instance, a good example of this change is how we prepare for and run a PI planning event. Originally, PI planning was a very quick event. You oriented the teams in a SAFe for Teams workshop and then right after that, you started PI Planning with no other preparation than that. You could go from zero to SAFe PI Planning in a week. As a result, the planning event was very intense, open and collaborative. There was none of the long, drawn out planning cycles that you typically see in PI planning today.

Over time that has turned into a much more deliberate sort of event. So now PI planning typically involves months of preparation as you prepare initiatives, and features, and stories for use in the upcoming PI planning. There’s lots of review and refinement that goes along with that. But originally, PI planning wasn’t like that. Originally PI Planning was much simpler and was more similar to what you and I might think of as an Open Space event.

You can find out more about Open Space here:

An open space event is where we go into the event with what we hope is some sort of compelling theme that’s going to drive the conversation. That’s all we have to start with. We have a stakeholder who delivers that theme and tries to provide as much color and context as they can to make the theme as vivid as possible. Then everyone in the room is responsible for coming up with how they are going to address that theme. From there, we leave it up to them. In the case of a business, you might put a key deliverable or initiative forward as your driving theme. It could be a key set of features – whatever compelling idea that you believe the market needs. You put it in front of the group and then you leave it to the teams for those two days to figure out how to proceed and let them organize the work as they see fit. The teams are responsible for taking that initiative, breaking the features down, identifying the stories, working out the dependencies and planning the work. They keep track of their work by putting it up on a big wall which looks a lot like an open space marketplace. After two days, you review your plan and you are done and ready to get started.

Running PI Planning as an Open Space would have some interesting implications:

  1. Open Space makes it clear that anyone can contribute ideas, not just particular people in a given role. PI Planning depends on initiatives and features provided mainly by key stakeholders and product management. I think Open Space would promote a more democratic input process where teams, who often know a great deal about the business domain, would be more able to contribute their own ideas for features, etc.
  2. Open Space has no formal collaboration structure beyond the marketplace. Wherever you meet is the “right place” whatever time is the “right time” and whoever shows up are the “right people.” That’s terrifying level of informality for most organizations, but it also opens up a great deal of freedom for those who can own their work. There are synchronization points in Open Space, like the morning and evening “news” where everyone gets to see what others have done and see changes in direction. My intuition is that I would want to spend time getting folks used to Open Space first (on other topics), before trying to substitute it for PI Planning.
  3. Open Space has the concepts of the “Butterfly” and the “Bumble Bee” – those people who flit from group to group, perhaps pollenating an idea or two. Even if we don’t use Open Space, I think these ideas by themselves would be useful to introduce to PI Planning.
  4. Open Space does not dictate the kind of work that can be done. Teams can write code, call customers, leave the room – anything that enables them to best pursue their ideas. This form of hybrid working/planning could be much more powerful than focusing exclusively on estimation and planning. 

If you find that your PI Planning has become very rigid and stale, you could try using Open Space to free things up. You have the option of incorporating just a few of the elements of Open Space, or you can go “All in” and completely replace PI Planning with Open Space. Or, you could keep PI Planning, but introduce Open Space in a separate forum. There are a lot of great options here for us to explore.


  • PI Planning feels stale and rigid
  • You’re looking for way to foster innovation

Framework Impacts

  • Replace the PI Planning with Open Space (same time commitment as PI planning, but less structure)
  • Less pre-PI Planning effort


  • More ownership of team direction and work
  • Potentially better plans because work can be actively investigated alongside planning (due to loose Open Space structure)

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: 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: The Core Protocols

April 17, 2019


For some organizations that prefer to have things really well explicitly defined or proscribed, especially if they are in a SAFe transformation, they might want to consider taking a long look at Jim McCarthy’s Core Protocols. To me at least, there is a very natural fit between the Core Protocols and SAFe. The Core Protocols define the kind of interpersonal interactions that you have on a team and SAFe defines the interactions that you have at a cross-team level and above. So, to a certain degree, especially for organization that are really seeking a highly proscribed picture of what to do next, it seems that the Core Protocols and SAFe might be well suited to each other. 

In fact, you might find that you can even evolve the core protocols to some degree. So how would this look? Well, Core Protocols specify, step-by-step, how to define major team interactions. An example is the Core Protocols Check In, where at the start of a meeting you will go around the group and have every person tell you what their current emotional state is, in terms of being mad, sad, glad, etc. Simple attributes. By doing this we get an emotional check-in and a starting point for everyone in the room, and we make it visible. So, it aligns with our need to keep things visible and transparent within the team. It also makes it clear where people are coming from. This Check In, could easily be incorporated into any meeting that you are using in SAFe, whether that is a team level meeting, or a scrum of scrums, PI Planning, any of your higher level meetings across the board. 

That’s just one example. There are about a dozen different protocols within the Core Protocols that could be incorporated in a variety of places. Here’s a short list:

  • Pass(Unpass)
  • Check In
  • Check Out
  • Ask for Help
  • Protocol Check
  • Intention Check
  • Decider
  • Resolution
  • Perfection Game (I love this one)
  • Personal Alignment
  • Investigate

Another example of a Core Protocol that we might use is the Perfection Game, which again can be used in many places in SAFe. It’s a wonderful way of providing feedback and you could incorporate it anywhere that you have reviews or retrospectives. Basically, you give feedback starting with a score of 1 to 10 (10 being perfect). Then you provide examples of what it would take for them to make that score a 10. So, for example, I love the new widget feature and I would give it an 8 out of 10. To get to a 10, I would change the widget so that it takes 1 mouse click instead of 2 to perform that action. That’s pretty much all there is to it. You let the person know how it rates, and then you provide the feedback to help them get to great. If you can’t think of anything to improve it, then you should probably give them a 10. I use this feedback mechanism all the time and folks really seem to appreciate it.

The more I think about this particular mix-in, the more I think there is a small bit of genius to it – at least for some organizations. I think there are some places where it might be very popular. We might also discover along the way that there are a few protocols that can be used at higher levels when having strategic discussions and at the portfolio level or solution level in SAFe. My belief is that there is actually a fair amount of room for creative interpretation and mixing of Core Protocols with SAFe.  


  • You are seeking more proscriptive guidance for certain team level interactions

Framework Impacts

  • None


  • More explicit guidance for healthy team-level interactions

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: Sociocracy

April 16, 2019


What if you are a big fan of sociocracy or holocracy? Can you combine those practices with SAFe? Right now, when you look at SAFe you see teams at the team level (of course), programs at the program level (or release trains anyway). However, at the executive or portfolio level you don’t see any specific recommendations for how to organize into teams or groupings or aggregations. I think the portfolio level is where sociacracy or sociacractic methods might come in handy in SAFe. So perhaps it’s time for a brief overview of sociocracy. 

Basically, there are two key attributes of sociocracy as I understand it. First sociocracy involves a hierarchical arrangement of people into circles or groups. I don’t think there are any strong definitions around how those groups are composed. In essence, you have the people who are doing the work, or those closest to the work, in a group or team or circle. You have group appointed representatives that will be representatives at the next level or circle up in the hierarchy. So that next level up is perhaps a group of related teams or teams working on a similar product or effort of some sort. That higher group is your next sociocratic circle. That circle, in turn will have members that represent it at the next circle up, yet again, to some top tier circle that would represent the executive team or directors, depending on the scope and scale of the organization in question. There’s no real limit to the number of levels of circles in this hierarchy. So it’s a hierarchy of circles.

The other key attribute is that decision making is made by consensus within each circle, not majority voting. Decision making is something where we are seeking everyone to come to the point where they understand the problem and they believe it is the best possible solution, even if it is not their favorite, among all the solutions presented. This is very different from an in-or-out roman voting system, where the majority wins. In roman voting there are winners and losers. The losers think the winners are idiots and the winners think the losers are whiners. Using roman voting you only get partial commitment from the winners and zero engagement from the losers. Consensus, on the other hand, has commitment from everyone. With Consensus everyone agrees this is the best path forward, even it isn’t their favorite. Frankly, it’s a much higher standard of agreement to try and achieve.

You can find out more about Sociocracy here:

With these the two key attributes of sociocracy: the hierarchy of circles and consensus-based decision making within circles, the question is, within SAFe how do we apply this? Well, we already have consensus-based decision making using the “Fist of Five” technique in SAFe. We don’t use it everywhere in SAFe, but it is used prominently at events like PI Planning. It’s certainly something that people are familiar with and comfortable with and it would be easy to incorporate into other areas within their organization. So, if we are going to apply sociocracy and one of the elements we are going to use is consensus-based decision making, then we can assume SAFe will have no problem with that, and we can call that a win. 

How about all those crazy hierarchies of circles that sociocracy has? Well that’s where we might have to change SAFe a little bit. Now if you look at the team level it’s quite clear that SAFe already has “circles” at this level. If you go up to the next level, the program level, and look at the release trains, again, the people are participating in things like the scrum-of-scrums, those people are basically forming your next level up of circles. So, so far, our hierarchy of circles that we might see in sociocracy is well represented already within SAFe with no changes. 

So, let’s go one more level up. At the top level this is where we might have to introduce change, because as far as I know, SAFe has no guidance for what kind of teams or organization should be used here. In fact, SAFe says little or nothing at all on this topic. It’s at the portfolio level where we would be asking the management teams, the executives, to form circles of their own. How many circles is going to vary depending on the size and scale of the organization. For instance, if we are looking at multiple divisions, there might be circle for each division and then a circle above that with representatives from each division…and then a circle above that representing some larger organizational context. That in and of itself is not a particularly challenging thing to define. Actually, I think many organizations implicitly do that in one form or another. 

However, I think it’s important to keep in mind that the idea of having representation from lower circles has to be captured here. That’s where I think that introducing and formalizing these teams and groups is important. You could use something as simple as executive scrum teams (or something of that sort). It would be useful for executives to walk the walk and talk the talk the same way everyone else in the organization may already be doing. So, to some degree it’s just a natural way of taking scrum and spreading it throughout an organization. Or Kanban, or whatever team-based organization tickles your fancy. The underlying idea: to use the circle model to spread the team behavior at the team and program level upwards to the executive level.


  • You are seeking ways to further empower teams
  • The executive team is willing to structure themselves in the same fashion as everyone else

Framework Impacts

  • At the portfolio level, we introduce circles


  • More ownership of team/circle direction and work
  • Executives tied into the same process the rest of the organization uses, with the associated benefits

Did I mention sociocracy probably isn’t for everyone? Because it’s definitely not. But it could be really cool to integrate elements of sociocracy in organizations where the culture is a good match.

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. ‪ ‬

One Step Back, Two Steps Forward

April 15, 2019

I was confronted with a bit of a dilemma the other day. I was working out and reaching the limits of what I could lift. I could tell, because as I prepared for each lift, I was a little bit scared. I didn’t really know if I could do it or not. Then I would perform the lift, and barely, just barely, make it. It wasn’t pretty, but I did it. Afterward, as I lay on the floor hyperventilating, I had a lot of conflicting thoughts running through my mind. I’ve been working toward a lifting goal for a long time now. I’m getting tantalizingly close. I can’t stop now. I’m not getting any younger. Time is short. If I keep this up I’m going to seriously injure myself. This is really painful. It’s no fun being terrified of the weight. I can’t stop now. I don’t know if I can do it again. Dear God, I hurt.

I don’t want to make too much out of it, but suffice it to say that I was seriously conflicted. I’ve literally invested years in getting my lifts to where they are today. It’s hard to step back with that kind of investment behind me. On the other hand, that’s a lot of investment to waste by injuring myself. So it’s a real dilemma, especially when I feel like I’m so tantalizingly close to my goals. Part of me is screaming, you’re almost there! And the other part is begging, pleading to back off.

Where else do we see this kind of goal oriented struggle? Developing and releasing a product? Getting a promotion? Saving up for something big like a new house? We see it anywhere there is a large investment over time toward a meaningful goal. The danger is that if we over reach, we may lose the opportunity entirely.

In my case, I decided that the prudent thing to do would be to take a few steps back. So I rolled back the weights and the intensity a few notches and started over again. I was back to lifting weights that I had been lifting nearly 3 months earlier. Three months is a lot of time to lose! However, I noticed a few things:

  1. It was so easy! I felt my confidence come roaring back.
  2. I was so much stronger than I had been. Where before it had been a challenge, now it was second nature.
  3. I was performing cleanly and confidently, not scrabbling to survive the experience.
  4. I no longer feared injury.

The road has gotten a little longer, but now each step I take feels more confident and certain. This is where having a coach can make a really big difference. They can act as that voice of reason that will help to steer you through these decision points. They act as a relatively unbiased party that is invested in your success. They need to know the domain really well – I would never take a coach who didn’t know about weightlifting. They need to have an experimental mindset: everybody is different, things that work for one customer won’t work for another. And they need to be able to firmly give constructive advice for change, even when the customer really, really, really, doesn’t want to hear it. Perhaps then most of all.

I don’t have a coach right now (perhaps I should take my own advice). I know that if a coach had told me that I needed to go backward three months in my training, I would have resisted. That would be crazy talk. And yet here I am. I think I now appreciate it a little bit more when I work with managers. I often recommend that they do things that would appear to be backward steps. For example, I might recommend pair programming for their teams. I often get the horrified reaction, “You mean twice the number of people doing half the work?” Uh, yes. That’s a giant step backward. Especially when you feel as though your teams are performing at what may be the best they have ever done. I think I get it now. That’s not an easy sell.

But a good coach knows that a few steps backward can lead to later leaps forward. A good coach is invested in getting you there. A good coach knows you will build confidence and capability, and that has value too. And a good coach won’t back down when they know it will help you reach your goals.

Oh, and if you are looking for a good coach, I’m available.

SAFe Mix-in’s: Role by Election

April 12, 2019


Another modification to SAFe that we might make is role by election. Role by election is turning some of the role selection process on its head. for example, as in dynamic re-teaming, we’re going to allow the teams to make more decisions themselves, we’re going to allocate more power to the team and less to the management. In this particular case, this goes back to the way that value streams, release trains, and solutions are created. Again, the typical way this is done, is these groups are appointed by management or key stakeholders. Selection by management implicitly takes power away from teams and also tends to employ those who are most respected by management, but perhaps not those most respected by the teams. 

To fix this, when we’re creating value streams, release trains, or solutions we need to let the teams pick their own leadership. They get to pick who the release train engineer is or the solution leaders. They pick the architect and the product manager as well. Now this could be as simple as getting these groups together and asking them to elect these people by popular vote. You might have product owners elect the product manager. You might have the development teams elect the architect and the release train engineer. It would be quite simple. Basically, you are switching from leadership by appointment to leadership by election.

In its simplest form, this really is the kind of thing that you could do when you are initially rolling out SAFe. Or you could do it over time, perhaps iteratively. For example, I know that being a release train engineer is a lot of work. And it’s not something that I necessarily see as a career path for the rest of my life. If I get elected for the job for one PI for example, I might be happy to contribute and help out, but I might not want to do it forever. So, we might hold another election at the next PI. And each PI you would elect someone new for each of the roles. That way we also can get away from treating some of these roles like job descriptions (which often happens) and keep them as temporary roles that we fill as needed with people who have the right energy and the right support to make it happen. And doing this with some sort of democratic process seems to be a reasonable way of doing. It

Of course, this means as managers we have to give up some control over who is leading, and that could have some HR implications too. It’s a hard thing to ask for, but there is so much to be to be gained:

  • People elected to these positions will have the approbation of their peers, and feel supported by them, having been elected to these positions rather than having been appointed or pushed into these positions. 
  • The teams will feel happier that they have had a voice. So, it empowers the teams, and they’re going to be working with or lead by somebody most capable of leading them, which also makes a great deal of sense
  • It is an opportunity that can be shared by re-electing on a periodic basis so that others can get experience in this role. This leads to creating more opportunities for leadership within the organization for everyone.

So it’s win, win, win.


  • You want the highest possible engagement and buy-in for your transformation
  • Management is willing to let go of the responsibility of role selection

Framework Impacts

  • None really, SAFe doesn’t dictate how roles are selected or changed


  • Improved buy-in and engagement from teams
  • Less burn out in key roles

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: No Prep PI Planning

April 11, 2019


One of the issues that I’ve seen with doing big room planning (BRP) or Program Increment (PI) planning in SAFe is often people tend to over-prepare for these events (a quick note here: I use the terms PI planning and BRP interchangeably). And let’s face it, there are often good reasons for why they might do that. PI planning is a big event. It’s expensive. It involves a lot of people. There’s a genuine reason to worry that if you show up without any work, you’ll be wasting a lot of people’s time and money. 

With that rather intense pressure in mind, what you tend to see is a lot of well-intentioned labor to make sure that PI planning is very, very, well prepared for. This leads us down a road that I’ve travelled many times. At Rally we had a BRP launch checklist. That checklist was for a nine-week process for preparing for big room planning. That was nine solid weeks of breaking down the work, reviewing the work, and estimating the work prior to the big room planning event. If you stop and think about it, nine solid weeks of preparation is an enormous investment. 

Therefore, if you think that 2 days of everybody’s investment is a lot of work for the event itself, then the nine weeks leading up to that is even worse. The burden falls on a relatively small group of people, usually product management and a few others. In many cases I’ve heard product management come back to me and say, “We like the collaboration at the end of the nine weeks, but this preparation process is murder.” If you’ve participated in this process, then you know there is a grain of truth to this concern. Even worse, I’ve seen instances where new unanticipated work was discovered in the BRP and therefore the conclusion: we need to invest more in planning next time. It becomes a never-ending nightmare cycle. Miss something, plan harder. Miss something, plan even more. I call it “Falling into the requirements black hole.”

So how do we avoid this pattern? What I would propose is that we lighten up that preparation process. I call it the “No-Prep BRP” or “No-Prep PI Planning.” After all, one of the underlying reasons that we’re afraid of wasting our time is we don’t trust that people can break down the work or do meaningful work without us preparing it all like pre-chewed baby food for them. And that’s simply not the case. 

In a no-prep BRP, it’s not that we would do no prep at all, but that we would minimize it to the greatest degree possible. In some sense this isn’t all that different from open space. Open space doesn’t have elaborate preparation, rather it has the absolute minimum of preparation. In fact, often times people don’t know what the issue is until they walk into the room. In a no-prep BRP what we are going to do is prepare the initiatives at the highest possible level. We’ll try and articulate those initiatives as well as we can, but we are going to stop there and go no further. Also, we’re not going to estimate – we’ll leave the estimation completely out of it. We’re going to spend more time on customer validation. Rather than focusing on sizing, we’ll focus in validating that this initiative truly has the right outcomes that are truly meaningful for our customers. 

You can find out more about No Prep PI Planning here:

  • Actually, there isn’t anyone calling it that, but we could start a trend…
  • Ivar Jacobsontalks about lightweight PI Planning

Using this lightweight process, we’re going to invest our time differently. We’re going to spend it more focused on the customer and less focused on the estimation. Once we get it all together, then we deliver it as we typically would in our BRP, but at that point it then becomes more of a Q&A and more of a dynamic breakdown that we are going to engage in with our customers (who are hopefully present) or our stakeholders. 

Part of the reason for the exhaustive preparation for big room planning is that these are organizations that are accustomed to having detailed plans. Detailed plans being one of the most important outputs for these kinds of organizations. Unfortunately, they haven’t learned the lesson that no matter how detailed the plan, “stuff happens” that no one can anticipate in software design. In an effort to try and compensate for this, they only try and squeeze more and more detail out of the plan in the vain hope of trying to detect the “stuff” in advance and somehow avoid it. Which by now we know that in a design process is nearly impossible. 

With that in mind, we need to change our focus for the BRP. The BRP is no longer about outputting the plan. The BRP is the start of a collaboration. It is the start of a conversation. It is the start of discovery, but it is by no means any sort of end result or end product. That means that in order for this to be successful we’re going to need to be a little bit more thoughtful about encouraging interaction throughout the duration of the planning increment. That means that our scrum of scrums and other activities are going to need to be more collaborative and we are going to lean on them more heavily, because plans will change. I think it’s a better reflection of the way that software design works, but nevertheless some organizations may not be able to tolerate this. And that implies that some organizations wouldn’t want to consider this. But for those that are willing and ready, doing the no-plan BRP may be the way to go.


  • PI Planning Prep is getting too heavyweight and oppressive
  • Product management is willing to plan less and discover more

Framework Impacts

  • None really, SAFe doesn’t require extensive PI Planning as such


  • Improved collaboration between teams and product owners
  • More time spent with customers and less time spent on endless estimation

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: The Prescriptive Mirror

April 10, 2019

There are two attributes of SAFe that I think have really been instrumental to the success of SAFe as a framework. The first attribute is The Big Picture. You’ve probably seen it before. It’s the great big diagram of the SAFe process that illustrates where and how teams, programs, and portfolios relate to one another. To me, The Big Picture is a mirror for any organization that is looking for a better framework or better process. The minute they look at The Big Picture in SAFe, they see themselves. That’s what a mirror does, it shows you your best self. It shows you the flattering view of what you might look like. It gives people in large bureaucratic organizations a pretty picture of what they might look like if they were agile. It’s flattering to them, and seems achievable.

It may not be flattering to everyone, but to many organizations that are struggling with how to adopt agile, The Big Picture is really an attractive portrait of how they might start down that path. I think that was my first reaction the first time that I saw The Big Picture. I was working in a very large bureaucratic organization and after seeing The Big Picture I could envision the next steps that we needed to take toward becoming a more agile organization. And just like when I look in the mirror every morning, I just see my 18 year old self (true). I don’t see the love handles (ha!) or the receding hairline. For some reason or another, it seems that when we look in a mirror, we only see the best bits. I think that’s exactly what you get with the SAFe Big Picture, and it’s one key element of SAFe’s genius.

The second attribute that has been instrumental in the success of SAFe has been the very prescriptive nature of the framework. SAFe has done a better job than literally any of the other competing scaling frameworks out there in terms of documenting and providing prescriptive answers for all of the processes that are described in the big picture. It’s exhaustive and that is exactly what these big customers want. They want a prescriptive checklist on how to achieve that Big Picture vision that they have fallen in love with. And so that’s exactly what SAFe has done with their documentation. It’s really quite impressive when you dive into it, and it continues to expand and evolve.

So given all of that: The Big Picture used as a mirror and the prescriptive nature of the documentation, together they are kind of a one-two punch that’s really killer for big, bureaucratic organizations. As such I have no complaint about that (and more than a little admiration for an organization like SAI that truly understands their customers). There are a few things that we need to keep in mind. For instance, when people look at The Big Picture what they see is an attractive end state. However, there are lots of different end states in the real world. There are lots of possible outcomes for organizations. When people look at the SAFe big picture they only see one outcome. To some degree SAI have addressed that concern. They have created the different packages (Essential SAFe, Portfolio SAFe, Solution SAFe, Full SAFe) acknowledging that not one size fits all.

However I think we can go further. I think what we are going to see is that SAFe is going to continue to evolve over time. So what I’d like to see is a hypothetical SAFe 8.0 where, we haven’t gotten there yet, but this is what SAFe might look like down the road. It might be something that has many alternative paths. I think if we can start to provide those future scenarios or pictures then we can start to give guidance beyond the first big picture. We need to move from the path TO SAFe, onward to the path FROM SAFe to whatever is next. We can start to help guide organizations on the evolutionary path toward a more agile future.