SAFe Mix-in’s: Dynamic Re-Teaming

April 7, 2019

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

Overview

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

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

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

Challenges

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

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

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

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

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

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

Forces

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

Framework Impacts

  • Teams must persist through full PI

Benefits

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

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


Let Your Freak Flag Fly

March 4, 2019

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

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

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

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

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

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

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


Make it Yours

March 2, 2019

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

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

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

association
band
bunch
club
coterie
crew
crowd
crush
faction
folks
gang
group
house
insiders
kinfolks
mob
moiety
organization
outfit
ring
sect
set
society
sodality
stock
tribe

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

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


Pernicious Escalation

February 21, 2019

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

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

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

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

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


Painting The Spots

February 16, 2019

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

  • Courage
  • Focus
  • Respect
  • Committment
  • Openness

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

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

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

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

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

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

This is What I Do

I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.

To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com


Maxims and Manifestos

February 13, 2019

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

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

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

He had a bunch of maxims: 

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

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

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

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

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

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

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

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


We Need a Map

February 12, 2017

map

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

-Steven Wright

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

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

Around and around they went.

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

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

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

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

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

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