Agile Mentors Podcast

Join Brian and Dr. Tess Thompson as they delve into the complexities of scaling Agile, highlighting the challenges of aligning leadership priorities, fostering transparency, and applying system-level thinking for successful organizational transformations.

Overview

In this insightful episode, Dr. Tess Thompson tackles the pressing challenges organizations face when scaling Agile, with a focus on the critical role of leadership alignment. Drawing from her extensive experience, she explains how misaligned priorities at the leadership level can stall progress and waste resources.

Dr. Thompson emphasizes the importance of system-level thinking, transparency, and communication between teams and leaders to resolve misalignments and ensure success. She also shares her holistic approach, blending practices from various Agile frameworks to meet the specific needs of different organizations.

References and resources mentioned in the show:

Dr. Tess Thompson
Scrum Inc.
Scrum.org
#68: The Pros and Cons and Real World Applications of SAFe with Mike Hall
#94: Connecting Teams and Leadership with Anthony Coppedge
Three Questions to Determine If an Organization Is Agile by Mike Cohn
Certified Scrum Product Owner® Training
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Dr. Tess Thompson is a visionary leader in Agile transformations, with over three decades of experience reshaping industries from energy to biotech across the globe. As a professor at St. Mary's University, her dedication to fostering Agile leaders has empowered countless individuals to embrace adaptability and forge their own path to success.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Dr. Tess Thompson with me. Welcome in Dr. Thompson.

Tess Thompson (00:13)
Hi, I'm glad to be here.

Brian (00:16)
I'm so happy to have Dr. Thompson with us. And just for people who aren't familiar, let me make sure that I introduce her and give you the background a little bit. First of all, she's been in this business for almost 40 years now. She's been doing stuff in IT since the 80s. She is a principal consultant and RST fellow with Scrum Inc. Scrum .inc, I should say. She is a PST as well with scrum .org. So two different organizations from two different founders of Scrum. She has been a professor at St. Mary's University. So has that kind of educational background as well. And I was asking her beforehand if there's anything else I needed to say. And she said, well, make sure you say I've got nine grandchildren. That's kind of my claim to fame. I love that. So. Nine grandchildren, very happy for that. So that's who we're talking with. And we wanted to have Dr. Thompson because there's a lot of experience here that she brings to the table in the realm of scaling, obviously being connected so closely with those two organizations. So with all that out of the way, let's talk about scaling a little bit. And Dr. Thompson, what I want to start with is just

Tess Thompson (01:27)
I'm

Brian (01:40)
When you work with organizations today that have scaling issues, what are organizations really struggling with? What's kind of the main issues that you see organizations have with scaling today?

Tess Thompson (01:55)
I would say there's a lot of things, but I would say still the biggest problem is getting everybody to align on what the priority is. So at some point, like you get alignment with maybe people that are doing Scrum and they're the people that are above them, but then the people above them are out of alignment. like, for example, one of the clients I have right now brought some consultants in to work on a project.

Brian (01:59)
Yeah, right.

Tess Thompson (02:24)
And those consultants have been stuck now for four weeks. And where the alignment problem is, is actually up at the C -suite with this client. Because one of them says, nope, we were supposed to help. That was a priority in 2023. And the other one's like, no, this is a priority in 2024. And they're not helping each other. So in the meantime, this project is stuck for four weeks. And we're spending money on people that are sitting there doing nothing.

Brian (02:50)
So just when you say alignment, give us kind of a flavor. when leaders are misaligned, what kind of things are they, are there different ideas about priority or different ideas about why they're doing this? What are they misaligned on? Okay.

Tess Thompson (03:09)
Both, both, I would say both. The, you know, especially as the companies get bigger and bigger, we have a CEO who's got some priorities, but then all the C -suite under them have their own priorities and they're not always, and then they break down to the next level and these priorities start to get out of alignment because people start bringing in their own objectives and their own priorities and they often don't match what somebody else is doing. So part of it is the different incentives and just the organizations being so big, they have to get even these priorities aligned at different levels.

