SAFe Mix-in’s: Dynamic Re-Teaming
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:
Dynamic Reteaming, by Heidi Helfand
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.
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
