084: Bruce Eckfeldt - Retrospectives — Looking Back at Our Progress

Are you thinking about how to grow your business with near and offshore staffing, but you're also wanting to make sure that it's reliable, cost effective and really well done. I think docsa talent is the way to go. Here's why. They don't just fill your jobs. They bring integrity, top talent, and a people first approach that's hard to find. I've known the people at Doxa talent for over 20 years now and I say that you can count on them. I have. Talk to docs of talent and you won't be disappointed. Go to docsatant.com Bill G Again, that's doxatalent.com Bill G One more time. Doxatalent.com Bill G Check it out.

Today we just don't take enough time.

To stop, look back, assess our progress.

And look at the real facts and real things. We're always reacting and too much just in the moment and there's not enough thinking then. And so we often find ourselves making some of the same mistakes again and again. A thoughtful retrospective review will make a real difference in the quality of your plans for the coming period or the period ahead. That's what today's show is all about. It's really about an approach to the review of the recent past that helps you to find and learn more from the past so you don't have to keep repeating and making the same mistakes all over again. Find the things that are working well and take advantage of those and work. So all of our sessions involve a look back. Every time we finish a quarter or finish a year, we take time to stop and assess our progress, to see what worked and what didn't work and what there is to learn from it. We do a variety of exercises. Today's show is on a special version of that called the Retrospective and we have a terrific coach and experienced entrepreneur, Bruce Eckfeld, who's going to share with us all about that. Stay tuned. Keep listening.

Hello and welcome again to the Scaling Up Business Podcast. I'm your host, Gazelle's Business Business growth coach, Bill Gallagher. On the show with me today is Bruce Eckfeld. So Bruce and I first met through the business organization. He's another one of these coaches now who's had a long history with the Scaling Up Rock Habits framework, first encountering it through the EO organization, right?

Yeah, yeah. Way back when.

And Bruce on the east coast and I don't know, Bruce.

I think we.

See each other more over drinks and stuff at either the summit or one of the events or one of the conferences that we end up with.

You're probably right.

Bruce is on today to talk to us about retrospectives, which you'll hear, especially if you're familiar with our work, if you are working with a coach now, if you're one of our clients, you'll hear it sounds familiar to some of the work that we do annually and quarterly to review and assess, except there's a certain rigor to it and a slightly different emphasis than maybe we do now. And I think it's useful to hear how Bruce approaches it. So I'm really glad to have you on the show, Bruce.

Yeah, it's great to be here, Bill. Thanks. Thanks for having me.

Well, I'm in the sunny west coast today, where actually it's beginning to get overcast, but it was beautiful earlier and sun is setting where you are in the east coast.

So we're at the end of the day.

Yeah. All right, so let's get into it. So before you. Let's talk a little bit. I think it's always sort of. It adds not only credibility but relatability for people to kind of hear, how do you get into the world? Where did you become an entrepreneur? How did you become a coach? How did retrospectives come into your life? Tell us the background.

Sure. Well, so way back when I was an architect and I got into software development, late 90s, really on the design side. So we were looking at user experience, design, product strategy, how to use digital technology to advance businesses. Now I got more technical and got into the lean agile movement back in early 2000s, when the extreme programming and scrum was all kind of coming to fruition in the software world. And really, retrospectives was one of the key things that really drew me into the whole lean agile movement, because for me, it was really about how do we basically, how do we get better about what we do? I think I've been on numerous projects back in the early days where we spent weeks and months and sometimes even years on developing things and then putting them into market and realized they really didn't work. So this whole idea of a retrospective, whole idea of continuous improvement was something that really drew me to the lean agile space. And really what started my company back in 2003 was really to focus on how to use lean software development to create better product. On the design and strategy side, architects.

And engineers of all kinds, I think, come into the world of business solving a problem. Architects maybe do it with a little more flair than the engineers, but we all come in, like, looking to solve a particular problem to address, to build something, right? Yeah, yeah, yeah.

I think they think of it as puzzle solving. It's all, you know, how do I deal with a set of constraints, a set of variables, and put them together? In a way, I configure it in a way that's actually going to meet the requirements or meet the success criteria that we're working towards.

So I know we're going to share some examples, but why don't you give us a kind of a working definition of retrospective? What do we mean by that?

