Another modification to SAFe that we might make is role by election. Role by election is turning some of the role selection process on its head. for example, as in dynamic re-teaming, we’re going to allow the teams to make more decisions themselves, we’re going to allocate more power to the team and less to the management. In this particular case, this goes back to the way that value streams, release trains, and solutions are created. Again, the typical way this is done, is these groups are appointed by management or key stakeholders. Selection by management implicitly takes power away from teams and also tends to employ those who are most respected by management, but perhaps not those most respected by the teams.
To fix this, when we’re creating value streams, release trains, or solutions we need to let the teams pick their own leadership. They get to pick who the release train engineer is or the solution leaders. They pick the architect and the product manager as well. Now this could be as simple as getting these groups together and asking them to elect these people by popular vote. You might have product owners elect the product manager. You might have the development teams elect the architect and the release train engineer. It would be quite simple. Basically, you are switching from leadership by appointment to leadership by election.
In its simplest form, this really is the kind of thing that you could do when you are initially rolling out SAFe. Or you could do it over time, perhaps iteratively. For example, I know that being a release train engineer is a lot of work. And it’s not something that I necessarily see as a career path for the rest of my life. If I get elected for the job for one PI for example, I might be happy to contribute and help out, but I might not want to do it forever. So, we might hold another election at the next PI. And each PI you would elect someone new for each of the roles. That way we also can get away from treating some of these roles like job descriptions (which often happens) and keep them as temporary roles that we fill as needed with people who have the right energy and the right support to make it happen. And doing this with some sort of democratic process seems to be a reasonable way of doing. It
Of course, this means as managers we have to give up some control over who is leading, and that could have some HR implications too. It’s a hard thing to ask for, but there is so much to be to be gained:
People elected to these positions will have the approbation of their peers, and feel supported by them, having been elected to these positions rather than having been appointed or pushed into these positions.
The teams will feel happier that they have had a voice. So, it empowers the teams, and they’re going to be working with or lead by somebody most capable of leading them, which also makes a great deal of sense
It is an opportunity that can be shared by re-electing on a periodic basis so that others can get experience in this role. This leads to creating more opportunities for leadership within the organization for everyone.
So it’s win, win, win.
You want the highest possible engagement and buy-in for your transformation
Management is willing to let go of the responsibility of role selection
None really, SAFe doesn’t dictate how roles are selected or changed
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.
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.
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.
Teams seem lackluster, not engaged
The management team is open to creative new options (and can tolerate giving up some control)
Teams must persist through full PI
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.
I’d like to talk a little bit about SAFe mix-ins. SAFe mix-ins are innovative practices in the agile community that we can incorporate into popular frameworks like SAFe, LeSS, or DaD (to name just a few). To me these mix-ins represent an opportunity for us to improve the performance of our teams within existing large scale frameworks, and that ultimately serve to enhance and provide benefit to us and our customers.
So, with that in mind, the first mix-in that I would like to address is mob programming. Now, if you haven’t heard of mob programming, it’s relatively new. It’s been around in the agile community, at least as far as I can remember for about the last four or five years or so. Its original proponent is a guy by the name of Woody Zuill. Woody probably describes it best, so here are a few references to mob programming and how it works.
In two sentences or less, mob programming is basically getting the entire team working together in a structured fashion to work on a single problem at a time. This is usually done in a team workspace in front of a big screen. It has a variety of intriguing benefits:
Helping to train everyone at the same time.
Getting all the minds and the wisdom of the crowd looking at the problem simultaneously.
Generally bringing the team together to work together closely and collaboratively. Working in, dare I say it, an agile fashion.
There are also some rules to mob programming, but not many:
There is one and only one driver. The driver is responsible for doing all the typing. They own the keyboard.
Everyone else is a navigator. The navigators are giving the driver directions and keeping an eye on where you are headed next.
Roles are swapped frequently. Being the driver is exhausting, so we swap out the driver role every 10 minutes or so. Everyone gets a chance to drive.
With these sorts of benefits, mob programming is the kind of activity that I would describe as a technical practice akin to pair programming. As such, it really represents no disruption to incorporate it into any of the existing frameworks. It’s relatively easy for us to incorporate it into SAFe. For example, if one team on your release train decides to adopt mob programming, great! It’s no problem, it doesn’t impact anyone else on any of the other teams. Furthermore, if you were to adopt it across all of your teams on a release train, you might find that they all might accrue the benefits of mob programming – without affecting any other release trains. All of this works out to our benefit.
So, with all of these things in mind, adding something like mob programming to a framework like SAFe seems like a fairly pragmatic and useful idea. Certainly, at its worst it’s harmless – it doesn’t hurt us in any way, shape, or form. And at its best, it helps us to improve the performance of the teams. Furthermore, it has no side effects or impacts to any of the existing practices, artifacts, roles or structures in the process that is SAFe. So, from that perspective it’s really quite useful.
Now, there’s probably one other thought that some may have which is, “Hey, if it’s so useful Tom, why don’t we put it into SAFe and formalize it?” I’m not sure that’s really necessary or frankly a good idea. After all, SAFe is espoused as a framework and as such should probably be kept as minimalist as possible (I know there are some who would laugh out loud at that last statement). I don’t believe that we should take every single technical practice that we happen to stumble across and stuff it into our definition of a framework.
The other thing that I like about the practice of mob programming is that it is so low impact that it doesn’t represent the kind of change that might seem to be challenging for some of your more conservative organizations. This is the kind of mix-in you can add relatively easily to an organization that might otherwise find more substantial types of change very challenging to adopt. In this particular case, mob programming is easy to slip in and try out. It’s low risk and has no noticeable effect outside of the team (unless, of course, it’s advertised). These sorts of mix-ins are probably the best-case scenario for starting to introduce subtle change and subtle evolution into frameworks like SAFe, LeSS, DaD, Nexus and others.
I guess there is one other question that we should ask ourselves anytime that we try to change our process: What problem are we solving? Let’s think about that question in terms of mob programming. How long does it take to add new people to the team and get them up to speed and contributing at the same level as everyone else? Do you have silos of specialization, where there are only one or two people who understand a component or subdomain? Are people able to easily switch roles on your team when someone is missing? If these are the types of problems you face, then perhaps mob programming would be useful. You could certainly easily measure improvement relatively easily.
I’ll also offer this thought: When you take a step back and take a look at the PI Planning process, it’s not a whole lot unlike elements of mob programming. It’s inclusive, everyone in the release train is asked to join and participate. Each team has its time in the sun where they share their plans with the other teams. And it’s an intense period of learning for everyone involved. You could think of it as mob planning. So, this mobbing concept might be useful in other domains outside of programming too.
Forces (What Would Lead You to Do This)
The organization is resistance to change at the program level and above
Work encounters bottlenecks within the team
Team is struggling to bring team members up to speed quickly
Team composition may be changing frequently due to growth or turnover
Framework impacts (How Would it Change SAFe)
Within individual teams only, no changes to roles or artifacts
No other impacts outside of the team
Benefits (What’s in it for You?)
Train everyone at the same time (learning transfer, cross functional training)
Getting all the minds and the wisdom of the crowd looking at the problem simultaneously – higher quality
Brings the team together to work together closely and collaboratively (team cohesion)
If you are one of those radicals who happen believe that SAFe needs to change. If you believe that large scale agile needs to evolve in order for the promise of agility to pay off. If you believe that we can incorporate the latest innovations in the agile world into organizations adopting these frameworks, then please come join me as we explore just how we can do that together.
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.
Well Sherman, Any time I explain what Scrum or XP is, I start with time boxes. The time box method has been around a really long time. The earliest record I can find in a casual search is where they were used at DuPont in the 1980s. I suspect that time boxes are much older than that. The time box basically applies a constraint to the system. It creates an arbitrary start and end date, usually on the smaller side. You commit to a fixed amount of work and when the end of the time box is reached you are done, no matter what the completion state of the work. Work that is complete is counted as done within the time box, work that still remains to be finished is either scope that gets dropped or perhaps that work is continued in the next time box.
This technique has some benefits:
Deadlines, even arbitrary 2 week time boxes, help keep everyone focused.
Deadlines force the question of prioritization. Not everything will fit in the box.
Small time boxes create a short heartbeat or pulse that is useful for measures of capacity and throughput.
It forms a useful skeleton for the OODA improvement cycle
There are also some challenges:
Small time boxes demand that you figure out how to break work down into smaller, but still valuable pieces. Many teams find this hard to do.
Small time boxes means that it is almost inevitable that scope won’t be delivered sooner or later. How the business manages this scenario says a lot about how the benefits of time boxes are perceived.
Much of the angst of estimation is due primarily to the fact that teams are struggling to fit work to their limited capacity in ways they didn’t have to prior to the time box.
It doesn’t work if you can’t break the iron triangle of scope, schedule, and quality. Scope usually has to be compromised in some form or another in order for time boxes to work (it’s kind of what they are based on)
Like so many other things, a time box is useful in the right context, but not all contexts. I’ve seen a few projects where a time box would not work (hardware constraints, legacy mainframe applications, an organization that wasn’t willing to give up the iron triangle, etc.). All too often we force the time box on the team and tell them that they suck if they can’t overcome the challenges. Sometimes that’s true, other times it isn’t. It’s a judgement call. Beware, and don’t let yourself get caught forcing a round peg into a square hole (I’m looking at you Scrum).
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.
If you do a little reading about Scrum one of the first things that you learn are the 5 basic values of Scrum:
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