Everyone wants a culture of agility, but culture must be balanced with the ability to produce results. In this talk, we explore how to systematically introduce organizational changes that can get people to think, feel, behave, AND deliver with agility.
Video Transcript
How do I get resistors to be overcome? How do I get the culture to change over time to get it more adaptive, more responsive, more all these different things. If I get the systems right, I get the practices right? I create the space for the culture to emerge. And so my general belief is if I have a view of what this should look like and I design it so that I can deal with all of the various competing cultural attributes and all the various personalities and needs and everything, and I’m telling you can with Agile, if you open up your purview of what Agile is, that’s how you get to this point of being able to do a transformation, overcome resistance, change the culture over time.
Introduction
Awesome. Thanks guys. Yeah, so I’ve kind of always had this love hate idea relationship with culture as it relates to Agile. Lemme try to pay attention to clapping over there because it’s so many folks in Agile kind of start with this idea that Agile, adopting agile is a culture problem or it’s a mindset problem. And I think the reason why it feels that way is because it’s like we have a better way to do it and people are resistant and if they would just kind of open their minds and they just kind of see the light, then we could get them to move. So I run a company based out of Atlanta. I work all over the place though called Leading Agile, and we’ve been in the business of doing transformational change management over the last 14 years and I’ve worked in a lot of companies before that back into 2000 twos that were doing Agile. So through the last 20 years almost, I just have a really strong point of view and it’s a little bit contrarian I think to sometimes how we think about this stuff. So what I’m going to do, just in case anybody wants to get out of here after the first couple slides, I’m going to tell you kind of the end of the story and then I’m going to talk a lot in the middle and then I’m going to tell you the end of the story again. Okay.
Oh, I forgot my intro slides. So if anybody actually wants the deck, if I get all the way through all my slides, this will be up at the end. But you can text culture to 3, 3, 7, 7, 7 and you’ll get a link into the deck and you can download it so that way we don’t have to, you’re welcome to get contact information, but you guys can be self-Serve on this. That’s me. I’m not going to introduce myself again, but basically a little bit of my backstory, I never really got to do agile in the small professionally, I was never part of a scrum team. I kind of grew up in project management and I grew up in project management and really, really complex systems. So my was financial services and so you think financial services we were building on top of mainframes that did like a CH processing engines.
So sometimes I just call those legacy monoliths. I mean they’re just that big pile of code in the back that takes forever to try to change. But then we had front end systems and we had reporting engines and we had APIs and interfaces we were publishing out. And so when I first started getting my exposure to Agile from the project management world, all the literature I was reading back in 2005 was about how do you form small cross-functional teams? And so as I kind of developed my point of view, I went from that. I worked with version one for a little while. I remember back in the days when it was version one and Rally and Rally was up in Boulder and we were in Atlanta, that was kind of a fun time to be in the agile community. And all the clients that we were going into at version one had these incredibly complex systems.
And what I spent most of my time trying to was trying to figure out how to tweak version one to basically deal with the things that were kind of messed up in some of the organizations that we were working in. And so during that time probably worked with 200 different companies in various degrees of disarray, trying to figure out how to get them to do sprint planning and story points and burn down charts and all that kind of stuff in organizations that were just really, really not wired for it. Kind of like my mental model during that time as I was thinking about and what a lot of my writing was about was if I could, I was like king for a day in a company and I could change anything, what would I change to make agile really, really work? So most of the stuff that I write about is appropriate teaming strategies and governance models and change management and how do we measure it and how do we do just the transformation strategy around it. So that’s kind of like my bent.
3 Ways to Approach Agile Transformation
And so over the last 20 years I’ve kind of observed, there’s kind of like three takes on how I see and hear people talk about agile transformation. And the first take is idea of a practices based transformation. And so in a practices based transformation, it’s like we use Scrum, we hire scrum masters, we get a coach, teach people how to do sprint planning, daily standups reviews, retrospectives. Maybe if it’s a technically more oriented organization, maybe you have XP coaches and it’s test driven development and pair programming and things like that. And what kind of, to me, as I started breaking down what I saw some of the failure modes around that was this idea that it was like you think about how Scrum talks about it, if I have a scrum master, their job is to remove the impediments.
But what if the impediments are a 40-year-old mainframe engine that does thousands of aach H transactions a second? That’s a pretty big impediment to remove. What if the impediment is siloed org structures and things like that. What if the impediment is I have a three month release management cycle and I can’t deploy anything into production? So I kind of had this idea that if you go down to practices first, sometimes it works small organizations or teams within larger organizations, you can get that to work. But in these corporate monoliths that we’re working in really, really tough. And so I feel for anybody, any scrum masters in the room, anybody who’s doing a scrum master job, really, really hard job. It’s like the next gen of project management project management’s a thankless job too. I think being a scrum master can be a really, really hard job sometimes because you’re betting on the fact that if we start to do these things and the impediments show themselves that we can remove the impediments and sometimes the impediments are harder to remove than doing scrum in a funky way.
It’s easier to change Scrum than it is to change the impediments in the organization. I think that’s why a lot of practices first transformations fail. Then what we’re talking about here today is a culture first transformation. What I’m going to do is I’m going to take personality profiling and we’re going to break down a lot of cultural attributes by personality and it’s super fascinating topic to me. And so in a culture first transformation, it’s kind of like where I started. If we just get everybody to think the right way and to have the right mindset, then the magic will happen, right? We’ll get everybody to think and be agile and do agile and everything will be great. I dunno about you guys, I’ve never seen that kind of a transformation work either, right? Because there’s so many diverse interests in a company and so many different priorities and you bounce up against corporate governance, you bounce up against architectural standards, all kinds of different things that make a culture first transformation really, really tough.
So we took this approach that we call systems first. And so what a system means to me is how do we get encapsulated teams? How do we get a team-based organizational strategy when there’s dependencies between teams? How are we going to deal with them? How are we going to orchestrate dependencies across teams? How are we going to subordinate that up to some sort of enterprise level prioritization mechanism? How are we going to measure it? How are we going to control it? How are we going to make sure that the system is producing the things that we want? And so what my general belief is around this is that if you start with the systems, you understand your dependencies, you understand your teaming strategies, and you can do that in a more holistic way across the organization, then you can enable a transformation with the practices, whether it be Scrum or safe or less or whatever, XP.
Then you can enable the system, combine I left, combine out. You can enable the system with really solid practices and then you create a space for culture to emerge the culture you want. When people see an incremental and iterative development approach start to work, they can start to suspend disbelief and start to trust it. Okay, so anybody want to leave you guys? Hang with me for a little bit. Okay, cool.
What is an Agile Culture? (And Why You Should Care)
So, I’ve got a couple slides just to set the stage a little bit. So this is all kind of top of mind when I build back, I’m just like whatever comes to mind, I kind of do. So it’s like what is an agile culture and get ready. I’m going to ask you guys here in a minute. So a lot of the words that you guys talked about at the beginning are words that I use all the time When we tend to think of an agile culture, we want to create trust, we want to empower people and have them be able to take ownership.
We want a leadership team and a product organization that’s willing to respond to change and inspect and adapt, that kind of a thing. We want to be adaptive, we want our requirements to emerge because of course we don’t know everything. We want to create psychological safety for people. We want people to be able to come and feel good at work with the people that they’re working in and ultimately get better teamwork. Any other words come to mind for you guys when we think about culture in this context? Did I kind of nail it or at least hit it close enough? Okay, cool. So we kind have an idea of what we mean by culture and then so now we start to think about who might be responsible or have an influence over culture in an organization. Oh gosh, skipped over this slide. So why is that important?
Why are those attributes important? Well, we want to build the right products. We want to get fast feedback, we want attention to quality, we want early delivery, we want to be predictable. That was actually a lesson I learned talking to executives back in my version one days because I would come in with all this, Hey, we want to be able to respond to change and all this stuff. And most of the times people are like, I want you to be able to do what you say you’re going to do and be able to make ’em meet commitments. You guys encounter that because at the end of the day, the triple constraints are kind of a real thing. So agile looks at it a little bit differently. We say even project managers say that you’re supposed to be able to fix two and the third one floats.
Well, in an agile world it’s like we fix time and cost and we let scope vary as the project goes, right as we deal with reality. But anyway, there has to be some mechanism for being able to call back to the organization, say, well, what am I going to get for this multimillion dollar investment? We want efficiency, we want lower costs and we want innovation, we want to build the right products, we want to make sure that people are buying the things that we do. And so there’s kind of this jump that kind of says, well, if we build this culture then we’re going to get these things. And that’s a big leap in a lot of organizations that are really complicated and really heavy. I think in smaller organizations it’s more attainable, more directly. But in larger organizations that’s a big leap to think that if I empower people and let them decide that all of this goodness is going to happen, I can tell you there is evidence that it doesn’t always work that way because of the impediments, because of dependencies, things like that.
So this is the one I tried to cheat up to. So who’s responsible for an agile culture? Well, there’s a couple different people that are responsible for an agile culture. So leadership of course, we want them to embody the principles of agile. I think at the end of the day, often it starts with individuals and teams. We all have to individually be responsible for the kinds of cultures that we want to build. The one that I think is an interesting wild card is sometimes customers want things from us that are not particularly reasonable. Sometimes it’s partners, different organizations that have to integrate complex software solutions. And then the last is that the stuff in the organization, the governance models, audit and compliance, legal sales, all that stuff we have to come up. We have to figure out what their part is in an agile culture.
So this culture thing is so rich and complex to me that because it just impacts so many different parts of the organization that we have to fundamentally attend to.
4 Competing Views on Culture
So, this is what to me probably the first interesting insight of this talk. So about six or seven years ago when leading Agile started to grow, we started getting really into personality profiling and things like that because trying to anticipate and find patterns in what made a good consultant, what made a good coach, what made a good developer, what made a good leader. And what we were finding is that hiring people was a bit random in the early days. And so what we were trying to do is figure out a little bit of a methodology for doing that. And along the way I was working with a coach, like a professional development coach who turned me onto a really interesting personality assessment that we use tons internally and it’s kind of changed in my life, it’s changed my relationship with my kids, my relationship with other people in my life with my wife, all that kind of stuff.
So I think personality kind of matters and I’m going to tie that culture here in a second, but I want to just explain the model to you a little bit. This model is built on the same fundamental science as a disc assessment, but it has a really just interesting way of going about it. If you’re just curious, I don’t have any interest in this company. It’s called color code. Go to color code.com. And what is interesting about it is it’s very natural with just a little bit of practice to start to see how people show up and what they value and what they care about. And very simply, I don’t really have the axes on here, but you can kind of see ’em. It kind of puts you on a continuum. If I’m standing in front of the thing too much, I’ll try to just keep looking around, man.
I’ll get the clue here. So on the vertical axis is controlling and non-con controlling. You guys know anybody in your company’s have controlling personalities. So I am super high on the controlling personality. So that will explain a lot of this talk to you super high on the controlling side. And then the other side is non-con controlling horizontal axis is emotional versus logical, and what that implies is kind of a quadrant, a two by two. And so the emotionally controlling quadrant is around intimacy and connection. And when somebody says, well, you’re really emotionally controlling, that doesn’t sound like a good thing, but my wife is a dominant blue and it doesn’t mean that she’s a bad person or anything that’s on camera doesn’t mean she’s a bad person or anything. It means she desperately wants people to be okay. So it’s like intimacy, connection, that kind of stuff. Now where I fall is in the power quadrant logically controlling. And what that means is that I focus on, I mean all these things have dark sides and light sides of expression, but the healthy side of it is I want outcomes to be achieved. I want to make a difference If it’s in my company, I want to be profitable. If it’s on a client, I want them to improve their metrics. So to me, the power quadrant is a lot about getting things done and getting them done.
Then you get into some of the non-con controlling personality types and the emotional non-controlling, which is my secondary trait is around having fun and showing up and just having a good time. My middle son is primary yellow and he’s hilarious. He’s like a comedian in our house. Just makes everything more interesting and more fun. And just as kind of a funny aside, he can roast you like crazy and you’ll be laughing at yourself. He is just that personality. And then the lower right, which is my wife’s secondary quadrant is peace. So my wife wants intimacy, connection and peace. And so how peace tends to manifest itself is kind of being a rule follower. So when my kids were little or growing up, she would be like, well, you don’t speed because it’s against the law. You don’t do drugs because they’re illegal. You don’t drink because you’re not 21.
But what she’s really kind of concerned about is I want you to be safe and I want you to be okay. And she appeals to the rules to try to drive that. So most people that we’ve personality tested, I’d say all people to some varying degrees are mixes of different personalities and I just find it super interesting. So I’m sitting in meetings or coaching a team or coaching my team. I’m constantly listening for verbal cues that tell me where these folks land and what they prioritize for. And when I can do that, it’s kind of neat. I’ll talk to one person in the room, I’ll be like, we’re going to make this happen and you’re going to get these outcomes and this return on investment and everything, and then I go to you and I say, everybody’s going to love it and it’s going to be awesome and it’s going to create these great and you’re going to have a ton of fun and the rules are going to be super clear so you can start to think about speaking to a room or speaking to a collection of people or speaking to a company in terms of what they value and how they show up in terms of personal relationships and what they’re trying to get done.
Yes, well, everybody’s kind of a blend. So my son happens to be the one I said, who is dominant yellow? He’s secondary white, so he just got his doctorate, physical therapy. It’s perfect for him because there’s rules and procedures and he understands the science and he understands every little muscle in your shoulder and can tell you what’s wrong. And then he makes jokes and tries to teach you how to do things and then you go off and he just doesn’t, if you don’t do it, that’s on you. He’s not trying to control you, but he’s super smart. I’m not saying he’s illogical by any means. He just operates within a structured rule system, but that manifests for him in terms of he tells jokes and things like that. For me as a leader in my company, I say the red yellow personality type is like, I really want you to love it here, but if you don’t, I go work someplace else, it’s cool.
The red blue personality types, a lot of times project managers, a lot of female project managers will show up in this way and with a red blue personality type and I call that the you’re going to do it my way and it personality type. So it’s like there’s just interesting blends of people. There’s some people that we’ve tested that show up and they’re equal in all four quadrants and they’re like chameleons when they’re in the room, they can just adapt to anybody’s personality type. It’s super fascinating. I mean, you can go down the rabbit hole for days on this stuff. So I teach you guys this to start to think about culture and what people value in a culture. And so somebody who’s in the blue quadrant, they’re going to show up and identify culture as things like trust, empowerment, safety, appreciation and connection. Somebody who’s read results, accountability, commitment, ownership, performance, somebody who’s yellow, recognition, creativity, flexibility, collaboration, fun and white is balanced, clear expectations, harmony, inclusion, autonomy, things like that.
And it’s really fascinating. I can almost tell by reading somebody’s title of their topic or their talk format or the things they’re focusing on, I can go, oh, they’re super yellow. Anybody that does games in the talk, you can almost guarantee they’re going to be on the yellow spectrum. Anybody who’s talking about culture or agile ecosystems from the perspective of teamwork and psychological safety, I almost always just go, okay, they’re blue. So what I generally think of is that companies that are really successful with this is that they can attend to all the different cultural aspects. And so it’s like if you’re a small company, I mean companies definitely bias towards a certain thing. So if I were going to describe my company, we are absolutely a red yellow company, but we have blue whites that work with us and yellow whites and red blues and all kinds of things.
I mean, you can’t grow to any scale and have, nor would you probably want to have everybody be the same personality type or the same value system. So we try to create inclusive systems that are where everybody can be successful and get something that they want out of the system. So ideally you want to attend to all the different types. So we want all this stuff to be able to be present in our companies at the same time. Now, it was actually a couple slides later, but I think I mentioned, I did this talk in Detroit yesterday at the Agile and Beyond Conference, and this guy we’re talking about systems first and we talked about this different stuff and he raised his hand. He goes, well, I have all the systems in place but it’s still not working. And I said, well, there might be a part of the system that appeals to some personality types, but the other people in the organization are experiencing that different.
Imagine if I’m an agile coach and I come in and I teach you Scrum and we’re playing games and the CFO’s like, well, when am I going to get my project? Or what’s the return on investment? That kind of a thing. Or I’m white and yellow, but then these people are over here, but I don’t know anybody on my team. I don’t feel connected to the people I work with. So if nothing else, we could hard stop here for just a minute and go. As you think about culture in your organizations, think about it through a lens of people are fundamentally different and people value different things in a culture. And yes, certain companies will probably bias more towards one or the other or two or three of ’em or something like that. But I would suggest that the people that show up as resistors to change probably are not getting something that they need to feel safe.
It’s a funny, in our community, a lot of times people talk about psychological safety. It creates psychological safety for me, making money and doing things on time, I feel incredibly unsafe if we’re losing money or clients aren’t being delivered for. But within that, we want to create an ecosystem where people like coming to work and we have fun and we do cool things and people know or are friends with the people they work with, and the rules have to be pretty clear. So the idea is to try to figure out if we can strike some balance.
Agile Delivery Systems and Culture
So, this next sequence of slides, I actually went out and I did this talk for a telecom in Belgium, and I actually added these slides for them and then decided to leave it in because I thought it was interesting. They were really, you think about Norwegians, right?
Culture’s kind of a big deal. There’s different culture in Belgium and Sweden and the Netherlands than there is oftentimes in the United States. And so they were heavily indexing on culture. And so I was trying to make this point, I stole this from Mike Cohen and I know he lives in this town. I was hoping he didn’t come and see me steal his graphic, but I’ve been using it for years with attribution. So some Mike Cohen graphic, right? So if I think about Scrum and think about Scrum and how it satisfies the different parts when done well, the basics of Scrum, you strip away all the ceremonies and everything. I have a complete cross-functional team of people that operate off of a really clear backlog that can produce a working test and increment software at the end of every sprint. It’s kind of like Scrum stripped to its core.
You’d think, okay, cool. So that structure, so I’m tying back to the first thing. That structure affords me a bunch of stuff. If I have a team that can stay together that’s operating off of a clear backlog that can produce a working tested increment, then the red in me can say, well, I know the size of my backlog, I know the velocity of the team. I know I got to a definition of done. So I can start to anticipate either when I run out of time, how much scope I have left or what scope things I need to take out. Or I can say, this is how many sprints it’s going to take to deliver the project. It creates a ton of safety for me as a red, right? Somebody who’s a white says, okay, cool. I know I show up on Monday morning, I do sprint planning.
We break down stories, we do points. We do daily standups every day. We do reviews and retrospectives and we do burn down charts. Everything’s good. I know the rules of the game. Now within that team that stays together, I have a group of six or eight people that can start to get to know each other, can start to create work with the product owner, start to understand what they’re trying to do. And if you happen to be yellow, then maybe some games and stuff are pretty cool. We do some sticky notes on the wall and we do some fun retrospective stuff and maybe we go out for team outings and things like that and world’s good. So now you start to think about you break the structure of Scrum, I have people matrixed into the team. I don’t know the size of my backlog. I can’t deliver something of value every two weeks.
And somebody shows up and says, okay, well we’re going to play games. Or somebody says, I’m going to show up an over index on the rules, or I’m going to come to you because I have no other ability to control and put you on a death march. And it doesn’t look anything like scro. It looks more like waterfall. So you start to see how when I don’t get the fundamental elements of Scrum in order, I don’t create the space for everybody to get what they need out of the system psychologically saying it’s interesting. So for these guys in Belgium, what I did is I started thinking through other ones. And so I picked on Spotify a little bit and I picked on safe a little bit. We’ll get to safe here in a second. Anybody use Spotify? Is that a thing anymore? Yeah. Cool. Do you guys use anything more than the word squad?
Tribe, guild, chapter? I’m, I’m being sarcastic a little bit. Those words have totally permeated, but I don’t see anybody actually really, really trying to pull this off. At the end of the day, as you start to scale up these methodologies, it’s just all fundamentally shades of the same thing. To me, a squad is basically a scrum team at the end of the day. A tribe is a collection of scrum teams. Think of it as like a release train or something like that. Chapters can be things like part of the management hierarchy. Guilds can be things like communities of practice, that kind of stuff. So what we’re doing is we’re creating at scale. If I’ve got cross-functional teams at the squad level, I get all the benefits, all the cultural benefits of Scrum, but then people start to feel disconnected from leadership or they start feeling disconnected from other people that are doing the same types of skill sets. If I don’t have a tribe or some collection of teams that can organize to deliver something, well then I’m just introducing a bunch of chaos and everybody’s doing their own thing. So as we start to think about implementing a methodology from a structural perspective, from a practices perspective, we can start to think about how the elements of the methodology are contributing to the kinds of cultural values that we want to have within the organization.
I love that diagram. That’s awesome. Safe is not as complicated as people think it is. Does anybody think safe’s too heavyweight to that kind of stuff? Oh, that’s a few. That’s cool. Raise your hand. Yeah, it’s cool. So I think back, I’m old enough at this stage in my life to remember implementing rep processes and of course waterfall and things like that. And most methodologies, I know there’s some confusion about this in the safe world, but most methodologies were kind of built PMI was kind of built this way. PMBOK was kind of built this way. It’s not designed to be taken in its entirety. It’s designed to be scaled and tailored to the unique parts of your organization. At the end of the day, what safe fundamentally is, it’s a way of orchestrating across multiple teams that all have to integrate to go deliver something together.
So there’s kind of a base pattern. I actually kind of like this base pattern. We have scrum teams really at the execution level, we have some sort of orchestration mechanism that rides on top of that. We have some view of the portfolio so we understand what our priorities are. We tie up to some sort of corporate goal or objective, an OKR or KPI, something like that because at the end of the day, the stuff that I do at the lowest level has to get up to the top and help us achieve our corporate goals. So you could look at something like safe through this lens. People will oftentimes, somewhat cynically say safe really is for the managers. So they can pretend they’re doing the stuff they’ve always been doing, but they can call it safe. Now they have an agile framework to put around it, but in reality there is a way of thinking about safe and implementing safe that creates the connection at each of these levels.
We have the opportunity for fun. There’s still a whole lot of rules, and if safe is done really, really well, then we get the business outcomes that we want. And so it’s just a way of addressing all of the concerns. But if you happen to be an agileists that believes in just small teams and empowerment and things like that, you see where these cultural words start to come in, we’re probably missing some of the cultural values and goals of the rest of the organization. So where I’m getting ready to go here is we’re going to strip down into some of the fundamentals and we’re going to start thinking about this is my way of sneaking a little bit of a transformation, talk into a culture talk. But I think it’s important because there’s another lens to look at this through. If I go into an agile transformation, my cultural values in an agile transformation are maybe connection and fun and how team members feel, that’s cool, that’s all valid stuff, but it might not satisfy the people who are white and are red.
So again, as we even think about transformation, not just the system of delivery that we’re moving towards, but the way that we’re actually going to transform the organization and the clarity that that needs to provide for people that are spending the money to do that, we can think about culture through a transformation lens as well.
What Gets in the Way of Culture Change?
And so, before I get there, we have talked about dependencies for just a second. Anybody have dependencies in their organization? Okay, come on. Seriously. Really? Yeah, just a few. Do you guys manage them explicitly or do you trust that the teams will self-organize them?
Or both, and that’s probably true to some degree, but to me, when I think of the barriers to transformation, the barriers to agile, the barriers to creating the cultural conditions that we want to create, almost everything that gets in the way of doing what we want to do is because of the dependencies. Why can’t I form a complete cross-functional team? Well, I don’t have enough people of the right kind of skillset. Well, that’s a dependency. I have a legacy technical architecture that won’t let me deliver incrementally and iteratively. That’s a dependency. I have three or four systems that all have to work together to create some sort of integrated deliverable that’s a dependency, right? Dependencies are everywhere. And so too much work in processes kind of dependency. I have to get this done before I can get this done before I can get this done.
Dependencies are just absolutely everywhere. And dependencies to me are fundamentally what get in the way of creating the teaming strategies that give us really the agile secret sauce. Almost everything that we mess up in Agile is some form of capitulation to a dependency we can’t resolve. And once you see it through that lens, it’s hard to unsee. Once you see the world through this problem of dependencies, it’s like everything starts to light up as to why we can’t kind of create the organizations that we want to create. And we’re going to unpack that a little bit.
The Role of Organizational Structure in Culture Change
So, what we fundamentally have to do is we have to organize for collaboration, but more generally, we have to organize for the cultural attributes that we want to prioritize for in our companies because the system and the practices in my worldview is what creates the space for the culture we want and it gets everybody what they want.
So the fundamental patterns, I’m not a methodology guy per se. We work with companies that do safe. We work with companies that do Scrum with Kanban with large scale Scrum xp, DevOps, you name it. We play in that space. But what I believe is super important is that you have to understand, excuse me, what’s really going on? What are the fundamental, call it a reference architecture versus a reference implementation up underneath Safe and Scrum And last, there’s is a common reference architecture that becomes manifest in different reference implementations depending upon what you’re trying to accomplish in your organization. You could say that SAFe is a reference architecture that is fully built out with a implementation model. And if you understand the reference architecture is safe and you understand how the implementation model, then you can start stripping down parts of safe and you can start extracting the pieces that you actually need.
Large scale scrums kind of like that too. Beautiful reference architecture up under large scale Scrum, but most organizations are not dependency free enough to actually implement large scale Scrum, right? Less so to me, the fundamental things to be aware of as we start to organize for the culture we want is that there’s different kinds of teams that do different things. And so the base pattern that I kind of think about a lot is oftentimes if we’re going to get Scrum teams that provide services to other Scrum teams like an API or a database, or it could be a marketing or a sales or a legal or something like that, you can think of services in lots of different ways. All those services teams can absolutely do Scrum or Kanban, whatever. All the same rules apply. We have our product that we build is a product that is consumed by other parts of the organization.
The service that we offer is a service that is consumed by the other parts of the organization. We need to encapsulate that team, create all the conditions due to Scrum. They can run off a backlog, they can produce a working test and increment of product or software or service at the end of every sprint. So we want to recognize the things that are common and shared across the organization, paying attention to time. Okay, cool. Product teams in this model are just the things that consume stuff from services. And so the really simple example, back from my financial services day, if I have an online banking app on my phone, you guarantee that’s making a service call most likely to a mainframe somewhere. And so anything that I want to do of value probably requires user stories there. And it probably requires user stories here. If I’m going to get that feature out, then these things kind of need to be sequenced and timed together.
Then oftentimes above that is something like you could call that a value stream team or a business capability team or something like that. This is where I’m stitching multiple teams together and that work has to be orchestrated across the whole thing. But that’s a team, that’s a team that can be a team. And then you have a portfolio team, somebody that does the macro level prioritization for the organization, and that can be a team. All the same rules apply teams all the way down. You guys ever heard that expression? Elephants all the way down. It’s actually a thing. Go look it up, I’m telling you. But it’s like teams all the way down from the top all the way down to the work surface. But they all have different roles and they get kind of structured something like this, a little bit of a pyramid, but the unit of value, the unit of work is not the individual.
This is an org structure or hierarchy. It’s a relationship between teams. And so one word that I know is not incredibly popular in the agile world, so I said I’m a bit of a contrarian, is that we typically will put Kanban based governance systems over top of multiple teams to do that orchestration work. And back in the day, back when I was at version one, I wrote a blog post that said, Kanban is just waterfall with smaller batches. It’s kind of true, you think, right? And David Anderson, the guy who invented Kanban, he actually messaged me and he goes, I guess it is probably 15 years ago. So it surely wasn’t like instant messenger. It was probably a text or an email or something like that. And he goes, I really wanted to be mad at you for your post, but it was actually right. So that was a bit of an acquiescence.
If anybody knows David, that was a bit win for me. So basically when I think of governance, it’s like how do I get the big things broken into small things so that as multiple teams deliver them, I start releasing things into market faster. Really hard to do in a complex environment if we’re just talking about Scrum and we’re not managing the dependencies that exist and we haven’t broken the dependencies. So we have to start putting in some sort of construct that integrates stories, something that prioritizes and does some initial decomposition. Oftentimes there’s a strategy tier where corporate governance lives, and we go often in our world. We say, well, that’s not agile. And I go, well, what is agile? Is agile, scrum is agile, safe is agile. This is agile mindset. Is it values? Well, agile is all those things. So at the end of the day, what we fundamentally want out of Agile is you want to be able to efficiently put small things in market so our customers can buy them and give this feedback fair.
So when you look at Agile that broadly there’s a lot of agile. You can do it every level of the organization, not just at the scrum tier. The reason why this matters, and I’m just going to drive this point home, is because what we value here often in a large organization is not what is valued up here. Leaders are often very willing to delegate if they have a reliable system they can delegate into. They want you to have fun, they want you to be connected, they want you to have a best friend at work. They want to know what the rules are, but at the end of the day, the system has to produce the desired outcome or they’re going to stop putting money in it, or they’re going to stop having money to put in it because they won’t be selling things and they’ll be going out of business.
So I get back into my red, yellow, white, blue thing, and you can have red, yellow, white, blue at every one of these levels. But I think sometimes in the agile world, we under index on the red side, the actual producing of stuff side. And again, where I think we suspend disbelief, and so we just kind of mess up the methodology a little bit is back to the dependency thing. So it’s kind of like I have a general rule. When we’re coaching organizations, you either have to break dependencies and truly let all these teams operate independently or in the presence of dependencies, you have to orchestrate them. I will admit you will be more agile if you can figure out how to break everything up into two or three teams. But if that’s not your reality, you need some way of being agile at the top that enables us to flow work through the aggregate system, not just at the story point system.
I can’t tell you how many people call us and the first thing they say is scrums working great, but my leaders aren’t getting what they need. Or I’m doing scrum awesome, but it’s not working. I’m like, why? Right? Well, systems, governance, structure metrics, then the personality type gets laid on top of that. So then that brings me into, if the problem is this big and I have to hit, oh, there’s a metric slide here in a second. So backlog, size, velocity, burn down. But as we start to get up here, things like cycle time defects escaped up here, we’re starting to think about time cost, scope, value, ROI, capitalization, things like that. These are real things that our leaders are dealing with. So the metrics matter.
Iterative and Incremental Change Patterns
So, then I start to explore incremental and change patterns. So in what we do, we think about a system of delivery, and then I think about a system of transformation. So how are we going to create safety for leaders to start to want to do the change? Well, we have to incrementally and iteratively transform the organization. And so approaches like going and train everybody running through leadership workshops, while all valuable I find insufficient as far as change goes, because again, it doesn’t deal with all the aspects of the system and it doesn’t address all of the cultural desires in the organization. So again, we’re always hunting, getting red, yellow, blue, and I almost said green, white. There you go. Okay, cool. Y
You’re taken an incremental iterative change model approach, you have to run two systems in parallel. One for leadership and what they’re accustomed to.
And hold that thought for just a second. I actually have a slide on that in a little bit, but I don’t think of it as building layers. I think about as building vertical slices and the metaphor to software is spot on because a lot of times we have, we’ll build a database, we’ll build the backend or we’ll build the middleware, we’ll build the front end or we’ll build this, right? And we think about our agile teams and layers, and you can do that, right? You could form a scrum team at this level and then you could orchestrate, but that’s the least desirable way. And sometimes we find ourselves in the midst of transformations where we are doing a lot of team stuff before we can do the orchestration and before we can get to the top stuff, it all varies, but ideally you want a slice of the organization from the top to the bottom.
But I will do, we did a mega transformation over the last five years and there was an interesting approach we had to take to deal with just the thing that you’re talking about. Okay, so I’m just kind of doubling down on this idea that delivery and delivery teams are only part of what we have to try to figure out how to accomplish. We have to create a home for product management, strategy, articulation, budgeting, and funding technology and architecture compliance and controls. Our talent organizations have to be brought along. Our leadership has to be brought along. They’re all stakeholders in this broader ecosystem, and they all have different personalities and different concerns, and all of that stuff has to be addressed. So we fundamentally have to think more broadly across the whole stack. There’s a story about blind men and elephant. I’ve heard, I got introduced to it through the agile community, and it’s basically you have three blind men and it’s an old Indian parable and they’re all describing an elephant and someone’s touching its trunk, says it’s like a snake.
The other one’s touching its leg, says it’s like a tree trunk. The other one’s touching its ear, says it’s like a palm frond. I think a lot of times is that we’re dealing with an aspect of the problem, and because we’re dealing with the small aspect of the problem, we’re not dealing with the entirety of the problem and the entirety of the problem for a truly agile enterprise, a truly agile organization or department or work group or whatever, is that we get all these pieces to integrate simultaneously. And so one of the coolest little things that I did is, and some of my other talks, I actually spell this out pretty explicitly, but we created our own little two by two, and we talk about predictability versus adaptability, emergent requirements, things that change all the time versus requirements where people think that they know what they’re supposed to build.
And the cool thing about it’s that we articulated this little quadrant system and we created this little base camp metaphor and expeditions all the climbers here from Colorado. We’ll probably appreciate some of that little fourteener things going on here. And that was kind of the metaphor that we drew from. And the idea was is that, oh, the reason why I thought it was cool is because Jeff Sutherland heard it and actually used it in one of his presentations before, and I thought that was super cool when the guys that you learn from will take some of your stuff and use it with attribution of course. But that was actually cool. I was a little highlight of my career. So what we started to think about was it’s really hard to go from where you are today into a lean startup totally emergent model over time.
So what we first kind of hypothesized was a more iterative approach to transformation. And for us that meant let’s get the system predictable. Let’s get the reds out of our hair for a little bit. Let’s get some of the white stuff put into place. Then we can start figuring out how to reduce batch size and start to deliver more frequently using teaming strategies. So the yellows and the blues are getting what they want out of the system. Then we start to break dependencies so we can really, really start to take off because the more encapsulation, the less orchestration that I have to do, I’m creating more opportunity for those teams to operate autonomously. And then if I can get the teams broken up, then I can start to think about team-based funding. And now I have a team that stays together that’s responsible for a long-lived product.
I can fund that long lived product. Then I get the opportunity to start engaging directly with customers and start getting really super innovative. But again, it’s back to the dependencies. These are kind of compensating controls, not as agile as I would like to be, but I get the stuff going. I get again, the reds and the yellows out of my hair for a little, or the reds and the whites out of my hair for a little bit. I start to break dependencies between the different teams, and then I can start to really accelerate some of the other aspects of the transformation. But to your question, and the largest transformation we’ve ever been a part of was 13,000 people, and we could basically take it up to the first two levels just systematically across all 13,000 people. But we had to create almost like I called it like an abstraction layer, because the corporate governance wasn’t going to change right out of the gate.
There’s not enough safety in the system for the financial controls and the audit controls for them to say, okay, here’s just a pile of money. Go invent some stuff. So what we did is we got the 13,000 or most of ’em into a place where they could reliably and predictably deliver in small batches to where they could get feedback, they could make and meet commitments. They could do what they say they were going to do using traditional agile, but also governed with Kanban governance processes and things like that. And then we came back and we started hitting the governance stuff because once the organization is at critical mass and you start to think about flipping it to different corporate structures, then we start, the organization has a trustworthy system it can delegate into. They get more comfortable going from an annual funding cycle to maybe a three month funding cycle because they know they can make smaller bets and they know they get more opportunity to change as the market changes, the macroeconomic conditions changes.
Then we did this step, which was super fascinating because one of the things that I think is a challenge when we start talking about value streams in large organizations is that value streams are often not encapsulated. The value streams run through common business capabilities. Well, so anytime I have basically a dependency, I have something that intersects, I create a constraint in the system, I create bottlenecks in the system. So we had actually organized this gigantic organization into a business capability aligned model, started measuring where all the dependencies are. We couldn’t break all the dependencies, but we could see where decisions had to go all the way up and all the way back down, right? Super inefficient. And that starts to guide, if I’m going to do a reorganization, let’s group things together where the dependencies are strong. Let’s push the dependencies lower in the organization.
One of the things I say about Scrum a lot, which I think is a hundred percent true if you have a single team, that value stream from concept to cash is analysis, design, build, test, deploy, basically, right? And what Scrum really fundamentally did is it said, we’re going to take that entire value stream, we’re going to wrap it into a team, and we’re going to let it self-organize and manage that value stream independently. What Safe did is it said, okay, value streams span teams, so we’re going to fundamentally organize around the value stream and start delivering and release trains and do big room planning and all that kind of stuff. It was a cool evolution of it, but the problem with safe is when you get past that 150 people or so, and now I’ve got dependencies outside of that value stream, how do I orchestrate those? So your question was great. Sometimes you’ve got to get it working enough to where the organization trusts it, and then you start tackling the corporate governance stuff here I’m maybe funding teams or work groups or parts of the product maybe here now I can start to think about having persistent products, persistent business capabilities as an organization. When you get the organization broken up small like that, that’s when you really get the opportunity to sense and disrupt in the marketplace place. Okay. Yeah. How
Audience
Did they measure? Did the top just let the bottom go as far as measurements go?
Well, so what I said abstraction layer. So I learned little trick back in my project management days. When I first started getting introduced to Agile, we had no control of the PMO, no control of audit and compliance, no control of anything. So I could actually out project manage all the other project managers on my projects using Agile, but it was a very strict agile, it was like size of backlogs. We understood constraints in the system. I just read David Anderson’s early book on agile management had read Eli Gold Rats, the goal. And so what we would do is we would deliver in an agile way, but present it to the organization as if it was a project plan. So we played by the rules of the organization, but we delivered against the rules in a more agile small batch kind of way. So I think of it as there’s an abstraction layer and the organization will often, again, these are gigantic.
This does not typically happen in a two to 300 person organization. As you start to get into 1500 to 5,000, then you start to get really distinct things. So what my general guidance is, is transform the organization underneath, put the abstraction layers in, and then once the organization’s at critical mass and most of the folks are doing things in an agile way, it creates more optionality from a leadership team perspective that you can begin to start to lean into. And so just so I don’t make this a transformation talk instead of a culture talk, I mean if you look at it through that lens, I was talking about if I’m a yellow blue biased analyst down here, how is this ever going to change? But if I can start to say, okay, we value yellow, blue, but we’re going to wrap it in some really, really crisp, clean, red, white, we’re going to manage our dependencies proactively until we can break them, cool. Then we can start influencing the rest of the enterprise. But it requires a bigger view of what we’re trying to do. And so in our world, we call those vertical slices, expeditions, summits kind of deal with all the other stuff around it. For the most part. That’s what I’m trying to communicate here.
The Leading Indicator of a Balanced Culture
So now, back to where we started.
When you guys go into your organizations and you’re trying to lead change and you’re trying to approach this, I’ll go back to that comment that guy made. I got all the systems, but I still have resistors. How do I get resistors to be overcome? How do I get the culture to change over time to get it more adaptive, more responsive, more all these different things. I’m a big believer that practices are never going to get us there. I’m a big believer that leading with culture. Now, again, I get in trouble and I’ve had some customers tell me, I love your view on culture, Mike. And I’m like, I never talk about culture. I just talk about systems and practices. But some people made the hop before I did. If I get the systems, I get the practices. I create the space for the culture to emerge.
And so my general belief is if I have a view of what this should look like and I design it so that I can deal with all of the various competing cultural attributes and all the various personalities and needs and everything, and I’m telling you can with Agile, if you open up your purview of what Agile is, that’s how you get to this point. Being able to do a transformation, overcome resistance, change the culture over time. Okay, cool. So I got through it. Awesome. Thanks for the five minute warning. Okay, we’ll do questions here in a second. That’s the text. If you want to text it again and I’ll just leave that up there in case any, yeah, what do you got, Jess?
Q&A – Skills and Experience
Well, so it’s interesting, right? So skills are kind of different, right? Skills and experience are kind of different. I would suggest that when somebody is squarely within their skills wheelhouse and they’re comfortable and they’re doing a job that they’re very experienced to do, most people operate pretty along type.
I think people can expand their type when they’re really comfortable in their type. They can be more chameleons. But it’s a little bit like some of the personality tests show like, okay, this is how I operate normally, this operate under stress. There’s a lot of people are complex, and I’m not saying that this labels any, I’m not even saying it’s universally right? I don’t think disc is right. I don’t think Myers-Briggs is totally right, but it’s just a pattern. It’s just a way of thinking about it. But I will tell you, I can show up blue all day long. Well, I say I can show up blue for three or four hours and then I’m kind of done. I’m done being blue, right? My wife can show up red for 15, 20 minutes, but then she’s done being red. So again, anytime you try to categorize human beings, you get into trouble.
So, I’m not saying this is absolutely right. Just use it as a thinking tool. Even if you take my little personality profile assessment out of it and you don’t want to use that, just recognize that across those color abstractions, there are people who value different things. And to that guy’s question in Detroit yesterday, I think I’ve got everything right? And I still have resistors. It’s like they’re not getting something that they need out of it. Now granted, there’s a dark side of that too. Sometimes what they want is power and control. They want to build an empire they’re doing. So there is that, but if I think it was Esther Derby, or maybe it was Diana Larson who said something one time, let’s assume that nobody’s evil if we just assume nobody’s evil and everybody wants the right thing for the company, they just have differing ways of thinking about it, different ways of going about it, different views of what they think is right. Then we give them that grace and regardless of color code or whatever, and we start to realize what are they not getting out of the system? What things create safety for them that they’re not getting? And is there some way I could use Agile to give them more of what they need so they’ll get out of my way. I’m just kidding. That’s the red in me coming out. So anything else? Yes, sir. Yeah, I mean, again, I’ve been consulting in my company for 14 years. I’ve been in this for about 20 at this point.
It’s like I try to take the whole metaphor of bad practices, bad this out, and it’s like we have to come up with something that helps us deliver in small batches, gets fast feedback, put things in market, sell it for money. I mean, that’s kind of like the reason the company’s in business. And so in a long-term consulting engagement, there’s so much work that has to be done to align people. We take those expeditions, we’ll do vertical slices, and it’s like sometimes you got to prove it to me first. So it’s not a line, it’s loops. Right. Just like everything we do, it’s all loops and circles and stuff like that. Okay. I’m getting the hook now. Thank you. Appreciate it. Thanks for coming, guys. I really appreciate you having me.
