
Sign up to save your podcasts
Or


We had the pleasure of speaking with Liz Llewellyn-Maxwell of Planview where she serves as a Senior Manager of content marketing. Liz has a deep background in Agile Marketing, including being on a team that started doing Agile Marketing, stopped, and started doing it again.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
We speak again with Richard Delahaye, Vice President of Marketing at Barracuda MSP. We last talked with him in late 2015 and this time we discuss about how he is building an Agile culture.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
Tenzin Alexander, Senior Vice President and Marketing Operations Director at Huntington Bank join us on the podcast. She heads marketing operation for Huntington Bank, including tools, processes and compliance and shares how they are leveraging Agile Marketing at scale.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
Today, we will be talking about how Agile marketing drives customer centricity with Ty Hayes. Ty is the Managing Director at the consultancy Growth Generators and formerly the CMO at Curtin University, where he transformed a 70 person marketing team to an Agile way of working.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
Joining us is Paul Acito, retired Chief Marketing Officer of 3M, who moderated a discussion about Agile Marketing with Joe Ferry, former Senior Director, Digital Marketing at Ceribell, Rob Smith, former Digital Commerce Director at 3M and Chief Digital Officer at Fractional Digital and Terry Peterson, Marketing Technologies Director at 3M.com.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
Elizabeth Stepp, Senior Vice President at Truist, talks with us about her personal Agile journey. She also shares the Agile Marketing transformation process at Truist, a commercial and consumer bank with locations in the southeast US.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
In this episode we talk with Elizabeth Venter. She is an Agile Transformation Lead at Agile Sherpas and an experienced Agile coach. Previously she worked as an Agile Transformation Consultant in various industries including financial services and automotive.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
Joining us is Brandi Starr. She is the COO of Tegrita, a full-service marketing technology consulting firm, host of the Revenue Rehab Podcast and someone who is passionate about helping people and teams succeed. She shares how they are leveraging Agile in their work and with clients.
Transcript
Jim Ewel
Brandy, can you share with us what motivated you to adopt?
Brandi Starr
Our marketing team was fairly new and we were getting things done but it felt like everything was taking forever. We tended not really hit many deadlines and so I started looking at different approaches to try to improve efficiency and move things through and so that’s where I stumbled across agile marketing in my research and the fact that we are a technology company, very familiar with agile on the technology side and so we chose to dive right in and take on agile.
Frank Days
What does agile look like at your firm?
Brandi Starr
A little different than at most companies. We are a consulting firm and so there are two parts of agile for us. We primarily use agile within our internal marketing team and so within marketing, we have our monthly planning.
Our sprints are a month which is long by comparison to most organizations but we do our monthly planning. We have our monthly retros. We have not used the whip limits.
We tried and we found that that just didn’t really work for us. However, we are planning with story points and looking at how much we’re able to move through in a given sprint. Then on the client side, we are using what I call agile light because our clients all work very differently within their organizations.
We can’t go full agile but we have adopted using a Kanban with our clients for planning the work that we’re going to be doing, having monthly planning meetings and then we have an internal retro on how we’ve managed the client and the work that we’ve done and how we continue to improve and so far that’s going pretty
Jim Ewel
one of the things I’m really interested in when people adopt agile is how they organize the teams. Are you organized in the cross-functional teams or how to do approach?
Brandi Starr
super small. Our marketing team is three people. I had operations and marketing and then I have two marketing managers and then we have several people on the team who support marketing.
One of our client strategists and two or three of our technologists also support the marketing function. For all intents and purposes, it is a cross-functional team and we are all using agile. We’re making sure that we’re publishing the plan for the sprint and that everyone’s signing off on it. We have our standups which are mainly with the smaller team. It’s quasi-cross
Frank Days
As you’re using agile with your clients, you talked a little bit about Kanban. Can you elaborate a little bit more about the interactions and processes and how that compares with what you use for your internal non-client
Brandi Starr
With our clients, our contract structures can vary. For some clients, we are working on very specific projects. They will contract with us to do a specific body of work.
Those clients, we aren’t using an agile process. For our larger clients, where we are involved in the day-to-day, so in many cases, they are outsourcing their email or marketing ops to us. We are involved in defining the strategy and all the initiatives that are happening in marketing will have our hands in.
The plan is a bit more loose. With our Kanbans, we keep it simple. We use smart sheets.
We have it set up with the card view. We have our backlog. Anything that comes up as a potential project goes into the backlog.
Then when we are doing planning, we are looking at, okay, here’s what we said. We were going to work on this month. This still makes sense. What do we need to grab from the backlog, anything we need to add to the backlog? Because clients are working on contracts where we’ve planned out their hours for the month of the quarter and we have estimates on each of the cards, we can determine if we’re putting too much into work in progress. Is it the right balance? And so that part works really.
And it’s actually created a lot more accountability and insight for our clients where a lot of them are not quite as organized. They kind of are just working on what they work on. They’ll have ideas and then those ideas get forgotten along the way.
And so that has been the most helpful part of agile. And then also so that we are continuing to improve the way that we work with our clients, the fact that our internal team does a retro and we essentially bring anyone who’s worked on the account to the retro to talk about how did it go? How do we improve?
We do the start, stop, continue. And that’s also helped us to improve how we manage our
Jim Ewel
Brandi, you talked about some of the parts that have helped you. What have been some of the challenges that you’ve encountered as you’ve adopted?
Brandi Starr
so initially the sprint duration was a challenge. We were trying to go with weekly sprints, which is what’s the most common. And it just, we just don’t move that fast.
And so we quickly abandoned that. And then also having whip limits on the internal side. Because most of the people that are supporting marketing, so other than my two marketing managers, all pull double duty.
So I do some of the consulting work, I own operations, I own marketing. Our strategists are primarily client-facing, but support marketing. It was really, really difficult to actually assess bandwidth.
There may be one month where I lean in and I’m doing 30 or 40 hours of marketing work. And then there’s some months where they’re kind of on their own and I only do 10 hours. And so you can’t really define an actual whip limit because it changes day to day. And so that was the other piece that really did not work
Then also with clients, daily standups trying to meet more frequently than weekly. Also didn’t work like we couldn’t other than one client where the volume is high enough that daily makes sense. Our other clients we’ve shifted to like a weekly standup process because it just didn’t work for schedules, didn’t work for budgets. And so we had to abandon that part as
Frank Days
You talked about WIP limits. So we had a recent guest on the podcast who’s talking about work in progress and the challenges that it introduces to the team by having too much work in progress. I’ll freely admit that when I’ve practiced agile with my various teams work in progress has always been too much WIP is always been the killer.
Everyone is whether it’s pressure from above or it’s over ambition or whether it’s underestimating the value. Can you share what your process looks like around managing your WIP limits?
Brandi Starr
So what we’ve started tracking is days. So define is our first stage when it comes out of the backlog and so we’re looking at how long it sits there before someone actually starts working on it. So we’ve been tracking that I think for eight or nine months or so as well as our percentage of work that’s getting completed on time.
So based on the dates that we set we always are focused on clearing the board because the goal is that at the end of the month, everything is done and the middle of the combo board is empty. And so tracking those two numbers as well as how many story points were able to put through month over month has really helped us to see what is realistic for our team. So even though we’ve not been able to set like an actual work-in-progress limit to say like if we’ve got too
much in this stage, then nothing else can move there. What it has done is it has helped us to not be overambitious and to actually really be realistic. And so when we see that okay, our percent on time is going down and our day.
is and define is going up. Yeah. We probably put too much that sprint.
Much better. And so that’s been kind of our approach to creating balance. And I was able to build some excitement around Clear the Board. So far, we’ve only had one month where we’ve actually cleared the whole board. That’s great. And it happened. I made a big deal of it. Like, we posted in Slack. I sent virtual confetti gifts, all sorts of things.
Get a big deal. And so that has also really helped everyone involve to be more conscious of what they can actually do. Because nobody wants to be the reason that we don’t clear the
Frank Days
I was just wondering about the little sibling of WIP, which is the unplanned work. The stuff that comes up in the middle of the sprint, do you have a process on how you triage things as a month is a pretty long sprint? There must be tasks that come up in the middle of the sprint people have. It is someone being ruthless about, OK, this one comes in. That one goes out kind
Brandi Starr
We are fortunate that we don’t have a high volume.
There are times when it peaks something happens, especially things in the national crisis or things that people are paying attention to. Sometimes you have to stop work or take things out of market or things like that. But for the most part, we do pretty good at planning ahead and not having a lot of last-minute stuff.
However, when there is, we do in our marketing daily standup, we have that gut check of, can we really get this done without putting something else on hold? Or do we need to put something on hold? And so it is really quick.
And I try to not make it a whole discussion. Like, it really is a gut. if we can get this done or not.
And I’ve gotten my team comfortable with being able to say no. If we do this, something’s got to give. And so that’s why I say I wouldn’t say it’s ruthless because if there is something that really has to get done and we can’t put something on hold, we do make it happen. And we do occasionally stretch ourselves then. But for the most part, we do pretty
Jim Ewel
Brandi, I’m curious if you have applied some of the iterative aspects of agile to your practice. What I mean by that is oftentimes we kind of work in a waterfall method. We get a creative brief in, we do the campaign, we declare victory.
We said the campaign’s over, right? And the essence of Agile is iterative to try to do a little something and see how it works and then iterate on it. Have you applied that aspect of agile to your practice with your
Brandi Starr
So we’ve been able to take that iterative approach in a couple of small ways. With our clients, I have started to really get them to think about what’s the MVP? Like what do we need to actually get done to get something in market or to get this project complete? And how do we iterate on it
Because we do, I do see probably more on the client side where projects will kind of just drag on and on and on because there’s this desire to be perfect. And instead, I try to shift them to “done is better than perfect”. Like how do we get to good enough?
And that works on certain things and with certain clients. So I do at least try to preach the iterative mindset where I can so that we don’t get stuck in those cycles of revisions and all of those things. On our team side, I think we actually do a little better in just being comfortable in certain places with the process of iterating.
Because we’re consultants, there is a little bit of a different expectation of we can’t put anything in the market that’s half done because it reflects poorly on our brand and it impacts our business. Our digital ads are a great example. We’ve found that LinkedIn has been most successful for us.
But our social ads aren’t quite yielding the revenue that we’d like. So we’re going through an iterative process. Like we had our phase one, we put it in market, we’re looking at what’s working, what’s in there. not and we’re as we’re going into January, our fiscal starts in November. So we’re now going through our second iteration of that and keeping what’s working, trashing what doesn’t. So we have an iterative process very much at the forefront of our minds. But I wouldn’t say that we’ve nailed it. Like it is still, there are still a lot of things that I do think stay in progress that maybe could have been done earlier in the month.
So earlier in the sprint, that comes down to the last day because we’re trying to make it perfect. So there’s room for growth there, but we are at least, we are at least being iterative.
great to hear. It hoists as a challenge for all of , do all that stuff completely do this iterative approach. I mean, I know I find that very challenging. So can
how you work with your clients in terms of like you said some of your clients, your smaller clients, it’s, it sounds like it’s fairly waterfall, right? You have a statement of work and you deliver against it, right? That probably makes sense. Given the size of the project, you can, you can actually define it. You probably have a pretty decent amount of certainty around scope and scale of the project. As they get bigger, what does it look like? Are these bigger clients that they just on retainer and
then, and so the way that we work is we will plan their hours by the year, but broken down into quarters. So okay for simple math, let’s say they’re buying a thousand hours from us, and they know that there’s a ton of work that happens in Q1, but Q4 is kind of coasting. So we may say that Q1, we are planning for 400 hours and Q4, we’re only planning for 100 hours and then in Q2 and 3, it’s going to be 250 each.
And so based on how their business flows, what they have in their annual plans, we will estimate just at a really high level where the hours should live in the year. And for some clients, there’s a little more detail there like some clients like to have specific projects in their statement of work that they believe that they’re going to work on for those larger clients, it really is just hours. And so we start off planning that in the annual retainer.
So that’s what’s in the statement of work. And then from there is where we have our con bond at the beginning of the year, we start to throw everything in the backlog that we know that we might work on, even where it is just a nice to have or some of those some of those cleanup type things that you only really do when you’ve got some extra time, we get all of that in the backlog and then we start to plan against what their planned hours are. So , what do
need to and then we also break it down so that it’s not whole projects as a single card. In most cases, we will do the strategy, the development and the execution as like three separate cards. So we might develop the strategy for an initiative in January and then the planning and build in February.
And so that way we’re able to take projects in an appropriate chunk. And so that’s been really, really helpful. It gives clients into visibility of what we’ve committed to. It creates some accountability for their teams because again, they don’t like to be the reason we don’t clear the board. And so that that part has really been really good in giving them structure where the statement of work is more
Jim Ewel
Do you have to anyone in a consulting or an agency environment who is just starting on their journey?
Brandi Starr
Don’t feel like you have to implement it in a textbook case we went through an agile marketing certification we learned all of the best practices, the standard way of doing things. And initially, I was real gungho to implement it straight out of the textbook. Like, here’s what my material says.
Here’s what we’re going to do. However, in a consulting environment, whether you’re leveraging agile for your marketing team or with your clients, there are nuances that are just very different than a lot of other organizations. And so it’s not all or nothing when you are implementing agile even if you just take some of the principles, it moves you in the right direction of being a more efficient more scalable organization.
And so I would… keep going iterate. We talked about being iterative, but iterate on your agile journey, and keep the parts that really work for you and make your teams better, and don’t use the parts that don’t. Like it seems like really simple advice, but sometimes it can be frustrating when you feel like you got to stick to what you learned, and that’s just not the case.
Jim and Frank talk with Tricia Broderick. She is the Founder of Ignite Insight +
Innovation, the co-author of Lead Without Blame: Building Resilient
Learning Teams and someone who is passionate about helping
people and teams succeed.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
We talk Esther Derby about why organizations find change difficult, how to lead positive, productive change, and the role of retrospectives in making teams better.
Transcript
Frank Days 00:02
Joining us is Esther Derby. She’s a consultant and author who draws on four decades of experience leading observing and living organizational change. She has been particularly active in the Agile community serving two terms on the board of the Agile Alliance and co-authoring a book called Agile Retrospectives: Making Good teams Great. Her latest book is Seven Rules of Positive, Productive Change: Micro shifts, Macro results. Esther, thanks for joining us today.
This episode, we’ll talk about why organizations find change difficult, how to lead positive, productive change, and the role of retrospectives and making teams better. So let’s get started. Jim.
Jim Ewel 01:07
So Esther why exactly is change difficult for many, if not all, organizations?
Esther Derby 01:13
Well, I think there’s a lot of reasons. But if you think about it, you know, people make changes all the time, right? So, change is not inherently difficult, you know, change happens all around us all the time. People choose change all the time. Often, it is the way companies go about it, that creates friction and makes it more difficult. For example, I see a lot of changes where a dictate falls from the Elysium, the corporate Elysium. And people have really no context, no understanding about what it’s about, you know, they might get some talking points, but they don’t have a deep understanding of the rationale. So you know, that makes it more difficult. Sometimes people are asked to make, you know, enormous changes, but yet keep up their previous workload. That makes it more difficult. Sometimes companies say they want to do something very, very different, like maybe, for example, that they want to be Agile. And so they overlay a process on top of all of their existing patterns. And they don’t address the patterns. And so the patterns reassert themselves that makes change feel difficult.
Jim Ewel 02:31
In some sense, I hear you saying it’s that people resist being changed. It’s not that they resist change. Is that right?
02:39
Well, I think that’s generally true. I mean, I don’t think any of the three of us here would particularly like it if someone we don’t know particularly well comes in and tells us to start doing things very differently when we have developed expertise in it for many, many years, which is often how it feels in organizations. Someone who doesn’t understand your work comes in and tells you to do it differently. I’m not crazy about the word resistant, people don’t resist change, they respond to change. Most people don’t like being pushed or told to change, as you just said.
Frank Days 03:15
In your latest book, you talk about two lessons you learned early on about change, that any given change might be positive for some and negative for others. And the second one being that change is ultimately a social process. Can you elaborate on those two lessons a little bit more?
03:34
Sure. Well, the story I tell in the book is about the first program I put into production, which was a program to automate an estimating process to making the decorative tape that goes along the sides of cars, I don’t know if it’s still a thing. But you know, that used to be a thing. You manufacture these decorative tapes and going cars. It was a very mathy program. And I overheard a conversation between the chief estimator and the head of the company the day before that went into production. And, you know, the chief estimator agreed that it worked, and it was faster, and that was accurate. And he still hated it. Because it was going to completely change the way he did his job. And his job had involved, you know, a lot of interaction with customers a lot of interaction with the shop, and, you know, working out estimates by hand and he loved it, he loved his job. And we changed that. So it meant to you know, less time talking with people more time sitting in front of a computer. It was a good lesson to learn early in my programming career. So, I think that going back to why change is sometimes difficult is people often don’t take that negative space into account that even if the change is great in the long run. It may have temporary losses, people, you know, may feel like “I don’t know how to do my job anymore. I feel incompetent,” which most people don’t like, or they may lose their routines or their social network may break. So there’s always, always some kind of loss. And it very often gets ignored and not acknowledged except to push people harder.
Frank Days 05:25
I agree with you on that. I had a boss who used to say that people aren’t afraid of change. They’re afraid of what potential impact is of that change. And I think you’re definitely right on with that.
05:35
I think when we talk about change, it’s important to acknowledge those things. And, you know, we don’t necessarily have to make everything happy for everybody. But acknowledging that goes a long way. Just acknowledging that, yeah, it’s going to be different, it’s going to be difficult. And we’ll have to figure it out together.
Jim Ewel 05:55
Yeah. And sometimes I think we can make small changes that can accommodate those things. I mean, absolutely. When I was running a company, we reorganized. This is an interpreting company, we had interpreters that sat in cubicles, and we reorganize them according to language instead of where they sat. And it turned out that people like sitting next to the person that they’d sat next to for three or four years, you know, and it wasn’t a big deal, we can make some changes to do that. And we ended up doing that.
But we had some struggles until we realized that we were unintentionally causing pain. In your book, you have seven rules, or you call them and I like this, you call them heuristics, okay, so not a fixed rule, but heuristics, right, for effecting change. So we don’t have time to cover them all. But I do want to talk about the first rule, striving for congruence. And I was particularly struck by that, because in a book I wrote called The Six Disciplines of Agile Marketing, I advise people to start with alignment. And I was thinking about that I was saying about the difference between congruence and alignment. Do you think there’s a difference between those two? And if there is, what’s the difference? And why start there?
07:16
Well, tell me a little bit about how you’re thinking about alignment.
Jim Ewel 07:20
I was thinking about it in terms of like, for example, if people are going to implement Agile, I tell them first get aligned on why are you implementing Agile? What does success look like? You know, what are the conditions for implementing Agile, you know, get everybody to talk about that and get aligned on that. I also suggest that they talk about what they like about how things work today, so that they can accommodate those as much as possible. And so I just, I just say up front, you need to get aligned on some of that stuff.
08:00
That’s really interesting. I think it ties in very closely. The first part of what you said ties in very closely with the first topic we discussed, which is why change is sometimes difficult, because people don’t understand what problem they’re trying to solve. And people don’t understand what outcome they’re trying to create. It’s very, very difficult for people.
Jim Ewel 08:20
I also say that people support what they help create. So I think it’s important, absolutely right. It’s for people to get aligned in terms of that, you know, their voices heard in ways.
Esther Derby 08:35
And I think your insight about paying attention to what people value about the present is also super important and often overlooked. Think about what you want to keep as well as what you want to change. So I’m going to answer your question about congruence. But first, I want to say it sounds like we’re kind of aligned on change.
Jim Ewel 08:58
Yes, maybe we’re congruent.
Esther Derby 09:02
Or maybe we’re both approaching change from a stance of congruence. So congruence is a concept that comes from the work of Virginia Satir, who was a pioneer in looking at families as systems. So when someone would come to her with a problem, she wouldn’t just look at the identified patient. She’d look at the whole, the whole family system, and while I am not trained as a psychologist or a social worker, a lot of what I have learned from studying her work is very applicable to human systems. So congruence is this idea that in any interaction, you have to balance the needs of your own needs, skills and capabilities. You have to consider those of the other people you’re working with. And you have to look at the context. So self, other and context. And those need to be roughly in balance. And it’s never perfect. It’s you know, I say strive for congruence rather than, you know, be congruent, because it’s always easy to get kind of knocked off and you know, kind of get back on track. I think of it kind of like a wobble board, you know, like you’re near never perfectly balanced, you’re always making adjustments. But those are the things you have to consider. And I think that’s actually, there’s a lot of commonality in the way you’re talking about alignment. Understanding the rationale has to do with the context, like we are in an organization, we’re in a business that needs to stay in business, the world around us is changing, we need to respond differently, therefore, we need to make some kind of change within our organization. So that’s the why piece that you’re talking about with alignment. And then what, you know, what do we value? And what do we want to keep, I think is very similar in some ways to let’s, let’s look at the other people involved in this change. You know, what are their wants and needs and capabilities and desires. And then the sell part comes from how you approach going about change. So I think there’s it, I think there’s potentially a lot of similarity in how you talk about alignment and how I talk about congruence.
Jim Ewel 11:23
It’s interesting to me the differences because what you’re saying for congruence is that it’s also about meeting the needs much as possible, of the different I’ll call them interest groups for the different parts of the organization, we need to meet the needs of, of management, we need to meet the needs of individual contributors, we need to meet the needs of middle managers as much as we can and still achieve our goals.
Esther Derby 11:51
We certainly have to consider them. Right. If they’re if they’re not considered at all, then you know, you’re not likely to meet any of them. And I don’t think you can always do it perfectly. I don’t think you can meet everybody’s needs perfectly, but I think it’s helpful to consider them, you’ll end up with a much more robust idea of how to go about change, if you give them consideration due consideration, and adjust how you’re approaching things based on that. What other differences do you see, I’m curious about that,
Jim Ewel 12:24
Those are the main differences, I think we’re aligned on aligned, right, where we are aligned on the general approach, but I like the strive for congruence that you you’ve mentioned. And I also like your analogy of the Wobble Board, you know, you can’t meet everyone’s needs, and it’s not a static system, it’s going to, it’s going to change a little bit, and you have to adjust your balance, you know, to stay upright and respond to those things.
Esther Derby 12:58
Yeah, I also think it’s, um, you know, it’s an individual stance, but it can also be the characteristic of companies. I visit some companies where they do generally try to balance those things. And I visit companies where they don’t, and that shows up in the company culture a lot. Like I see a lot of companies that are that have a very blaming culture, which is an incongruence stress stance, because you’re not considering the needs of other people. Generally speaking, if you’re in a blaming, if you’re in a blaming stance, but from an individual standpoint, I think it’s important because that’s where we can access our best thinking. And that’s where we can access our empathy. And it’s hard to access empathy. When you’re blaming, it’s hard to access empathy when, though you’re blaming someone else, or you’re blaming yourself or when you’re not considering anything but the context.
Frank Days 13:51
In your book you have Rule Five is “experiment”. As you say, little changes, limit disruption and allow people to learn. Can you share with us an example of an experiment that one of your clients took that was particularly effective?
Esther Derby 14:07
I can tell you about an experiment that in some ways failed, but was super useful because we’ve learned something from it. And what was learned from it allowed us to take a different approach and discover some other things. I was doing some work with a company who like many companies, they were trying to do Agile, do the Agile, and their sprints were almost always overstuffed. So we started asking questions about what was going on with that. So we did some little experiments to see if we could shift the dynamic in the commitment meetings. The teams weren’t actually present, as it turned out, so people would talk about the team’s commitment, but the teams were never actually in those meetings. And there’s, there’s one problem right there. But we started trying to make the team velocity visible. This is how many stories the team has committed on average in the last six Sprint’s, so let’s not commit to more than that. And having that information visible, we thought might change how people behaved, but it didn’t.
So the next thing we tried was we gave people physical tokens, we gave them poker chips and said, Okay, you can, you know, move a move one to the next to the other pile each time you add something. And when you’re out of chips, that’s it. And that also didn’t have the effect, we thought it might, which led us to look at some look at some different areas about what was going on in the system. And it turned out that while the teams actually had a very consistent velocity, they also very consistently got stuck in the middle of a sprint because they had some big technical issues. And so the teams would take in extra work. So they had something productive to do when they were stuck on these big technology problems. But it masked the impact of these technology problems. And it created this dynamic where the teams were saying, oh, let’s do 100 But they only finish 70. And so people were mad at them, because they were only finishing 70 Why don’t you follow through on your commitments? So that was really useful in learning something about the system?
Jim Ewel 16:37
Well, Esther, I can’t leave this interview without talking about retrospectives. Okay, you co-authored a book on that. And I find that a lot of teams, they either don’t do the retrospectives, or they do them ineffectively. So why are retrospectives important? And how to teams make them something that’s a meaningful meeting?
Esther Derby 16:57
Well, first, I want to say there are also a lot of teams that are doing really great retrospectives, and having great results with them. Sure. So it’s not that, you know, everybody’s failing with them, I have, I’ve seen a lot of teams that are really making good use of them. And there’s a company out in Southern California that I think has actually experienced some significant transformations because of their retrospectives. But you’re right, a lot of teams are getting really shallow results or no results. And I think there’s a, you know, a handful of reasons that happens. After looking at many, many companies and talking to some friends who have data on it, a lot of teams have been taught that a retrospective is just you make a list of what went well, what, what didn’t go, and what we would do differently, and then you dot vote. And those teams typically have very shallow insights, they are not really understanding what’s contributing to their issues. So they’re very superficial, they tend to get bored and think they’re useless, because they kind of are.
Jim Ewel 18:09
Yeah, you know, I mean, okay, so what should they do instead?
Esther Derby 18:13
So it is possible, if you have really great facilitation, to have a good discussion based on making three lists. It’s possible, but I find it much more effective to one to have a focus. Because very often, those lists are scattershot, right, there’s just a kind of grab bag of everything. So have a focus, you know, this week, we are going to look at our patterns of defects. Or this week, we are going to learn look at our relationship with this other team that we need to work with. Or this this iteration, we’re going to focus on our technical practice or whatever it is, but have a focus, and then have some data. You can have subjective data, which is how people feel about things, people’s perceptions about things, are you going to have hard data but have some data? Because otherwise, you know, you’re not grounded. And then once you have some data, you know, that’s related to your focus, you can actually apply your analytical brain to it and have some insights about the nature of the issues you’re experiencing. What is getting in the way of achieving what you hope to achieve? What is the goal that you want to move towards? And with that, then you can think about what are we going to do about it? And then you choose one or two things to do about it.
Frank Days 19:35
It’s interesting, too, because it feels a little bit like you know, obviously we got to change the behavior to get different results. Right. I know I’m a guilty party when it comes to retrospectives that we’ll go and make some insights and then we’ll try to make some changes, but then ultimately, behavior. We come back a month later and we still overstuffed to the sprint with too many tasks. And I think you’re right. It is like trying to ask different questions and look and look at it from different angles. instead of just the staid, same old, same old, what went well, what didn’t go, Well, what can we do differently kind of questions.
Esther Derby 20:08
And what does that mean? It’s also important, like we talked about this at the beginning, you have to look at what holds the current pattern in place. You can’t just expect people to change their behavior, if everything in the system is only to all the other incentives in the system, formal and informal, are holding current pattern in place. If everything is influencing the pattern in one direction, you know, individual skill and will is often not sufficient to switch it. There were a lot of things that kept that old patterns in place. And often you really, it’s necessary to look at those that retrospectives don’t do anything. Another is that the expectation is that teams are always working on features, and that any improvements from the retrospective are, you know, done in all in all of the copious extra time that people have after they’ve worked a sixty hour week.
Esther Derby 21:07
Don’t overstuff your sprint. One, because things are going to come up, they always do. People don’t build in time where the expectation is people are going to be using this time to learn, to work on improvements, to figure out how to do something differently. Because all of that learning takes time. We all went we and we all went to school at some point we put in some time studying why do we forget that when we get to work?
From the publisher's feed