Brian (03:49)
So this is kind of an amazing thing, I think, for people to latch onto here, because I hear a lot of people in just regular base level classes talk about how there's a disconnect between them and the leadership on how they're going to do Scrum and how this fits into the overall structure of the organization. just understand, Dr. Thompson here is talking about organizations that The leadership has stated, at least in some way, or form, we're in alignment with this. We want to do this. We want to have Scrum throughout our organization. But even in those situations, we're seeing these misalignments of just priorities and what are the drivers really for what they're trying to do. So I find that fascinating that talking to so many people who just wish that their leadership could get on board. with what it is they're trying to do, that even in those organizations where they do, quote unquote, get on board, there's still these kind of fundamental disconnects.

Tess Thompson (04:51)
Yep, absolutely. In fact, I do very little work anymore on scrum specific. is many organizations, I mean, almost every organization I go into anymore has some shape or form of scrum going on or people with experience with it. Some people, you know, they're not, it's something that they're trying to do anyway, something agile. And they're... They're getting things done quicker. They're delivering with higher quality. They have better communication at that level. But then as you go up the chain, things start to break down and then teams are stuck. So organizations can only get product out the door with high quality as quick as possible. The more the organ... We have to really think the system. So most of the work that I do today is around the system, which is scaling. It's system agility. Otherwise you start having, you just run into optimization in areas, that local optimization problem.

Brian (05:58)
Yeah, yeah, not seeing the whole, right?

Tess Thompson (06:02)
Right, absolutely. So I think that over the years that Agile has been around, we're seeing more and more of it, but then it's, like I said, almost all my work now is system level and not down at the team level. So often I'm not even using Scrum language when I'm talking. It is about alignment. It is about prioritization. So yes, at a Scrum level, your product owner is putting the order of the product backlog, and then the team can pull out off that backlog. based on value from all the different stakeholders that the product owner is working with. But in a big organization, those stakeholders can be a manager, can be a director, it can be another department, it can be, it's from all over the place. And then at some point, how does that work coming into the product owner roll up to the priority of the department or a higher level? And then how does that roll up to the higher level? And that's where we start running into messes.

Brian (06:58)
Yeah. Yeah. Yeah. mean, it's like you said, with all these various priorities, with all these various drivers, I've always talked to product owners and say, it's a tough job. You're balancing the needs and desires of all these people into one product, and you're having to take them all into account. So yeah, it's not easy. It's not an easy job.

Tess Thompson (07:08)
You.

Brian (07:27)
Well, so I'm curious about, you say you don't really even use the Scrum language as much when you're talking to the leaders, because they're not really interested in that, right? They're not really interested in, we doing this exactly according to what the Scrum guide says? They're interested in the outcome, right? The results that you're getting from this. Yeah, so I'm kind of curious, especially since you're a fellow with Scrum Inc. And I know that the...

Tess Thompson (07:37)
No. Absolutely.

Brian (07:55)
a Scrum at Scale kind of strategy is very specific about how these things are implemented. There's practices and all sorts of stuff that Scrum at Scale kind of implements. Would you categorize yourself as sort of a Scrum at Scale implementation consultant? Or is it more of just, I take more of a holistic approach to the scaling.

Tess Thompson (08:19)
Holistic, absolutely. So actually, I'm certified in Nexus, Scrummit Scale, Less, and Safe. I mean, I have all of them. So I always think you need to bring the best tool to the job. One of the things I like about Scrummit Scale and Nexus is they're just so simple. Like if, hey, if these two teams are not, if we need to coordinate, let's get these product owners together and work together to figure out what is really the order. So whether we call it a meta scrum or we call it something else, I don't think that language matters as much as seeing the need and then bringing in a tool to help meet that need. If these teams are interdependent and they need to be chatting to help get rid of those interdependencies, well, let's spin up a scrum of scrums here.

