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. ‪https://bit.ly/2HXCcKD ‬

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. ‪https://bit.ly/2HXCcKD ‬

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. ‪https://bit.ly/2HXCcKD ‬

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. ‪https://bit.ly/2HXCcKD ‬

SAFe Mix-ins: Mob Programming

April 2, 2019

I’d like to talk a little bit about SAFe mix-ins. SAFe mix-ins are innovative practices in the agile community that we can incorporate into popular frameworks like SAFe, LeSS, or DaD (to name just a few). To me these mix-ins represent an opportunity for us to improve the performance of our teams within existing large scale frameworks, and that ultimately serve to enhance and provide benefit to us and our customers.


So, with that in mind, the first mix-in that I would like to address is mob programming. Now, if you haven’t heard of mob programming, it’s relatively new. It’s been around in the agile community, at least as far as I can remember for about the last four or five years or so. Its original proponent is a guy by the name of Woody Zuill. Woody probably describes it best, so here are a few references to mob programming and how it works.

In two sentences or less, mob programming is basically getting the entire team working together in a structured fashion to work on a single problem at a time. This is usually done in a team workspace in front of a big screen. It has a variety of intriguing benefits:

  • Helping to train everyone at the same time.
  • Getting all the minds and the wisdom of the crowd looking at the problem simultaneously.
  • Generally bringing the team together to work together closely and collaboratively. Working in, dare I say it, an agile fashion.

There are also some rules to mob programming, but not many:

  1. There is one and only one driver. The driver is responsible for doing all the typing. They own the keyboard.
  2. Everyone else is a navigator. The navigators are giving the driver directions and keeping an eye on where you are headed next.
  3. Roles are swapped frequently. Being the driver is exhausting, so we swap out the driver role every 10 minutes or so. Everyone gets a chance to drive.

With these sorts of benefits, mob programming is the kind of activity that I would describe as a technical practice akin to pair programming. As such, it really represents no disruption to incorporate it into any of the existing frameworks. It’s relatively easy for us to incorporate it into SAFe. For example, if one team on your release train decides to adopt mob programming, great! It’s no problem, it doesn’t impact anyone else on any of the other teams. Furthermore, if you were to adopt it across all of your teams on a release train, you might find that they all might accrue the benefits of mob programming – without affecting any other release trains. All of this works out to our benefit. 

SAFe Implementation

So, with all of these things in mind, adding something like mob programming to a framework like SAFe seems like a fairly pragmatic and useful idea. Certainly, at its worst it’s harmless – it doesn’t hurt us in any way, shape, or form. And at its best, it helps us to improve the performance of the teams. Furthermore, it has no side effects or impacts to any of the existing practices, artifacts, roles or structures in the process that is SAFe. So, from that perspective it’s really quite useful. 

Now, there’s probably one other thought that some may have which is, “Hey, if it’s so useful Tom, why don’t we put it into SAFe and formalize it?” I’m not sure that’s really necessary or frankly a good idea. After all, SAFe is espoused as a framework and as such should probably be kept as minimalist as possible (I know there are some who would laugh out loud at that last statement). I don’t believe that we should take every single technical practice that we happen to stumble across and stuff it into our definition of a framework.

The other thing that I like about the practice of mob programming is that it is so low impact that it doesn’t represent the kind of change that might seem to be challenging for some of your more conservative organizations. This is the kind of mix-in you can add relatively easily to an organization that might otherwise find more substantial types of change very challenging to adopt. In this particular case, mob programming is easy to slip in and try out. It’s low risk and has no noticeable effect outside of the team (unless, of course, it’s advertised). These sorts of mix-ins are probably the best-case scenario for starting to introduce subtle change and subtle evolution into frameworks like SAFe, LeSS, DaD, Nexus and others.

I guess there is one other question that we should ask ourselves anytime that we try to change our process: What problem are we solving? Let’s think about that question in terms of mob programming. How long does it take to add new people to the team and get them up to speed and contributing at the same level as everyone else? Do you have silos of specialization, where there are only one or two people who understand a component or subdomain? Are people able to easily switch roles on your team when someone is missing? If these are the types of problems you face, then perhaps mob programming would be useful. You could certainly easily measure improvement relatively easily. 

I’ll also offer this thought: When you take a step back and take a look at the PI Planning process, it’s not a whole lot unlike elements of mob programming. It’s inclusive, everyone in the release train is asked to join and participate. Each team has its time in the sun where they share their plans with the other teams. And it’s an intense period of learning for everyone involved. You could think of it as mob planning. So, this mobbing concept might be useful in other domains outside of programming too.

Forces (What Would Lead You to Do This)

  • The organization is resistance to change at the program level and above
  • Work encounters bottlenecks within the team
  • Team is struggling to bring team members up to speed quickly
  • Team composition may be changing frequently due to growth or turnover

Framework impacts (How Would it Change SAFe)

  • Within individual teams only, no changes to roles or artifacts
  • No other impacts outside of the team

Benefits (What’s in it for You?)

  • Train everyone at the same time (learning transfer, cross functional training)
  • Getting all the minds and the wisdom of the crowd looking at the problem simultaneously – higher quality
  • Brings the team together to work together closely and collaboratively (team cohesion)

If you are one of those radicals who happen believe that SAFe needs to change. If you believe that large scale agile needs to evolve in order for the promise of agility to pay off. If you believe that we can incorporate the latest innovations in the agile world into organizations adopting these frameworks, then please come join me as we explore just how we can do that together.

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. ‪https://bit.ly/2HXCcKD ‬

More SAFe Mix-ins

February 9, 2019

Based on the popularity of the first post on SAFe Mix-ins, here are a few more ideas for practices that you could mix and match with your SAFe implementation:

  • No Coaching – Train the managers and leave them in charge of the transformation
  • Sociocracy – introduce Sociocracy
  • No Prep PI Planning – Do a quick half day of training and then go straight into the PI Planning event
  • Agile Chartering – Integrate concepts from Diana Larsen and Ainslie Nies book, Lift Off!
  • Disciplined Agile Development – are there more document centric practices that might apply, especially in highly regulated industries?
  • Lean Budgeting – can we incorporate concepts from Lean budgeting or beyond budgeting?
  • Agile HR – Can we bring HR into the big picture in a meaningful way?

As you can see, there really are no limits to the elements that we can use to enhance or refine our SAFe rollouts. I want to thank all the folks who attended this session at Agile Open Northwest this year. Their ideas were amazing!