Building Up and Tearing Down

May 27, 2019

Recently I put on a public Leading SAFe training. This wasn’t your typical training, however. In collaboration with Ron Quartel, we tacked on an extra day to discuss FAST Agile. Now if SAFe is an example of a scaling framework, FAST Agile is perhaps a good example of what you might call a de-scaling framework. FAST uses an open space style of organization to provide only the most bare bones structure and guidance. It’s really quite elegant in its simplicity. 

Ron and I had both been inspired by the ideas of mix-ins – processes and practices that we can mix and match together. So, it was with that in mind that we thought putting on a combined training class would be interesting. First teach SAFe, then turn around and teach a competing framework. Then compare and contrast. Well, as it turns out, the combination was quite brilliant.

As I taught the two days of Leading SAFe training, the class built up the framework from teams, to programs, to solutions, to portfolios. Learning the roles and processes of each. By the end of the second day, I was exhausted but happy (as usual). Then Ron stepped in and proceeded to teach FAST Agile on day 3. In essence, he took everything I had taught them and tore it all down. The focus was on simplicity and self-organization. The class was totally into it – questions flew fast and furious. Everyone was fully engaged. 

The contrast between the two frameworks was stark, and it raised many questions for both Ron and I. You see, I wasn’t there to sell anyone on SAFe. Don’t get me wrong, I like the framework, and I enjoy the training a lot, but I don’t give a damn whether or not you decide to adopt it. What I really care about is that you make an informed decision based on what I hope is the deepest possible understanding of the options. If you understand the values, principles and practices deeply, then you will choose to implement what is best for you and your organization. There is a tremendous amount of nuance and subtlety to the art of organizational change (that’s probably why I like it so much), so I believe that the ability to not only adopt ideas, but also to be critical of them is important. 

The act of building up the framework and subsequently tearing it down again felt like a very powerful learning experience. It went beyond rote learning. Not only do we ask, “Why would you adopt this?” We also ask, “Why wouldn’t you adopt this?” That requires us to understand the ideas from different perspectives. People stayed after class each day debating the ideas for over an hour each evening. That’s when you know you’ve really got them thinking. I’m looking forward to doing it again.


Why Mixins?

May 8, 2019

“Some say that I should settle down, go slower and not push so hard, so quickly for such transformational change. To them, I say that you misunderstand the size of the problems we face, the strength of the status quo and the urgency of the people’s desire for change.”

– Eliot Spitzer

The Challenge

According to the latest VersionOne State of Agile survey 2018, the most prevalent scaled agile framework in use today is SAFe. Note that I didn’t say it was the most popular framework. I’m not sure that most people love SAFe, but I can say that most people use it. Why don’t people love it? Well, I’m sure there are lots of good reasons:

  • The framework is very prescriptive, often specifying “best practices” without much discussion of alternatives
  • The framework is overly dense, incorporating nearly every agile practice ever invented
  • The framework is designed as a first step for large organizations on their agile journey, but often it is also the last step
  • Implementations tend to be cookie cutter and not make allowance or provide guidance for change

I’m sure there are many more very good critiques of SAFe. It’s not my purpose to condemn the framework, but rather to highlight some weaknesses that I believe can be easily addressed. My goal is to consider how we can make SAFe, and frankly, many other scaling frameworks, better.

So how can we accomplish that? What can we do to improve this very full, relatively rigid, and somewhat context-free framework? My answer is fairly simple: swap in practices and processes that complement the framework and may provide a better “fit” for our transformation customers. Essentially, I’m arguing for the application of a little creativity. All of the frameworks have a planning process. But there are a lot of ways to do planning. We can vary the estimation practices like story points, WSJF, or #noestimates. We can vary how we prepare for the planning event by using extensive top down review, bottom up conversation, or LeanUX related practices.

The truth is, that we have a whole constellation of different practices that we can swap out within our scaling frameworks depending on the need. This gives us incredible flexibility to help our customers find the “right fit” for where they are at in the moment. This has some important consequences:

  • For engagements that begin with a very prescriptive bent (which often makes sense when teams are learning something new, think shu-ha-ri), using mixins is a great way to begin down the path of experimentation and continuous improvement
  • We even have the discretion, once we have learned how the framework works, to try our hand at de-scaling – that is, to remove processes that seem too heavyweight
  • Mixins give us the creative potential to continue to evolve our scaling frameworks far beyond what their creators may have originally envisioned
  • Using mixins during a transformation rollout can help us to avoid the cookie cutter implementation phenomenon