Brian (08:58)
Yeah. Yeah. Yeah. I've had someone on before that we've talked through kind of the safe model a little bit and talked about how, you know, there's so much additional overhead, there's so much additional roles and events and all these other things that get added from the safe perspective, that it can be very, very overwhelming for a lot of organizations to look at that and say, well, gosh, how are we ever going to, I mean, we're barely hanging on with it, trying to understand what Scrum is. And now we're going to layer in all these other things and,

Tess Thompson (09:22)
Thanks. Okay.

Brian (09:38)
It just seems like a recipe for disaster to try to understand all these things. So I guess one of the things that I had in that previous conversation was this dialogue about how you match the problem to the practice. You find the problem that is going on in the organization and you find the right practice that solves that, but not necessarily implementing the whole smorgasbord of practices because you may be trying to solve problems you don't have. Do you see that as kind of your approach when you work with organizations or how do you match the practices to what's actually going on on the ground?

Tess Thompson (10:18)
Yeah, I would say, you know, it's kind of similar to what happened with, so I'm also a PMP. So when we When we put together the PIMBOK over the years, it became this, know, it was supposed to be, these are best practices that you can have. And over time, it became very, big, thick book and people didn't understand they were only supposed to implement whatever tool from that book really helped solve the problems they were having. And started implementing the whole thing. And I think that's what happens too with like,

Brian (10:50)
Ha ha.

Tess Thompson (10:53)
safe or any of these agile practices, even though, know, Ken and Jeff went completely the opposite of PMI and said, hey, we're just going to roll out. This is the absolute minimum that you need for running, running a team or a project or product. And, but it's not enough. So you need to add in some more things to it. You got to bring in some additional tools to help depending on the organization, such as road mapping. I really believe that's one of the. I spend a lot of time helping organizations and product owners think about, we do need to plan ahead. And that is one of the pieces I do like about SAFE is that in their PI planning, have the getting some product owners and teams together to plan together to look out further, I think is pretty essential in most organizations. Now, do we need to do it on a regular cadence of every eight weeks? And do we need to have 200 teams together? I think

Brian (11:23)
Yeah.

Tess Thompson (11:49)
Sometimes it's, think organizations end up implementing all of SAFE, kind of like in the pin box, if you will, and it's way more than they need. So I think it's taking the elements of all of these and then using them to meet the need of the organization. I mean, if you're a 30 person organization, do you need a bunch of release trains and engineers and stuff? No.

Brian (11:59)
Yeah. Yeah. Yeah, I mean, it's very interesting to me with your background that you have all of these different scaling frameworks in mind. How much of what you do do you feel is aligned to a specific framework and how much of it is just piecemeal across the different frameworks?

Tess Thompson (12:34)
I would say I'm most aligned to, well, Scrum at Scale, never solely. It's always piecemeal. It is a piecemeal thing because I really do believe that teams do get to need to plan out in almost every company I go into. Teams do need to plan out more than one sprint.

Brian (12:44)
Hmm.

Tess Thompson (12:54)
Okay, we need to plan out and we're never delivering anything alone with one team. It seems like we're always need multiple teams. So we need that coordination and we need some of the scaling practices for sure. I really use a variation of safe of PI planning, but then I layer in, so we put together our plan for let's say the month, maybe we have a product goal for the month. And then I use the version of PI planning to get the teams together to plan out for sprints. weekly sprints to get to that product goal and try to get rid of the dependencies and problems that we see between the teams. And then we let it run. But then I pull in from Scrum at Scale, definitely the Metascrum. Like every sprint, let's still get the product owners together and revise our sprint plans because we've learned a lot in the last sprint or we learned a lot today. So we're not just going to let it ride for a month, for example, we're going to still get together at a regular cadence, like once per sprint. and realign our backlogs based on what we've just really happened. So it's using both, yeah.

Brian (13:55)
I love that. Yeah, taking the best of what these different practices offer,

Tess Thompson (14:04)
Absolutely.

