Episode Description:
In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by AgileThought colleague and return guest, Eric Landes. Eric comes from a DevOps background and originally started as a developer. Currently, he serves as a senior DevOps consultant, ALM director and solutions architect at AgileThought.
This week on the podcast, Dan and Eric are discussing organization transformation. (If you haven’t already heard Agile Coaches’ Corner Ep. 59, “The Four C’s of Organizational Culture,” you should tune in to that first, as this episode makes reference to it). Today’s episode is asking the question of whether an organization should start by implementing a practices-based change or a culture change when they’re looking to transform.
Is starting with changing the culture a more practical approach, or is keeping the culture as it is and incorporating more agile practices over time more beneficial? Tune in to hear Dan and Eric’s take.
Key Takeaways:
- A culture change approach vs. a practices-based approach:
- A practices-based approach generally refers to making small changes to behavior
- A culture change is more of a big bang whereas a practices-based approach is more of an agile journey
- A culture change is more of a plan-drive, A-B transformation; a practice approach is more of an incremental, step-by-step process
- The argument for taking a practices-based approach to transforming an organization rather than changing the culture first:
- The ability to change practices and shift the overall mindset without changing the culture is a more achievable place to start—it’s also more of an agile mindset/method (because you’re starting with a practice, seeing how it helps, measuring it and then moving forward)
- Practices get modified over time so it can be beneficial to be more agile as your organization is going through a transformation (rather than going for that “big bang” that a culture change would call for)
- Putting practices into play (such as test-driven development, breaking down product backlog items, or implementing more Kanban metrics) can help the organization discover what fits and what doesn’t fit into the current culture and also what delivers the most value to the customers
- Using metrics and practices will lead to changes in thinking around how the organization is delivering
Mentioned in this Episode
Eric Landes’ Book Pick:
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now, here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner. I’m your host, Dan Neumann, and happy to be joined today by colleague Eric Landes. Thanks for joining.
Eric Landes: [00:25] Hey Dan. Thanks for having me on.
Dan Neumann: [00:26] Anytime and two episodes ago, there was a conversation or monologue, really about the four Cs of organizational culture. And the Schneider model was used for that. And Schneider basically breaks culture down into control, collaboration, cultivation or competency. So he makes those four distinctions and using those cultural aspects to promote agility was the topic of that. So if you haven’t listened to that, that would be a not you, Eric, but you, the listener haven’t listened to that, it’d be good to go back and maybe listen to that after because today’s episode is also related to or has a cultural component to it. Talking about agility and starting with practices or starting with some type of change to the culture.
Eric Landes: [01:22] Yeah. Uh, I think, you know, we had talked about, uh, some comments around should we start when we’re transforming an organization, does that start with, uh, changing the culture to a more agile culture? Or there’s other folks who might say, let’s start changing practices within the culture. And you and I were just talking about this, uh, maybe you, you know, let’s use the culture as it is. Let’s start doing more agile practices and then maybe the culture will change. Maybe it’ll stay the same, but we will be introducing agile. And, uh, you and I talked about maybe just having a conversation around that. What does that look like? Um, how, how would you do the practices versus changing, you know, culture from the, I look at that more as top-down and organization-wide practices-wide.
Dan Neumann: [02:22] So starting with the, the practices, making small changes to behavior I think is what comes to mind for me. So when somebody talks about, uh, a desire to change the culture, that in and of itself, even if it’s possible, and I think that’s, that’s where the previous episode, I’m not, I’m not convinced that it’s possible to change the culture of an organization per se. There’s just so much involved in that. But the ability to change practices shift the mindset even without changing the culture, I think is a far more achievable place to, to start.
Eric Landes: [03:00] Exactly and, and as I said, I would, I would argue that’s a little more of an agile mindset of let’s start with a practice, see how it helps us measure it and then move on. You know? Uh, I guess that’s, that’s one argument for it.
Dan Neumann: [03:21] So when you say it’s more of an agile approach, to me is it because of the size of the change you’re asking for? It’s small, easier to iterate on, easier to, to change or go back on. Is that part of the reason you view it as a more agile method?
Eric Landes: [03:36] Well that and the end state is going to be different than what you thought it would be in the beginning.
Dan Neumann: [03:46] Right. So, so the culture change first approaches is much like a big bang, Hey, here’s, here’s, we’re going to drive to this transformation. We’re going from a to B and a culture, I’m sorry, a practices based one really is more of an agile journey. Hey, we’re going from where we are now, we have a practice that we think will help us or a mindset shift we think will help us move towards more agility. Maybe engaging with our customers better, maybe delivering working software more frequently, um, maybe being more technically excellent. So some kind of incremental step towards a more agile stance and then continuing on that journey as opposed to a, uh, a plan driven going from A to B transformation.
Eric Landes: [04:35] Exactly. Now I think I get worse and people come from and changing the culture because for some large organizations being able to, let’s say, move into from thinking about a project, you know, from project based work, uh, where we have an end date in, uh, and if we deliver what we promised, that’s kind of the way we’ve done things in the past to a product based mentality where we’re going to keep delivering value to the customer until we don’t need to anymore. And we’re not really planning that right. Uh, that may take some cultural change and I understand where people come from on that. I just believe using the practices, some of those you mentioned that’s going to help, uh, get to that end state, it’s just not going to happen right away. And like I said, the end state may not be what we plan to do in the beginning because as you and I both know, practices get modified and changed through time. So why wouldn’t we, as we’re doing a transformation, be agile and adopt the latest techniques and those kinds of things rather than going for that big bang up front, Hey, we’re all going to do Scrum.
Dan Neumann: [06:09] Eric, when you were talking about starting with practices or culture a moment ago, you’d mentioned the Scrum Framework and I was curious just for clarification, would you view that as more of a practices change or a culture change?
Eric Landes: [06:24] So it’s a practice we would use, but certainly there are cultural aspects to it. And by that I would say things like roles, the role of the Product Owner maybe in that specifically maybe different than a organization has. What I’ve experienced is, uh, getting sign off on that, uh, for that role and for what you need for it. For instance, having profit and loss as a Product Owner and prioritizing, you’re the one voice. Uh, to me that’s the biggest challenge in using that framework and selecting a framework I would say would, would be a practice we’d want to implement as we’re implementing agile.
Dan Neumann: [07:21] Okay. Yeah. And I was at, uh, a place that I think could be described, well, it probably best fits into a control culture. There was a, it was a, a financial institution with a pretty significant hierarchy. And one of the ways the big boss leveraged that culture was saying, we are going to Scrum using two weeks Sprints. Go. There was not a lot of convincing of people that this was a good idea. He wasn’t asking for opinions about whether we should move forward with Scrum. He was a kind of grabbing the reins and saying, this is the new framework we’re using moving away from a heavily gated, um, lots of requirements, lots of design, long delivery cycles. And he said, we’re done with that. We’re going this way now, march. Um, and I thought, I think in my mind that was a very interesting approach to starting down the road of agility using the Scrum Framework.
Eric Landes: [08:21] And I would agree, Dan. And, and the more as we talked through that, that almost is implementing a practice in a way, right? So the culture hasn’t changed right? When the, when the, when the gentleman said we’re using Scrum, the culture didn’t change necessarily. Uh, but it might’ve changed after we’ve used Scrum and gotten good with it. Right. Uh, and maybe you changed the way you used it?
Dan Neumann: [08:55] No, it was interesting, I think. I think there, um, some of the control aspects shifted. So by that, I mean there was still an expectation that people would adhere to the Scrum Framework. Uh, I think there were some, we still had feedback loops that were happening, so it wasn’t, um, it wasn’t control culture where it’s, you think of it like a, a pendulum or a spectrum. You can go too far off the control side and that might look like somebody’s doing things that would go against the values of the Scrum Framework, like telling the team how many story points they would use if they’re using that, uh, generally accepted Scrum practice or telling the team the scope of the Sprint and not collaborating on the Sprint goal with the team. So there are ways that control can be very non Scrum in practice. But there are also some ways I think where that um, that culture, um, driving for people really filling the role of the Scrum Master well and not accepting, um, half arsed kind of implementation of the Scrum Master role. I think that’s a way that a control culture can really, um, align with the Scrum Framework and doing Scrum to a level of excellence.
Eric Landes: [10:14] Yeah, that, that makes sense. Well, let’s maybe do a thought experiment in that particular instance. What practice could we implement to help with that? So for instance, the, we are given points that we have to make every, um, know every Sprint a certain amount of points as an organization. Is there a practice we could implement? I’m thinking maybe we implement something like tester and development in that aspect, which, um, might drive points up right to, to when we’re developing software, but we’re getting higher quality software and, and we can prove that. And again, I’m just kinda thinking out loud here. Uh, and what I would like to talk about in that scenario is can we use practices, not necessarily to change culture, but to fit in with the current culture, but to make work better for humans right in the end and to deliver value to our customers.
Dan Neumann: [11:46] I wonder if kind of what you’re describing and uh, for the enjoyment of our listening audience, I am suffering with hotel wifi. And so if there’s a little bit of weirdness in this, it’s because of my, uh, single digit, uh, bandwidth connection here. But something like what you’re describing where a team is told, Hey, here’s the band, or here is the velocity that you’re expected to achieve. That would be a dysfunction I would hope an agile coach or somebody who really understands what’s trying to be achieved would go pretty directly at that dysfunction. And try to remove that. You know, the, the notion of dictating how fast a team should move, use air quotes kind of should move, um, that’s pretty broken. Um, practices that can help a team move more quickly though. You know, we’ve uh, coached together at places where breaking product backlog items down into smaller pieces so that they can be validated more simply earlier on, either in a Sprint or um, more quickly if you’re doing something non iteration based and flow based instead. So breaking items down smaller helps them flow through the system better and results in a much better throughput from a team. And so that would be one of those really simple to do practices that I think could help a team move more quickly.
Eric Landes: [13:15] I agree Dan. I think another practice that might be implemented, you talked about flow based, maybe we start implementing some more Kanban type metrics. Things like cycle time and throughput that are based on reality and start showing that as also part of whatever metrics your, your management is looking at. Uh, so the team, you know, they’re basically team metrics, but the team can give some predictability, if you will, to, to the, uh, to management. And I’m not saying they’re going to be totally predictable, but there are ways we can, we can yeah. Decent metrics that show how fast the team can produce things. Right. Um, and that’s always helpful. And to me that’s the more thing is let’s help the culture understand what can be delivered, what kind of value can be delivered. And so those would be practices that might help them. So again, that’s another thing I’d throw it in again, a little, uh, advertisement if you will for, for me. But we do a professional Scrum with Kanban course that, uh, I think is super helpful for that kind of stuff to, to actually use those metrics within a Scrum Framework. And a team could do that.
Dan Neumann: [14:48] Yeah. And I think you’d talked about, you talked about predictability and I think I stepped on you due to our wifi thing here at my hotel, but you talked about predictability. And I think you still can be quite predictable. As long as you’re not trying to be overly precise, you know, we will deliver on, you know, January 31st at noon or we will have the exactly the scope done at a particular time. It changes the conversation to, you know, what, based on our performance we expect to be done in this window, you know, January 25th to the 3st or something like that with a certain level of confidence.
Eric Landes: [15:25] Uh, agreed. I, I think we want to give some level of predictability, like you said, don’t, don’t want to be precise and we want to use metrics that matter rather than metrics that don’t, um, your case in point around, Hey, you have to have a velocity of points. Well, points me nothing, right to, uh, in the end, the customer doesn’t care how many points we got done in the Sprint. They care about the features that got done and they also care about if the features got done and they work and they got delivered quickly. You know, typically. So let’s think of practices that help that and if we’re having problems with that, maybe things like continuous delivery can help us deliver quickly and things like automated testing, um, test room and development can help with our quality. So let’s start using those metrics and practices to think more about what we’re trying to deliver. And in the end I think you’ll see changes in thinking around how we’re delivering. And again, fitting it to you, to the organization.
Dan Neumann: [16:47] You are describing with test driven development? You know, given if you’re in a control culture, you, again, you can kind of dictate that if you’re in a collaborative culture, you could say, let’s do this together. You know, we will learn to do TDD and build that skill together. Um, similar with cultivation, Hey, let me help you, you know, Eric, you could help me learn that skill if I don’t have it. And in, in competency culture, it’s more of a, a pride thing. You know, you think of the, um, the craftsmanship movement with which, Hey, if in order to consider yourself a professional developer or a true software craftsman, this is the type of behavior we expect from you. And so that’s how something like a practice might be introduced or encouraged in, in each of those four different cultures.
Eric Landes: [17:39] Nice. I like that description of how you can introduce that. Um, are there other practices you’ve seen, Dan, that you would introduce? I mean, I know we were at a, um, at an organization and we actually tried to do introduce TDD as coaches, uh, or, or started to introduce that. Are there other types of practices you would recommend maybe as early building blocks?
Dan Neumann: [18:13] Oh, the world is our oyster, right? Where to start is one of those challenging situations. Um, you know, for, for organizations that have already decided that they’re going down the path of Scrum, I think like, just making sure that the Scrum practices are in place, that we are adhering to the events. There’s not too many artifacts, but you want those artifacts to be of quality. And that people are really filling those roles well and guiding them through how to form a backlog, what product backlog items go in helping them work towards delivering an actual product increment in the Sprint cause that gives you a taste of success. So I think just starting with the Scrum events and artifacts and roles and doing those well would be the practice. For me that comes to mind if somebody is going down that road, if you’re not going down the Scrum road I think for me the most powerful one is just to start make making things visible and explicit. So that might look like what are we working on right now? Instead of talking about all the different stuff and having the words fly through the air, grab a sticky note, whiteboard, whatever, start enumerating what all the different moving pieces are, what assumptions you’re making, what dependencies you have. So making things visible for me would be the more generic non Scrum answer I would give because then you can realize when you have people that are thinking differently about what work is happening or not happening and assumptions get invalidated pretty quickly when you start to actually make things visible. So that’s, that’s probably my favorite, um, non Scrum type of thing to do.
Eric Landes: [20:08] I love that. Uh, just a quick story on making things visible. At a company I was at a quite a while ago, you might know it actually Dan, but no names being mentioned, we introduced Kanban for the first time and, uh, all we really did, we actually were just making things visible. We weren’t introducing WIP limits or anything along those lines, but we did put the boards in a very visible place, uh, and it showed all the work we were doing. And I remember a manager coming and asking me, Eric, what is the team working on? Why, why are there so many of these stickies in this column where we have more work to do? Uh, you know, what are they? And when I told him, Hey, this is, uh, you know, we had like 15 reports that have to get done. Uh, you know, he described, Hey, let’s talk with the Product Owner cause we can only do five, you know, and cause I don’t have time for you guys to do this. It was an interesting dynamic that they didn’t realize what we were working on, the team was working on and when the management did because quite honestly, none of us wanted to work on those reports. So we were kind of grateful that we narrowed it down. But, but he understood, Hey, it takes how long to get them done. And we had 15, that’s, you know, you can figure out the timing. Um, again, it wasn’t a super agile way, but it was very visible. Uh, and I think the beginnings of getting us to, to a more an agile way of doing things.
Dan Neumann: [21:51] And that intentional practice is something that really doesn’t happen often enough. Whether it’s in software. I know I’ve alluded to my, my running habits, but you know, if you’re going to be a software developer, it’s not good enough just to keep cranking out the same code the same way you’ve always done it. You need to build new skills, build new mental muscle memory, I guess, if you will. So for sure that intentional practice is valuable. In a minute, Eric, I’m going to ask you about what you’ve been reading that has you inspired, but I also thought I’d take a second and plug that the next episode will be Sam Falco and Adam Ulery and there’ll be talking about tips for Scrum Masters. So that should be an episode that’ll be insightful. And as people may have noticed, Sam and I are trading off host duties a little bit, so neither of us intends to go anywhere. But the next episode will be Sam with Adam as a guest. Eric, what, uh, what are you reading? What’s got you inspired or thinking these days?
Eric Landes: [22:56] Nice. Well, um, because I do a lot of training, I always read Train From the Back of the Room. Um, so that’s kind of a standard that I always refer to, but a new book that, uh, actually my, my kids just got me reading is called the Color of Compromise and it is by Jemar Tisby. Um, it’s a look, uh, at really slavery and how, how that affected and especially how the Christian Church was involved with it, with it in America. And it’s from a different perspective than I have normally looked at that. So it’s very interesting book.
Dan Neumann: [23:38] That sounds quite thought provoking. And I guess for, for folks familiar with you, you’re a college age and graduated college. This is not a children’s book obviously based on the, uh, the subject matter. Okay. Yeah, it’s an adult children’s book, I guess. Yes. Okay. Well be curious to hear more about that. Uh, perhaps when we meet in person.
Eric Landes: [24:03] Sounds good. We’d love to talk about.
Dan Neumann: [24:05] Alright, until next time. Thanks for listening. Thanks for joining Eric.
Eric Landes: [24:11] Thanks Dan.
Outro: [24:13] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
