Peter: Welcome to the Humanizing Work Show. Today Richard and I are talking about team resets. Richard, you wrote in a recent newsletter a few weeks ago about teams needing some sort of a reset because they're not functioning as well as they could. And I thought it would be interesting to dig deeper into how teams get in that state of needing a reset.
What are the signs, how you can recognize if your team is there and some of the things that we've seen make a difference in those types of resets.
Richard: Sounds good.
I think probably the biggest cause for a team needing a reset is, maybe unexpectedly, not things going wrong in a big way. It's not a failed release or, people just being really upset about something.
A lot of times it's just inertia and entropy. Over time new people get added to a team. Some people leave and you realize after a year or two, two thirds of my team wasn't around when we had our initial kickoff, where we figured out why we exist as a team and what our agreements are and how we wanna work.
They've just picked up our language and mental models and agreements secondhand, maybe third hand. From somebody who joined in the middle and kind of playing telephone while we're busy. And you usually notice that retros don't get you back to those points of alignment anymore. They just do small tweaks and at that point you may see we've just come a long way since the last time we aligned and kicked off how we want to work.
It can make sense to do some kind of reset event at that point to get realigned and move forward with more energy in the same direction.
Peter: So entropy can be one cause of it. It is the second law of thermodynamics, after all. I guess we should expect it to apply to teams as well. What are some other causes that you think, contribute to that need to reset.
Richard: Another one that we've seen is what we used to call the death march kind of project. I've often been called in to help a team that is demoralized after a long slog of over time and fixing defects and things like that. And in that case it's actually downstream of a broken way of working.
Usually putting off complex things until the end of an initiative instead of front loading for complexity. We've been talking about our caped approach quite a bit recently, and Caped is a way to systematically bring forward that complexity and resolve the hard stuff early so you get this sense of momentum.
We're getting faster and faster, more and more predictable, but I've worked with a lot of teams over the years that didn't take that approach. They started with the more predictable things. They moved towards the unknown, unpredictable things, and then got in this mode where they had a deadline they had to deliver by.
There just wasn't time to do the work Well. In the time that was left, they ended up working overtime. They ended up cutting corners. By the time they got to the end, they're just worn out and exhausted. And in that case, the reset functions more as a way to get back to what do we care about? What matters in our work?
How do we want to be with the next thing that we start off? And so in those cases it, it may be more about rethinking, like what can we learn to avoid getting in that situation again, and how do we wanna approach the next thing that we're working on?
Peter: That death march is certainly something that I experienced a lot.
We didn't quite get to the death march stage on our, on our team at Adobe, but we called it the end game and it was hard. There were teams around us that might call it a death march. But our team was fairly good at doing iterative development even before we learned about the agile stuff and Scrum. We did still call it the end game when we adopted Scrum.
It got way better because our bug count was just low all the time. Then we got to what we called a Feature Complete date at Adobe, and it was usually six months before a release, and then you spent the next six months fixing bugs, finishing up the documentation, marketing, back in those days, integrating into the suite installer, testing the installer.
All all of those other parts that we had put off to the end, and especially the bug fixing part of that, testing, and bug fixing, was a hundred percent delaying complexity to the end. We assumed that, well, we got the features mostly done. I'm sure we'll find a few bugs at the end and fix 'em, but we'll fix 'em.
What really happened is that we didn't have time to fix all of the defects, Speaking collectively here as the company, deferred fixing a lot of 'em until a future release. Sometimes we would get around to fixing 'em, often they just stayed deferred. So that was a big quality issue for us. So we're, we were right there with you.
And I think deferring complexity of "does this thing actually work? Does it actually integrate? Can we do it without defects?" All of that was complex and we just deferred it to the end. Scrum really fixed that for us on our team.
Richard: How about other teams there who'd been through a painful end game? Did you ever have the opportunity to do a sort of reset after one of those, and if so, how did you approach it?
Peter: When we shared our data about what it looked like when we were using Scrum, that was the thing that caused Scrum to spread at Adobe. When people looked at our bug counts, when I told the story of getting to that feature complete date and saying, I don't know what we're gonna do for the next six months. I guess we'll start working on the next release early, and they were all working, 80 hour weeks.
That was pretty convincing for them to say. "Tell us more about this scrum thing that you've been using." And so I did get to help a lot of those teams. At that time, the answer was, can we try Scrum? That's really how I helped them, was taught them how to use an agile approach. And that did make a big difference for a lot of teams.
I have. Back from those days, I had a bunch of graphs where our team had that reduction of bug count. Then the next team that I trained was After Effects. They experienced a similar reduction. Then Premier Pro, then after, or then Photoshop and just team after team as they, they experienced the same thing, and it led to less chaos at the end of those cycles.
So back in those days it was, we'll adapt an agile approach and this will fix it for you. So that's how we helped them reset, was we trained them how to do agile.
Richard: Right. That points to a general pattern in how we often like to do a reset for a team, which is you don't just get together and talk about yourselves and how you wanna work and kinda the typical lessons learned postmortem sort of thing.
We found it works a whole lot better if you introduce some sort of outside idea or set of ideas and then you look at what you experienced through that new idea that brings some fresh energy and, and focus in there. So that might be, let's introduce Conne if a group's not really familiar with it, and talk about what is that complex versus complicated distinction reveal about what we experienced on this last project and why it was so hard at the end, and what do we wanna do about that next time?
Or in your case, let's introduce Scrum and how might things have gone differently if we had this? What does this tell us about how we wanna work together? So introducing a new concept in some way, and then using that as a lens to look at your experience and look at how things might be in the future can be a really great way to go from, whether it's the inertia or, something genuinely painful to a new start.
Peter: And lest our listeners misunderstand, I don't think it's just any new idea. It's like, "let's try this book I just read about something!" It, it really is. The reason that Cynefin works, the reason that Agile frequently worked, is that it got to a root cause of why things were broken. And I do think it's important that you have some evidence that the new thing you're gonna introduce addresses some level of root cause of those things, rather than, "well, this is the trendy thing. Let's, let's do this. I can think of a lot of examples of that that didn't help teams. Like when, for example, Growth Mindset. When Carol Dweck wrote her book on growth mindset, everybody said, let's adopt a growth mindset on our team. And that didn't really shift anything because it wasn't a thing that's A) easy to shift, b) like what would you actually do differently? Cynefin, Scrum, these cause you to do things differently. They change behavior, and they give you patterns of behavior. So probably whatever you adopt as a reset framework, or shared language, or mental model, probably needs to change behavior in a way that you can hypothesize at least, "I think that will address a root cause of why things were not working in the past."
Richard: Right. Yeah. The other thing that we've seen useful when it comes to introducing outside ideas, it's, it's not always introducing, it's more like going back to. Like we, we've just been doing our own thing with Scrum for the last three years. Let's go back and look at how is Scrum defined. Not to say we need to do it perfectly according to the Scrum guide, but let's set aside how we've adapted and go back to the original and see is there anything in there that teaches us something like if we did it this other way versus the way we've.
Drifted into or experimented into what might be different. So it doesn't always have to be a new idea. Sometimes it can be going back to something you haven't looked at for a while, and a lot of times what you discover when you do that is, oh yeah, I forgot about that.
Peter: I had this experience. Had this experience a couple of weeks ago where I was teaching, ostensibly teaching a team about Agile, a large group, actually about 35 people. And several of them had had training before and sort of knew how the Agile stuff works. Many of those teams had been using Scrum for multiple years. And this happens almost all the time when we do training these days, because somebody in that class has, has been doing agile, often a lot of 'em have been been doing some kind of set of agile practices.
But I had this senior developer come up to me on a break and he said. This has been great. I, I got certified five years ago and I've been using this stuff for three years and it's really helpful to remember what I'm actually supposed to be doing and how this stuff is actually supposed to work.
Not, not because he felt they were doing something terrible, but just that reset to say, "oh, yeah, that's why we do this meeting. Oh, yeah, we're supposed to do this." And particularly for him, it was vertical slicing. He said, yeah, we've really gotten away from vertical slicing. When we started talking about that, I realized, ah, we've drifted from that.
That was a root cause for them of why things had drifted. So that'd be another set of patterns is how do you, how do you split work vertically?
Richard: Mm-hmm. I think that dynamic is more important than ever now, because you have so many teams that are using the language of Agile or Scrum or whatever, maybe never even really trained on it, but we've got this tool that calls things stories.
So now we talk about our work as stories. With maybe no connection to even what user stories are and where they came from and that vertical slicing idea. And so you can think you're doing a lot of these things just because we're, we're using the words. We have these meetings. We have a tool that calls things, stories or epics or whatever.
And getting back to how are those things originally defined? How are, how are they used by teams that have good results with them? No implied obligation that we need to do it just like that. But use that as a lens to look at your experience and see maybe we're missing something. Maybe we didn't adapt to make things work better in our environment.
Maybe we just had entropy cause us to drift into some practice that was low friction, but maybe low effectiveness as well. There's,
Peter: there's a pattern here that I see happen not just with Agile, but with anything like that. OKRs, I see this all the time with a lot of patterns like this, which is some organization experimented their way into a practice that works well for them at that time.
And then they write about it, and other people say, wow, that's really cool. I think that would work for us too. And they adopt it and it works for them. And eventually what you have is like the book, somebody read the book about that thing, they go tell their team about it. The team says, oh, I think we can do that.
And it's like a tree that grew up, took this specific shape, and then lightning hits the tree. It still has that shape. But the tree is dead. Like the roots aren't, there's nothing, there's nothing alive about that tree anymore. And somebody sees that tree and says, that's what we should look like. But there's nothing inside.
They, they adopt the outer shell of it. There's no living heart to it anymore. And that, I think that can happen to all of us, is that we say, "oh, it worked for them. It must work for us. Lemme get at least the shape of it right, and it'll probably work." But doing that, without understanding why it works, and recognizing that it was an experiment that worked in a context for an organization, we should adopt it experimentally as well and see what works for us, is a pattern we see a lot.
Richard: Someone might say, we we're doing retrospectives. It's already built into our work. How would you know if a retrospective is enough or if you need some larger intervention to reset and reenergize your team?
Peter: I just got back from a road trip, as you know. Our family drove from Arizona up all the way up to Colorado to visit my sister.
Then we took the scenic route home through the Lawrence homestead there in western Colorado. Got to hang out on the farm a little bit and then drove back. And I was thinking about this as we drove, which is, road trips are fun, but things can go wrong on road trips. Luckily, this was a pretty uneventful one as far as the road trip part of it went. Some, some other things with the adventures around the road trips, but, nothing catastrophic, luckily.
But on that road trip I was thinking, I have been on road trips where the car started malfunctioning. I remember in the old times we somehow, we used to pack mom and dad and six kids into a 1978 Ford Bronco that had two bench seats.
Richard: It's a clown car!
Peter: And I remember my, yeah, my dad built, built a, a platform that went in what we called the way back. Which was behind the second bench, and he would put the suitcases under it, couch cushions on top of it, and two of us would get to sit in the way back. And that was the good place.
And I remember in that 78 Ford Bronco once driving through Northern Arizona up into Page, and there's this big climb as you approach Page, which is right on the border, right by Lake Powell. And it was hot. It was in the summer. We must have been driving up to Utah or Idaho, where we had family, from California. It was hot and that 78 Ford Bronco had a problem called vapor locking, where the carburetor stops working correctly. And what happens is it feels like you're pushing the gas and it feels like you're driving and you just start losing power and losing power and losing power. Normally that's fine, unless you're on a really steep hill. Well, in Page, approaching Page, we were in a really steep hill. I think that's one way that things can go wrong in a car.
Another way is that, on that Bronco, the 78 Bronco. On that Bronco, one time my wife and I, newlyweds, we were driving it, in a beautiful mountain trail, there was a bunch of switchbacks, called Four Peaks just outside of the Phoenix area.
And as we started going around these switchbacks, all of a sudden the steering just completely locked up on me. It got harder and harder to turn. And by the end of it, I really couldn't turn it. I could make the wheel turn about two inches, and so I would do these like 20 point turns to turn around, get down the next switchback, get down the next switchback. Turns out the steering gear had gone out on me and locked up. So steering can get hard.
And then the third thing that can go wrong on on a road trip, and this is probably more common for anybody that's been with their family, is that the vibes can get bad in the car, right? People aren't getting along. We can't agree on what music to listen to, what game we're playing, whatever the game we're playing on in the road trip. People don't agree on the rules, right? You can start arguing. There's a bit of that to be expected, but it should be in the sense of we're having fun together. Sometimes that can get toxic and everybody just stops talking.
Okay. Long story. I think there are three categories of things that go wrong on a team that we could relate to that analogy. The first one is the engine stops working as well as it should, right? You're not producing, you're not going as fast as you used to, and you're not sure why. You've tried it in retrospectives and it's not getting better.
So if your production is slowing down, it just feels like, like that Bronco trying to climb that last hill into Page, and it's just not gonna make it? I think that's a time, that's a signal that the retro's not working.
The other one is if it's getting harder and harder to steer, like you're not getting feedback from customers anymore. You're not sure that what you're building is the right thing. You have a backlog, but it seems like you're just reacting to the latest emergency rather than building something intentionally, strategically. That would be kind of like the steering.
And then the last one is if you're not, you're not talking as a team, you're not gelling as a team anymore. The, the little arguments have built up over time and you haven't resolved them. You haven't fixed and addressed the conflicts, the interpersonal conflicts.
I think we could summarize those as if production is slowing down, if direction is getting harder, or if connection is dropping and retrospectives aren't fixing that, it's time to do something bigger.
Richard: We'd love to hear from you. How have you noticed that a team needs some kind of reset and retros aren't doing the job? And what have you tried and how did it work? And if you'd like help in designing a reset event, or even having us facilitate something for your team so that you can come back with new energy and increase your productivity, improve your direction, be more connected and effective as a team. Reach out to us. Visit the
[email protected] and let's have a conversation and see how we can help you.
Peter: And thanks for tuning in to this episode of the Humanizing Work Show. We'll see you next time.