So retrospective is really, I like to say, is the process of looking at the past to improve the future. And the goal here is to really use the things we've done, the results we've generated, as data that we can develop insights around. And we can use those insights to develop ideas about what we might want to change and from that, decide what we're actually going to implement and the key things that I find about the process. So when I actually sit down and kind of explain the process to people, the first thing is we really want to create a safe environment. So we talk about making sure that we're setting a context, setting a meeting space where people can actually talk about the things that have happened. Because sometimes those things are not been good things, sometimes they've been failures, sometimes they've been mistakes, sometimes they've been major mistakes. But we still need to get that on the table if we're going to learn from it and prevent them from happening in the future. So we need to create that space, then we need to collect the data. So we're always starting with the raw data. We don't want to make inference yet, we want to look at what really happened. Sometimes we have to dig a little bit to figure out what that really was to the raw data that we have. But also we need to make sure we collect all of it. So people's memories have big gaps in it, people's recollections about what happened or what their focus was. And so we're collecting a lot of data in the beginning. From that we can actually develop inference. So figuring out based on that data, what do I see, what can I observe, what kind of patterns, correlations, inferences can I make? And then from that I can look at possibilities. And we want to have a nice divergent process around. Anything's possible. I like to use called a rule of peanut butter. If someone says peanut butter, we write it down. There's nothing bad, nothing wrong to be said. And then we want to converge, then we really Want to focus on? Okay, out of all these things, what really is going to move the needle? What is really going to help us improve? And then what are we going to commit to? And then it goes to the who, what, when, what commitments and what actions are we really going to take and when are we going to do them by?

So now you're all the way into planning already. Why don't we give us a couple of examples? So first of all, why don't you start with an example of something that didn't go well. Share with us somebody who either failed at the retrospective or failed to learn from something.

Yeah, I would say that the one great example I have about a failure, and it was really a failure process, was this whole idea of not creating a safe environment. And it has to do with. It was a big project we did for major fashion brand. We did a big store in New York. It was a multimillion dollar build out of a technology and retail space system, very cutting edge. And it was using a lot of RFID chip technology. So we had spent basically months building a set of readers, building a set of software systems behind those readers. And it wasn't until we put them in place we realized that the interference between the various technology was causing reading errors in the process. And we had spent several weeks trying to diagnose it. And we realized that in the meetings that we had previously, some of the people actually knew this was a problem. So that the sub team that was working on the shielding for the different components knew that they were having interference problems, but they were afraid of the blame that they were going to get by bringing this up early in the process. And so they tried to fix it on their own. And it ended up delaying the project probably about six weeks. It was several hundred thousand dollars probably of delay that we ended up. But it was, that whole thing is when we were meeting and when we were having our reviews, there wasn't enough safety in the process to actually get the data on the table that we needed to have so we could all actually address it. And if we, you know, if we knew what the problem was and we knew that we were having this interference, we probably could have figured out some other ways of addressing it sooner rather than later. Even though it was a problem, we could have probably solved it a lot quicker. So I think that's, it's things like that typically that I find fail. The retrospective process is when you don't have the safe environment and when you're not collecting the right data because you end up making Kind of false, false assumptions or preemptive assumptions and solutions that really don't solve the root kind of problem that's causing the scenario that you're in.

So different coaches have different ways of saying this. You'll hear a lot in our world, people. No blame, no shame. There's a morality that affects us all and a desire to be good, not bad, or at least to look good, not bad, and a pressure to not be the one who screwed up. And so we've all heard the term cya, right? Cover your ass and you hear that. And we know fundamentally it makes no difference, right, that all of that spin and all that just hides it might deal with the personal impact, right? The shame, the discomfort, but it doesn't really help solve the problem. If anything, it slows it.

So there are two things that we do to really address this whole idea of safety, creating a safe space. So the first thing is something I call the Prime Directive. And it was developed by this guy named Norm Kurth back in. I think it was the 70s or so. And it really. It's a phrase that really sets up the context of the meeting. And we literally read this before each retrospective because we know that without reading it, without being cognizant of it, we are naturally not going to do it. So we start our meetings this way. And the. This is the way the Prime Directive reads. Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. And so we acknowledge that in the beginning to basically say, look, we know people are going to screw up, and we know that people make mistakes. That's okay. Or at least we're going to still talk about it. And we're not going to bring blame into this. The other thing I do is make sure that the senior team is modeling this behavior. And. And it's actually not so much that the senior team admits their mistakes, because it's kind of easy for a senior person to say, oh, you know, I screwed something up. Let me show you how I made a mistake. What the modeling that I really try to encourage is that a senior team member calls out another senior team member on the mistake they made and brings it to the table as an opportunity for learning. And when other people see senior people calling out other senior people and mistakes and using that as learning opportunity, that's the modeling that will actually get this retrospective process going.