Brian (14:06)
I love that. Well, one of the things that I wanted to talk to you about as well is sort of in working with scaling practices, I'm sure you already talked a little bit about how leadership has different ideas than the team level does. And the team level is kind of struggling with a certain layer of complexity. The leaders are struggling with another.

Tess Thompson (14:22)
Okay.

Brian (14:33)
I know there often appears to be sort of a disconnect between these two groups. I've talked to people who feel like they're speaking a different language. It's sort of like the leaders are, especially when teams, the team level will look and see, there's people in leadership who just, they want us to do Scrum, but then they want a lot of things in the same way that they always have, which is really hard for us to translate and put back into that old language. I'm just kind of curious your thought about that. Do you see leaders, the leadership layer as sort of speaking a different language than the team layer and how do you help them understand each other?

Tess Thompson (15:13)
Yeah, I mean, my most successful implementations is definitely when the leaders are on board. Leaders are really important to agility. We need their help and we need their support. What I always find super interesting is when I go into an engagement, I usually run an assessment, an agility assessment. And what I'm measuring is kind of where the organization is on culture, delivery, how well they're continuously improving or optimizing the system, how well they prioritize and how customer centric they are. Because I really believe agility is about those... It's those five dimensions, if you will, that you need to really focus on. And so I run this assessment and I always have them self -assess through a survey, interviews, and then observations. So often I see my assessments different than maybe how they self -assess and I'll compare both of them. But the leadership assesses so different than the teams do. And so at the end of the assessment, it's just interesting how different they are.

Brian (16:13)
Yeah.

Tess Thompson (16:21)
The teams are thinking they're delivering so well because they're getting all kinds of stuff done and leadership's like they're delivering, they're not delivering. And it's, like, how do we get so out of aligned it all the time at companies? Yeah.

Brian (16:35)
Yeah, yeah, we will do an assessment to it mountain goat. And one of the things that like became clear to me very early in doing that is that self perception versus, you know, perception of others is very different. And, you know, it was amazing to me, just like you said, to see things like the leadership might think that you have one opinion of something and the teams might have another or, you know, the other thing that I saw was was You know, like the Scrum Masters might think, yeah, our practices are great or they're going really well. And then you ask the developers and developers would say, no, it's horrible. We don't like the way this is working. so, you know, it kind of became apparent to me that you have to factor that human personal perception, right? We tend to be maybe individually more critical on ourselves, but

Tess Thompson (17:18)
Okay.

Brian (17:34)
you know, as a group, tend to give ourselves a little more grace in how we're performing, whereas others, when they look in from the outside, will kind of be more honest about it and say, it's not so great in this situation.

Tess Thompson (17:49)
But what I often find is they are delivering. The thing is they're delivering a bunch of things that the leadership doesn't even know about. So the leadership will have their priority list in their head of projects or things they want the teams to be delivering. But the team is getting hit with all kinds of other stuff that the leadership doesn't know about. So they are working hard and they're delivering. So in their head, they're doing it. It's just this.

Brian (17:56)
Yeah.

Tess Thompson (18:12)
the leader maybe not attending to a sprint review and really understanding what the teams got on their plate.

Brian (18:17)
Yeah, and that's kind of that transparency moment, right? mean, if they think they're not doing anything, they may be, they're just not seeing what they're doing and what they're actually spending their time on. And it's not that they aren't really working hard. As you said, they are working hard. It's just the work they're being asked to do is not really in align with what the leadership thinks the priorities should be.

Tess Thompson (18:22)
Yes. Absolutely, that's it. Yep. And then should the people be working on the stuff that they're working on? You know, is it the right thing? And often it may not be.