All of the practices that I propose as mixins are novel and innovative. Most have proven their value on their own in the agile community. It is the recombination of these ideas with Scaled Agile Frameworks like SAFe that I find so interesting. It feels like something very new. It’s an exciting challenge, are you up for it?


Different Roots, Same Tree

May 1, 2019

Recently, at conferences, in social media, and even informal gatherings, I’ve heard statements along the lines of “[X] scaling approach is absolutely not agile for [Y] reason.” I use the word approach to avoid the question of whether we are talking about a framework or a methodology. I really don’t care about that distinction and much of the subtlety that lies there is beyond me.

Admittedly, there is a long and rich history of critiquing each others ideas in the agile community. Some examples include:

  1. XP vs Scrum
  2. Kanban vs Scrum
  3. Lean vs Agile

To my knowledge, none of these debates has ever really reached any sort of meaningful conclusion. In fact, the more I watch (and even sometimes participate in) these debates, the more I feel like they are mostly a reflection of a sort of core philosophy. What I mean, is that there seem to be some common starting points or assumptions that characterize how people approach these debates.

Let me give you an example. Let’s take SenseMaking and the Cynefin framework. We can use a tool like Cynefin to help us navigate important decisions based on the assessment of contextual complexity. The beauty of this system is that you can use it anywhere. It doesn’t matter whether you are agile or not. Cynefin is simply used to help assess and navigate the environment of simple, complicated, complex and the chaotic. What decisions you make within each context will lead you to healthy outcomes. With Cynefin, you can start with absolutely no framework or required processes at all. In essence, you are building from scratch, and evolving only as necessary. Frankly it’s a beautiful and elegant system. Conceptually, it’s founded on the notion of sensing your environment and making decisions based on what you uncover. It’s a radically empirical process that starts wherever you may be. There is no default starting point for applying Cynefin. You simply use it to help you grow from wherever you are.

The interesting thing is that Cynefin isn’t the only framework that uses this “start wherever they are” approach. Kanban is also very minimalist in its rules. In fact, Kanban usually starts by simply making the existing process visible. You don’t need to change your process at all, just make it so that everyone can see it. Starting from there, the Kanban approach recommends that we consider applying WIP limits and working to understand the constraints of the flow through the system. There are no pre-defined required processes. You don’t have to do standup. You don’t have to hold retrospectives. You basically start Kanban from scratch and add those elements wherever they make the most sense. You build your agile process from scratch based on the feedback you get from making the process visible. Again, it’s a very elegant and powerful system, that’s founded on the notion of visibility (or transparency) and allows you to evolve however makes sense for your environment.

So I see both Cynefin and Kanban as sharing some important conceptual roots (while each is very unique). Both methods provide us feedback to help make good decisions in whatever context we may be working. Both also make absolutely no assumptions about what the starting point may be. You could start with a very rigid, waterfall style, process. Alternatively, you could be using Scrum. Neither Cynefin, nor Kanban care about where you start. In fact, what they really care about is not blindly applying process without some sort of feedback. So I think of Cynefin and Kanban as the “build it from scratch” or “consider context first” methods. Actually, I really like to think of these as the Buckaroo Banzai methods, you know, “Wherever you go…there you are.”

Now this also implies that you are really committed to this learning journey, with all of its joys, discovery, false starts and dead ends. Building your process from the ground up is not for the tentative or the faint of heart. Why do we have to go through all of this learning pain and discovery, when others seem to have found some practices that seem to work? Well, the argument, and it is a very valid one, is that you need to discover what works for you in your context. Trying to apply solutions that may have worked well in other places often leads to disappointment. In the Toyota way, Toichi Ohno warns us of exactly this. If you want to build a world class process, you can’t rent it. You need to build it and find out what works for you.

But what if we really could rent our process? Wouldn’t that save a lot of time and wasted effort? Let’s face it, this is business, not rocket surgery. We can’t all be so unique that we have to waste time rediscovering the wheel. Let’s take a look at another very large branch on the agile tree: approaches based on starting with a predefined set of practices or processes like Scrum, or XP.