Totally get that. Totally can see that that makes a difference. So Admitting your own mistake is one level, and then the next one is creating that environment where you can call out somebody and they can look together at it.

Yeah, exactly. And that is the essence of the retrospective. Because oftentimes you don't see the data or you don't see the inference from the data. I'll be looking at a set of data and like, like not seeing the bigger idea and someone else can look at that. But if I can't get that on the table and I can't be okay with other people doing that to me, then I'm not going to get to that level of insight.

I think that's probably a good thing for people to know in general. If you call up your coach, your advisor, whomever you're working with, and you're like, yeah, things are going pretty good. Yeah, well, I'm working on this, but, you know, I'll get there. You're not using the coach, you're not using that person anyway to make any difference on it. But if you call them up and I had somebody, it stands out because of the way she did it, but CFO for a company, and she called me up, she's like. We started off the call, she's like, yeah, things are going pretty good, actually. No, they're not. I'm going to be honest. And she caught herself in that common political, like, friendly lie that we all do. Yeah, I'm pretty good. You know, could be better. Like, it almost becomes a weather check. Right. And instead she's like, no, I'm struggling. Let me tell you what's going on. Right then I'm like, okay, that was the moment she decided to use her coach as her coach. And that was the moment our relationship shifted and something shifted for the whole company.

Yeah.

So give us a good example of where you've introduced retrospective. For a company that worked really well. It had a huge payoff. Paint a picture of that. Right?

Yeah. So typically what happens is we're running retrospectives usually every quarter, sometimes every month, depending on kind of the pace that we're running at. We had a case recently where it was kind of a technology focused company and they were looking at deploying a new product. And we were reviewing what happened the last month. They had a series of two releases over the month. They were releasing every two weeks, and we were going through a major kind of rollback issue. So they, they released a product. They realized the database didn't. Wasn't set up the way it was supposed to be set up. They ended up taking almost Two days to kind of get the product back to where it was. They had to go to a secondary server for a while. In the retrospective that we were having with the leadership team, they were, they were talking through the problem, they were putting this data on the table. And someone in finance actually recognized that that date had to do with a purchase of a new software license. And by lining up the dates of the new software license purchase and when this rollout was happening, they realized that there was a new update to one of their packages that happened to coincide with that license renewal. They didn't know it was going to be automatic. But by, by lining up this data and seeing that where the root cause of this thing was, they're actually able to figure out what happened and actually prevent. And they actually kind of caught a couple other things that might happen in the same way to be able to make sure that that wasn't going to happen in the future scenarios. And so for me, it was really, it was seeing the two different departments that normally wouldn't really talk together. It was the CTO and the CFO that were in this, seeing how that data, seeing that the. We do it as a timeline, so we'll put up a month on the board, and we do it by day and by week. It wasn't until they kind of connected the dots on that data till they realized that really was the root cause of that analysis. And they had spent a good couple of hours trying to diagnose what this problem was.

Somebody in a different department, one department's looking at stuff, another department sees it looking together and says, oh, that's probably this. Yeah, yeah, right, yeah.

And that's usually what brings up in the retrofectum. And one of the purposes of it is to connect the dots between domains, between areas that normally would not see those connections.

You know, it's interesting in working with human beings one on one, like executive coaching kinds of work, and in peer groups, the blind spot reveal is the big thing, right? And we've seen, all of us, some version of this, in a funnier sense out in the world. You're in line at the post office, the dmv, the bank somewhere, right? And you see a person who's like, really worked on their whole look, but the back of their head is messy, or there's a piece of toilet paper on their shoe, or, you know, like there's something that everybody else can see except you. And for whatever reason, right? You just like, you can't see it, but then once you see it, you can't unsee it, it's revealed, right? And then your actions are altered and naturally start to figure out how to address the whole thing. And a lot of times people will be like, ah, God, you get so smart. Like, my coach is really smart. I'm not that much smarter. I'm a lot dumber than some of the people I work, I think.

