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

SAFe Mix-in’s: Sociocracy

April 16, 2019

Overview

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.

Forces

  • 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

Benefits

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


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

Overview

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.

Forces

  • 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

Benefits

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

SAFe Mix-in’s: No Prep PI Planning

April 11, 2019

Overview

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.

Forces

  • 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

Benefits

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

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.


SAFe Mix-in’s: #NoCoaching

April 9, 2019

Here’s a weird one: Today’s SAFe mix-in is called #NoCoaching (yes, I totally made that up, but hear me out). So one of the things that you’ll see when you encounter any sort of decently large scale agile transformation is that typically there is more work that one coach can do. So often times you will have a senior coach that will play a coordinating role, there will be program level coaches that will be responsible for doing things like launching large programs or value streams/solutions, and there will be people who operate best at the team level acting as team coaches. So as you might imagine, on a significantly large engagement that can end up being a lot of coaches.

Overview

What we often find is that the conventional process of doing a transformation using SAFe or many other frameworks seems to involve dozens of coaches to get the job done. Now that’s if you’re doing it the conventional way. When the transformation is over, and believe me, when you are paying for that many coaches you want the transformation to be over as quickly as you can (because it’s hideously expensive to be paying for all of these coaches). So once that initial coaching is completed, they kick you out pretty quickly, because it’s terribly expensive to have you around. So what this leads to is a bout of intense training and coaching followed by a complete absence of any coaching or training. You launch your release trains and then you kick your coaches out and you’re off and running with SAFe (or whatever framework floats your boat). Eventually things start to suck as the transformation “high” tapers off. This often leads to a syndrome of re-launching the agile transformation over and over. Each time, hiring a different group of coaches.

Well, that model has some obvious problems. Namely that most of the knowledge about agility has just left the building (oops). And everyone is now wandering about struggling to understand what all those crazy coaches were thinking. Often times things just fall back into their old patterns.

There is an alternative to this approach. The idea is that if we step back for a second and think about what we are trying to accomplish in a transformation, what we really want is for people within the organization to own the transformation, be responsible for the transformation, and ideally, to execute the transformation. Why? Because it’s their company, it’s their business, it’s their domain, so they’re the ones that really need to adopt and internalize this stuff. Throwing in a bunch of proxies or a bunch of coaches does not serve to make that happen, or if it does, it’s kind of a poor secondary effect.

What I propose with #NoCoaching is that rather than throwing an army of coaches into an organization, that we only coach the middle management and key stakeholders. That means that everyone has to be coached by the managers and stakeholders that they work with. So basically, you transfer the ownership of the transformation from the coaches to the middle managers and stakeholders. It will work better that way, at least in theory, because those are the people who are going to carry the transformation forward. Those people won’t go away. Those people are the ones best suited to figure out how things will work best within their context. So the key is giving them some good training and then being there to give them advice over time on a much smaller scale. But you’re not coaching every single team, you’re not coaching every single product owner, you’re asking the organization to take that role.

Challenges

I can think of a lot of reasons this might not work. First, managers are busy people, and they aren’t necessarily the best trainers. In fact that’s probably an understatement. There are organizations that are full of busy managers who couldn’t possibly find the time to engage like this. So this approach probably won’t work for managers in organizations like this. In fact, it’s hard to see how any kind of meaningful agile transformation could work where managers just can’t afford the time to be bothered. Just sayin’. So I have to believe that this will be most effective in organizations that value the manager’s active participation in training. I know they’re out there. There’s also the issue of responsibility. If managers own the responsibility for the transformation then they can’t blame it on the consultants. That’s a common mode of operation for many companies: hire consultants to take responsibility for the transformation, then blame them when it fails. Agile probably isn’t going to fly there anyhow.

Forces

  • Repeated attempts at transformation
  • The management team is willing to be the trainers and own the transformation

Framework Impacts

  • None

Benefits

  • Lower cost
  • Higher engagement
  • Longer term sustainability of the transformation
  • The agility is “internalized” – you own it

So the bottom line is that #NoCoaching isn’t for everyone. When you look at it closely, you might even conclude that it’s not really an absence of coaching as much as it is a different way of approaching the coaching process. There’s still a coach hiding in there (right there, behind the curtain), but they are only coaching the managers and key stakeholders. You don’t see them coaching the teams at all. That’s the responsibility of the managers. I’m probably a voice in the wilderness on this idea, but I believe there is a better way than using an army of coaches and trainers to milk the customer of every billable hour we can. We can do better.