Scrum is based on a very fundamental set of practices that creates the infrastructure (or framework or method) for continuous delivery and improvement of small units of work. Depending on who you ask, XP and scrum came into being around the same time. As I remember it, XP was the first to really land hard on a required set of practices that defined the process as truly being XP. These twelve practices were non-negotiable. You had to do them, and if you didn’t, well, then you weren’t doing XP. You’re probably familiar with many of these practices. They are foundational practices like pair programming, continuous integration, test driven development, and so on. Part of the reason for requiring these practices was that they supported each other. It’s hard to do continuous integration without some form of test driven development. The two together are kind of a magical combination – they help reinforce each other. Often, what we see happen in the real world, is that teams will struggle with and perhaps drop practices. When that happens, keeping the other XP practices working gets harder.

Scrum does something similar, but different. Scrum has a default set of non-technical practices that are required. You must have sprint planning, daily stand-ups, and sprint retrospectives. That’s non-negotiable. To do otherwise is to do “Scrum, but…” and to be mocked mercilessly by your peers. Both scrum and XP could be loosely described as having a default set of “best practices” that are required in order to use the framework to its best advantage. Now I personally hate the term “best practice” but that’s exactly what they are doing. We’ve identified the best, minimal, set of practices that you must use as a starting point, no matter what your context is. It’s a package deal and we defer to the wisdom in the package. Unlike Cynefin or Kanban, you have a very well defined starting point, and you aren’t given the option to do differently. Now, both XP and scrum are based on empirical process control (at least in theory) and they both claim that you can evolve and change the framework as you learn to use it. However, in practice, I’ve rarely seen it actually happen (Spotify being one very notable example). When you start with a predefined set of practices, it seems harder to evolve to anything else. Well, I guess Darwin never said evolution was easy.

So we have two very different schools of thought about how to think about approaching agile:

  1. Start “where you are” and use a decision making model or visibility model to evolve to where you need to be (Cynefin, Kanban).
  2. Start with a fixed “starter set” of best practices and then evolve to where you need to be (Scrum, XP).

I think that these two philosophies or approaches explain a lot of the conflict I see in the agile community today. The “start where you are” folks seem to feel very strongly that “starter set” approaches run the risk of being applied in a cookie cutter fashion and often incorrectly. To them these approaches are likely to lead to poor outcomes and are therefore to be avoided or even wrong headed.

On the other hand, the folks who take the “starter set” approach” are appalled by the waste involved in the “start where you are” engagements. Why in the world would you waste your customers precious time and energy on rediscovering the wheel when you already have a very capable set of practices to start with? It’s folly! These practices are tried and tested and there are very few exceptions. To ask the customer to invent their process on their own is just a high risk recipe for disaster! Therefore, to do anything other than the “starter set” approach is to be avoided or…well, you get the picture.

I think the argument only gets amplified when we start to include scaling frameworks in the conversation. As I look more and more closely at the scaling frameworks, I start to think that I see their roots in each of these different approaches. For example, SAFe has its roots firmly in the “starter set” camp. SAFe is most definitely a framework of prescribed “best practices” that are intended to be applied universally. There is some allowance made for the size and scale of the organization, but the gist is that everyone does SAFe. On the other hand, there is LeSS which seems to share its roots much more closely with the “start where you are” approaches used by Cynefin and Kanban. In LeSS there is more emphasis on using tools like systems diagrams and root cause analysis to discover the right means to change the system for scaling. So LeSS feels to me like it leans a bit more toward the “start where you are at” approaches.

Of course, the adherents of each approach think the others are nuts. I think some of that is due to how each sees the world. They are coming from very different starting points. I’m not sure they’re ever going to agree with each other. Fortunately, I’ve seen both approaches work well for people. And I’ve also seen them both fail miserably. Often it had little to do with the frameworks, and a lot to do with the people. So I guess we count ourselves lucky and try to remain calm when they point quivering fingers at each other and proclaim loudly that the other is “Not Agile”.

Of course they aren’t.

That’s OK.


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

Overview

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.

Forces

  • 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

Benefits

  • 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: Radical Co-Location

April 18, 2019

Overview

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.

Forces

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

Framework Impacts

  • None

Benefits

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


SAFe Mix-in’s: The Core Protocols

April 17, 2019

Overview

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.  

Forces

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

Framework Impacts

  • None

Benefits

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