Brian (19:00)
Yeah. Yeah, I know I've had several instances where I've talked to people when I've been in working with teams where they will, the team level will say, you know, we have all the stuff that we're having to do in addition to the new work. And, you know, we know that that's just kind of a constraint we're under. The organization has asked us to do this as well. And, you know, my comment is always, well, Are you being really transparent about that when you get to something like a sprint review? Are you showing them where you're spending your time? Are you showing them kind of how much of this extra other work you're doing? And I've had situations where we've been in sprint reviews and we've shown them, for instance, like how much support time that they've had to spend. when the lead, right. And the leaders see that and think, my gosh, I didn't know they're spending 60 % of their time doing that kind of work. That's not good. We want them to do,

Tess Thompson (19:32)
right. Yep, eye -opening.

Brian (20:00)
new work. So I've had leaders who have actually spun up support teams when they've been confronted with that just because they didn't know what was going on.

Tess Thompson (20:09)
Yeah, absolutely. That is one of the things I love about sprint reviews is that transparency. And I have seen teams also go into sprint reviews thinking that they just want to show like some progress they made on an increment for a project and not talk about the support work that they did or some of the other buckets of work that come in. And I'm like, you. Part of transparency is seeing, hey, and it doesn't have to be that you show all the support tickets or anything like that. It's talk about something like 50 % of our time, of our capacity was spent on support tickets. Just throwing that in there to make sure leaders are aware.

Brian (20:45)
Yeah. Yeah. Yeah, I want to go back to something you said earlier too, because you were talking about when we first started about how one of the biggest issues is alignment on priorities. And I want to just dig under the surface in that a little bit, because when we talk about that alignment of priorities, are we talking about more of the product area? Are we talking more about just a general overall? What's our company's priority? What kind of priorities are they misaligned on?

Tess Thompson (21:08)
All, I would say all, all priorities are misaligned. So it's been an interesting move to, for me, to Scrum Inc. Because Scrum Inc's clientele is very much

Brian (21:21)
Right.

Tess Thompson (21:35)
scrum mostly outside of IT. So it's been really fun for me because my career and background was all in IT. So I've been learning so much about all these other different domains out there. And we're doing full transformations of an entire company is doing a version of scrum, right? Or scrum at scale so that they're aligned on priorities. And anyway, so it's very... It's all, all the work tends to be a little out of alignment. And going back to the support, I really like to work companies to help them really understand that almost all support, whether it is support in a field that's doing some kind of drilling or it's or it's IT support or it's HR support, you know, taking phone calls from the employees that it tends to all be tech debt. All support is really some form of tech debt. And so getting that message out there, how much time we're spending on and how much money we're spending on support helps companies, leaders to agree to fund some of these.

Brian (22:44)
Yeah.

Tess Thompson (22:57)
projects around reducing tech debt.

Brian (22:59)
Yeah. Yeah. And there's always the having to overcome the kind of more traditional viewpoint of projects and these things based around projects and scope schedule, that sort of thing. How do you help leaders understand kind of this is a new way of doing things and not that we can't talk about schedules, but

Tess Thompson (23:07) 
Okay.

Brian (23:29)
that we're kind of shifting our priorities a little bit, or we're trying to focus on what matters more than arbitrary dates. How do you have those conversations? How do leaders understand that?

Tess Thompson (23:38)
In some organizations it's easier than others. It depends how much the leader above those leaders is on board, to tell you the truth. So I feel like fundamentally they understand. And if we bring up two different priorities and it's two vice presidents, for example, and they're getting bonuses or something based on their performance in their area, we can see

Brian (23:50)
Yeah.

Tess Thompson (24:08)
They fundamentally will understand in a meeting together, they'll understand and then we'll leave and they'll still kind of do their own thing. But if I could get even though like the person, the CEO also, a person above them be like, nope, this is important. And for that person to see the two competing priorities and where there's a problem, I mean, it's really about if there's a problem, right? And then they'll agree and kind of one will give up a little bit on.

Brian (24:30)
Yeah.

Tess Thompson (24:37)
on their ambition towards getting their thing done, understanding that it's good for all of us, the whole company, we all, to get to work on maybe the other priority first.

Brian (24:50)
So a lot of negotiation involved, right? A lot of negotiation skills.