Right. Well, yeah, that's probably why you're smarter because you don't have that preconceived notion.

That, well, more than that, I'm just not in their day to day. I'm not. I like, you know, we come in, we see them for a minute and we like. And what they can't see stands out like crazy. Like, dude, that person is on the edge of a break. Like, help, you need to help.

I like to say, I think as coaches we can see things you can't see and we can say things you can't say. Really is kind of our primary purpose is to bring that stuff up and get the conversation going in the right direction.

It's awkward and often it has to do with the CEO or the owner. Okay, so what are the parts?

So breakdown.

What are the key elements of retrospective?

Yeah, so anytime I'm going to start, think about that, creating the safety. So whatever I need to do to make sure that I've got a create space. So that's step one, step two, think about that data. Like what do I need to do to get data on the table? Sometimes it's a timeline, sometimes it's, you know, I have people go through calendars, through email, like whatever you need to kind of recall what happened. And I think that's, that's the key thing, is it? Sometimes it comes in waves. Like I'll say you're going to get a whole bunch of stuff in the beginning and you're going to, I put stickies on the wall or put notes on a spreadsheet, whatever tool you're going to use, and then wait, give it a couple of minutes and sit there with that data and you'll start to trigger things. Things will start to come back in waves. And then you key off other people's information. So as you see other people recalling things, that may trigger something for you. So once I have data, then I'm going to move into insights. What are my inferences? What do I observe? Typically I'm looking for patterns, connections. Do I see a correlation between something, an inverse correlation? Do I see a gap? Maybe I'm missing something that really should be there. What happened there is There something there that we didn't really investigate from those insights. From that inferences, I can then develop ideas like, well, what do we want to do? Well, maybe we should really change the way we're doing our coaching meetings. Or maybe we should move this meeting from Mondays to Fridays because that would free us up for this thing. Or maybe we should organize this in a different way. We come up with ideas and this is the anything goes, no bad idea, get it all out. And then I want to really filter because the idea is I need to be able to implement these things. I have limited time and resources. I need to choose which ideas coming out of my retrospective do I really want to implement. So once I have all the ideas on the table, I prioritize and then I commit. So those final step is saying, what are we going to do to implement this? And this goes on the action list. These are things that we're literally saying, who's doing it, what are they doing it by? And what exactly is definition of done? So how do we make sure that we know what success looks like with teams? One of the things we'll actually do is actually chart the number of ideas coming out of each retrospective. And that will become. So we'll say, how many ideas are we generating? How many small, medium, large, how many of them get implemented? What's our success rate? How many of them fail to get implemented? Well, actually retrospect the retrospective, not to get too meta on it, but we'll say, well, I'm a big believer in developing learning organizations and this is one of the key tools that I find learning organizations can use to just get better, whether they're trying to improve or trying to scale or trying to transform form. This is one of these key tools.

So it seems like this lends itself especially well to singular focus areas like a particular initiative or project to do a retrospective and gather data and that it might be a little more challenging to do it with a broader scope. Like the whole business.

Yes. And I've had a lot of success of doing it with leadership teams where we'll retrospect on the previous quarter priorities and we'll actually go through and figure out, okay, well, what worked, what didn't. And sometimes, I mean, I've had things come up in retrospectives where like the weather comes up as part of something that happened. We're like, yeah, it was really, you know, everyone had a hard time getting in this week. It really caused problems with continuity or we missed a bunch of meetings. Well, what do we want to do? Is There a better way to handle this? Is there a better protocol for being able to deal with weather situations? I've actually had terrorist attacks come up on my retrospectives where the World Trade center goes down. Well, what do we do? Or outages go out and what do we do? Actually thinking through how do these things impact us, do we want to make changes, do we want to actually have fundamental process considerations about how we deal with this kind of stuff in the future or not? Hopefully these things are limited, limited events.

I have weather come up every quarter with one of my teams because they're a travel and tourism related business. Weather has a significant impact on their business on a very regular basis. And, and I can think of others where it's really about how or when it occurs. Like in their case, it's does the weather, the adverse weather occur on the weekend or not? If the weather happens midweek, no big deal. If the weather happens Friday to Sunday, big impact, right?