Tess Thompson (24:54)
Absolutely, and getting people in the same room so that they can have the conversation together. You know, it's not me talking to one and then going and talking to the other. I mean, there is some of that too, but then we have to get together here and decide. And yes, unfortunately, yeah, and yes, we will probably be working on these at the same time. However, if there comes into, you know, with an or,

Brian (25:10)
Yeah, it's amazing how much easier that is, right?

Tess Thompson (25:22)
With a large organization, when you've got hundreds of thousands of people, of course we're working on a ton of things at the same time. But when there is a conflict, like we need this skill set here and this, then we have to know which one is more important.

Brian (25:37)
Yeah. Yeah, and someone has to make that call, right? Someone has to be given that authority at some point. Well, this is fascinating stuff. I'm really interested in hearing your perspective of working with these organizations in today's world. So last little question here. From what you just see, especially most recently,

Tess Thompson (25:44)
Yep.

Brian (26:07)
from what you've seen in the organizations you've worked with. If you could just blanket, have one thing fixed before they start working with you, or one thing that they were in alignment with that would really give them a boost in their scaling before they start working with you, what would that be? What would be the thing that you think is most often missing in organizations before you work with them?

Tess Thompson (26:33)
Getting their goals, their strategy and starting to build out their backlog. based on those priorities. In fact, I usually do ask that. Start thinking about what are really your goals? What's your strategy to get there? And what kind of things are you doing to get there? What products are you creating? What services are you What projects you're creating for those products? Start thinking about that and start being a list together. And then when I get there, I'll help organize the list if you don't have it. But it's just starting to think about that ahead of time. Because what I see is leaders or people have multiple lists. They have a list over here of their projects. They have a list over here of stuff they're doing. They have all their emails that are coming in, their chats that are coming in, the phone that's coming in. And it's like, can we get it all kind of in one place so we can really look at it to make better decisions on really where we should be spending our time and our money?

Brian (27:14)
Yeah. Yeah, yeah, that's a great point. A friend of mine, David Hawks, used to say that organizations are swimming in a sea of opportunity. There's all these different things we could do and really trying to limit that scope and say, yeah, we could do all these things, but what makes the most sense for us to do? What's the most valuable thing for us to do?

Tess Thompson (27:58)
Yep, absolutely. And getting in touch with and constant feedback with your customer helps you figure that out. So many companies don't even, the people are like, have no, I always love when I get a group and I said, hey, let's name our customers. And they're sort of out of the line on who their customer is.

Brian (28:19)
Right, and if you don't know who it is you're trying to serve, how do you serve them? Yeah.

Tess Thompson (28:25)
Yeah, yeah. That's usually one of the first things I ask is, hey, who's your customer? Is it the shareholder? Is it this? Is it that? Let's agree. Yes, you will have multiple customers. Let's get it together and understand who are our customers. Let's all agree on that. Maybe even a priority on some of those customers to some degree.

Brian (28:30)
You Right, love that. Right. Yeah, yeah, this has been great. Well, I really appreciate you taking time out, Dr. Thompson, for coming on and helping us and to see things from your perspective. It's so great to talk to people that are, know, not just, you know, this isn't just theory or book learning. You're actually out there, you know, doing these in these large scale organizations and, you know, hearing from you what those real world problems are that you're seeing on a day to day basis.

Tess Thompson (29:18)
And I'm having amazing, amazing results. tell you, I'm, that's why I only had three hours of sleep last night and I'm still.

Brian (29:27)
Ha ha.

Tess Thompson (29:28)
woke up full of joy to be here with you today is I love what I do because I'm constantly getting phone calls after the factor during it and it's like, wow, this stuff really works. I'm like, yeah, it does. It really does.

Brian (29:41)
Amazing when that happens. Awesome. Well, thank you so much for coming on and I just appreciate you sharing your wisdom with us.

Tess Thompson (29:53)
Anytime. Thank you for having me.