Yeah, I had one. We figured out that weather was impacting the consumption of soup. We actually figured out the delay and how it was the prediction of weather that oftentimes impacted the soup orders over the actual weather itself. So it was an interesting kind of analysis. I would say that the thing with this, if you really get into retrospectives, it's separating out the data from the inference. I think a lot of people end up kind of doing these project reviews and postmortems and stuff and they stay in this kind of inference like what do we want to change? And I think by really taking the time and going back and capturing the raw data before you jump to the conclusions or jump to the inferences, is where some of these bigger insights and these aha moments will occur. And a team that gets really good at that, whether it's a leadership team or a division or a project team, is where that kind of muscle can get built in organizations.

So as coaches, I think most of us do some variation of this. We share the wins, the bright spot, the successes. Right. Personally reported by all the individuals and often summarized by the CEO. Then we'll share relevant metrics, personally reported summarized by the CEO. We'll share the progress on initiatives and priority rocks for the quarter of the year. Happened, didn't happen. And we'll throw all those up and then we ask people for key learnings and we're looking for, not what we're looking for, all learning. And then we're trying to net out the biggest learnings across the organization, but we aren't looking together at the raw data. We're throwing at all these points. So the good things, the bad things, the metrics and the actual status of the major initiatives, and then we're asking people to throw up what they think the learning is. Right?

Yes. It's that data. Like I've seen people put the same thing in very different quadrants. If we do, oftentimes we'll do a board, we'll make a wall, we'll have the beginning and the end of the time period and then we'll rank things, things that happen and we'll score them, things that were good and things that were not so good. And people will put the same thing both high and low. And it's in that difference of seeing that same thing both as a high point and a low point is where the, where the insight is generated. Because now I can start talking about that.

So you're saying it's fine to put it both high and low because it generates a conversation. Correct.

It's an individual's perspective of how that event, how that data point impacted them or how they.

Well, an adverse event overcome often creates a hotel. Right. You think about like your lukewarm customers are the ones that have uneventful experiences. You have a few people who are happy at the other end who had something that was great, but the people often who are most passionate are the ones who had something negative that you recover well from.

Yeah, well, emotions are relative.

Yeah, awesome. So. So the key difference is more data shared and looked at together than draw things out rather than. Yeah, I get that. I get that. That's the biggest. So how long do you allow for if you're going to do this monthly, quarterly, annually, how long would you allow for this kind of work? The preparation, etc.

So generally I. My rule of thumb is one hour of retrospecting for every one week of work. So if we're going to do it weekly, we do one an hour. If we do, you know, if we're doing two week iterations, we'll do two hours, you know, once a month, we'll do at least half a day, you know, for a quarter, we'll often do a full day retrospective. Like, well, if this is a big. If it's a big initiative, we'll do a full quarter, a full day of retrospecting on the quarter. You know, it depends on the team. It depends on how well the muscles developed and how sort of how much fodder we have to work through. But that's my general, kind of general rule of thumb for, as I hear.

It right off the bat, I think, wow, getting somebody to spend a full day of retrospective on a quarter's work sounds like a challenge unless I break it into pieces, like, do this before we arrive and we'll do this together and like that.

Yeah. And I usually, I mean, the idea is by the end of that, by the end of that day or by the end of that process, we have our key areas of focus going forward. So I'll feed that into the quarterly planning process. You know, it's a good way to kind of work, work through the last period of time and get to a point of kind of clarity and closure and key set of priorities and key set of areas of focus for going forward and action items. I mean, people are usually coming out of that with, okay, I'm going to do X, I'm going to do Y to fix these things.

Here's a key complaint I hear from folks when I'm working with them is.

Oh, when are we going to get.

To talk about the plan? We're not spending enough time talking about the plan for the coming year, the coming quarter. Right. We're doing all these exercises like, yeah, this is the reflection. This is where we look back and we see. So we don't just keep doing the same stupid stuff again and again.

Yeah, you can quote einstein. I spent 55 minutes figuring out what the question is before I try to answer it. I just find that the better we understand really what happened and really where things went right and went wrong, that next part becomes so much easier. It's just so clear around, okay, yeah, we really need to do this next. And then it falls into place much faster.

I think that's the thing we don't notice is like, like, why do I need to do start, stop, continue. I know what I need to do this next quarter. Let's just plan that. I'm like, yeah, but if you stop to look at. You had great intentions last quarter too, and not everything worked. If you stop now and reflect then all the different things where we assess that and we do our red, green, yellows, and we call whatever system you use for doing that kind of thing, you update yourself swot, you do a start, stop, continue. You run your team through the Rock Habits checklist. You look at how the sales went up and down and how your production, your margins, what your cash position, you look at all these things then as you go and plan then the quarter, the year ahead, or even the next couple of weeks, all that's there present, fresh in the background. It informs your Decision making. You can draw a very rigorous line and, and sometimes I'll do it where I'll have say, okay, before you create your suggestions for the priorities for the next period, go walk around the room. Review the stuff that we've just spent the last day or half day or whatever doing. Look around it, think about that before you just launch right into it. It's in the background already. And I would say that's probably one of the ones that people are most. No, I could just do it from here. No, yeah, that's fresh for me. Right, like, no, actually go walk around. Look at that. Like, all right, look at your swot. Connect the strengths to the opportunities. That's where the insights come from. Right.

I would agree. I think that it helps validate those initial ideas with data. So we actually have data on the walls that says, okay, yes, this really is a priority. The other thing I would say it's a, a bit of, of a process. And by getting the team to go through that, it gets everyone behind that priority. It gets everyone committed to that. I think it's just you get better kind of adhesion to the final set of priorities that you end up coming out with when you've done that. And actually that group, that team has walked through that process together and comes out the other side in agreement with those things as opposed to just saying, okay, I think this is it, okay. And then trying to rally support or rally consensus around it.

Well, I think you've probably given folks a lot to think about. So we want to start with data. We want to create a safe space to look at the data together. So we've got to remove that idea of shame and blame from it. Creating permission for it both through personal example and the way we interact with each other. We want to get that whole data together. We want to then develop the insights and ideas from looking at and reviewing the data. And then we can begin to make suggestions about initiatives for the coming period and where we want to focus. And fundamentally then we can align and commit to plans of action that would take us further. I want to just let people know that if they'd like to get further information about retrospectives, then go to ekfelt.com retrospectives and you've got video information there on that. And then if you'd like an overview of the scaling up framework and the whole approach and I've made reference to our planning sessions, that kind of thing. We've got an agenda and instructions how to lead your own planning sessions with your team along with worksheets and tools to get that started@scalingupbusiness.com and you can also subscribe there and then get podcasts like this every week sent right to you in summary form. So we'll have notes. We'll put the link of course to.com retrospectives right in the notes as well so folks can go and find it after the show and get information about Bruce's work and this particular approach to it. So go check out Bruce's website and go to scalingupbusiness.com and get our growth guide there for information on how to follow up. Thanks again for being on the show, Bruce.

Thanks Bill. It's a pleasure.

Well, I hope you can use this show to tune up and bring more rigor to your retrospective review of recent performance and results. I really want to thank Bruce Eckfeld for coming on and sharing his approach with us and hopefully we can use it to all raise our game in the area. I particularly found myself using and thinking right away of people that I wanted to share that Prime Directive with. If you come from a Star Trek background or other fandom, you'll recognize that terminology. Of course they mean a different thing for it here, but I think it's really useful in in creating the right environment. I want to thank our show producer Nio Bade. Audio production by Podfly Productions Our show is edited by Albert Burge and our show notes are written by Ain Kodina and proofreading is done by Tim McGowan. If you got some value from our.

Show today, please share it with someone.

Else and let us know what you loved. Thanks for listening and keep scaling up.

Are you ready to turn your goals into daily wins? You should check out our Scoreboard software. Powered by Align, it's the official software for scaling up. With Scoreboard, you'll get an AI driven coach for priorities and KPIs and it'll help keep your team focused on what matters most. With Align, you can track your goals in real time and you'll even see results on the go. With their mobile app you can rest easy knowing the Align has world class onboarding and support to set your team up for success. This is really more than just software, it's what I actually use to manage growth in our scaling up client teams unlock clarity and results with Scoreboard by aligned. To try it now go to aligntoday.com Bill G One more time aligntoday.com Bill G that's aligntoday.com Bill G Check it out and try it now.