Let's talk about design. No, I'm not talking about UI/UX design or home design or blueprints or anything like that. I'm talking about organizational design. How does the design of your organization impact your product, and how well does it implement the ability to build the product that you hopefully want to build?
Today I would like to talk about that organizational design and share with you a story of a real life customer. So instead of lecturing to you, I thought I would tell a story.
The Costco Checkout Challenge: A Real-World Example
Working with a retailer - and we'll just say it's like a Costco, Walmart, Tesco, wherever you are in the world, just think of some big retailer that can do just about anything or sell just about anything.
Now, the goal of let's say like Costco - any of y'all that have been to Costco, I don't know if you've suffered this same problem. I'll go to Costco, I'll walk in and I love Costco by the way, and I look around and there's nobody at the checkout counter. It's like, great, I'm going to breeze through all of this, get everything that I need and check out. But ultimately what happens is when I get my turn to checkout, the line's long again. Does that ever happen to y'all? Maybe it's just me.
But at any rate, imagine you're the general manager at Costco and your goal is to create an awesome customer experience, not only in the way of the products that you sell and the organization of the store, but also how the customers can flow through the checkout. They have a lot of checks and balances at Costco, and that's great. You got to buy your stuff, then you got to check out and they check your receipt at the store and all that.
But just imagine you're the general manager and you want to make that experience as seamless as possible.
The Bulk Shopping Problem
Now, the problem we have in a Costco is they sell bulk wholesale type goods. And so what'll happen is you'll buy a loaf of bread and you'll get to the checkout counter and next thing you know, they're like, "Oh, sir, you actually get two loaves of bread." And so then you have to pause the line and go grab another loaf of bread, and it just becomes this disaster with everybody kind of going through that. You've got cracked eggs, you need more toilet paper. You get two things with that.
So the general manager looks at that, and I had a real life scenario of this before where the general manager was like, "Hey, at the checkout counter, it would be really cool if in the point of sale system when you scan and the product comes up, let's say the loaves of bread, and they say, 'Well, you only got one here. You actually get two,' it would tell you the actual shelf, the aisle and the shelf that that bread is on so that they can send a runner and say, 'Go to aisle 12, shelf three and get another bread of this brand,' and then we can continue checking out."
So if they did that across all of the checkout counters and had little runners that could go directly to the shelf and not hunt for it, then I think it would go a lot smoother. So the general manager's thinking about this.
How This Applies to Agile Organizations
So now let's go into how does this apply to Agile? Well, at some point, Costco or whoever this customer might be has an IT technology group - the people that build the systems that support Costco and their warehouse distribution, finance and accounting and all that good stuff. And so he finally contacts the IT group and let's say they're trying to practice a process like Scrum, which would advocate for cross-functional teams that are working in small iterations, trying to get a usable product increment delivered so we can inspect it.
So he contacts them and says, "Hey, I've got a great idea for this point of sale system." And he describes the feature. You scan it, it comes up, it shows you the shelf, the aisle, how much is on hand. Seems like a pretty quick thing to integrate into the point of sale system.
The Organizational Design Problem Unfolds
So at any rate, the project manager or whoever takes that call says, "That sounds like a great idea, general manager, let's go and talk to platform services." So Costco or whoever this customer is has a platform services team, and the general manager describes the problem to that person who's kind of over the platform engineering. They're like, "Oh my gosh, that's a great idea. We would love to be able to accommodate you on that." And they're really excited about it.
So what I'm getting to here is: how has this retailer organized teams and backlogs to minimize dependencies and bottlenecks across the whole organization?
The "Buy N Large" Company Structure
So I'm going to give you an example of this, and just for the sake of an argument here, we're going to call this the "Buy N Large" company. So Buy N Large company, I basically stole this from WALL-E, if you've ever seen that movie before. And we're going to talk about Buy N Large, and what's going to happen here is that they're going to shepherd this general manager through the process.
They say, "Okay, well we've got to talk to the enterprise platform team." The enterprise platform team will say, "That's a great idea." They usually have quite a few people. They support just about everything there is in the organization, and they are excited about that feature. So they place it about number three in this product backlog. Now mind you, they're practicing Scrum. So they have these product groups, they have teams of people working on this backlog.
The Dependency Chain Nightmare
So enterprise platform team is excited about that, but the project manager says, or the product owner, I guess if we're practicing Scrum for enterprise platform says, "Hey, it's a great idea, but you're going to have to go talk to the payment processing team." The payment processing team handles all of the integration between the inventory and what's on hand. So we can surface that into the point of sale systems, but we're going to have to go talk to the payment processing team.
So we march on over to the product owner of the payment processing team, and they say things like, "That's a great idea, but we got a lot of stuff ahead of you on that related to actual payments. So we'll get down to it maybe in the next two or three quarters." And now we're feeling a little deflated. General manager's not too excited about their feature anymore, but they actually say, "You're going to have to go talk to the database team."
And the database team is going to have to make some changes before we can do it. Now, I'm a database person by technology trade, and usually this is a small group of people, highly specialized, three or four maybe people. That's all there is. And every change we have to do kind of comes through the database team. If it's related to data, guess what happens when we go to the product owner of the data team? "We love that idea, but we're just too busy. That's going to go in the bottom of the list. We really can't tell you when that's going to be done."
They also say, "You're going to have to go talk to the active record team. You're going to have to talk to the Salesforce team." And Salesforce team is busy servicing finance, accounting, inventory, all these other things.
The Root of the Problem
So my point to you here is highlighting this idea that the general manager had a really cool idea. He was trying to really help his customers, but the technology group was so focused on the applications and they designed their teams around the layers of the product or the applications, the components - which now require the people who have these ideas to jump through hoops to finally get a feature deployed out to the point of sale team.
So when I mentioned organizational design, what I'm really referring to is: have we organized teams and backlogs to minimize dependencies and bottlenecks?
Why Traditional Team Structure Fails Agile
I love Scrum, but you're only going to be so good in your scrum team if you're handing off components to other teams. You're going to find problems much later in the process. You're really just building inventory. And anybody that's in retail knows we don't want a bunch of inventory sitting around. Now in software, it's really dangerous because we don't see it as bad, and it comes back to bite us infinitely when it goes bad.
The Solution: Product-Focused Organizational Design
So what I want to talk about now is, okay, well let's say they hire a consultant or a coach in Agile and they say, "Hey, how would we handle organizational design?" So we would come in and say, "Well, who are your customers? Who are your stakeholders? Who are you building products for?"
And what often they'll say is, "We don't build products. We're Costco, or we're Walmart or whatever - our product is retail." It's like, "Yeah, but your IT technology group, they build products." So who are your common stakeholders that could share a vision and align themselves on the infinite list of priorities with a finite team?
Identifying Product Groups
So we would talk about that and we say, "Well, we have an e-commerce product where we try to merchandise things and people can sign on membership rewards. We have the point of sales store systems, we have the inventory warehouse distribution systems, we have finance and accounting, HR, corporate communication, maybe even some internal IT like data center type team."
And so what we would want to do is to align the product groups around as much of the common stakeholders as we could and as much of the large amount of work that they have. Obviously if HR, corporate communication, finance and accounting didn't have enough work to foster a few teams, we'd have to put them together on one team, but at least they weren't so far divergent on their stakeholder needs. They could probably do that.
But if you try to do something like that, how often are all those stakeholders going to agree on the top priorities? So we would want to have one product backlog per product group as it would be, and then we can start practicing Scrum in that case.
The Better Structure
And so then we could say, "Well, there's multiple teams per backlog, and there could be one product owner, one scrum master, things like that." And that way those common stakeholders could align themselves on the priorities. And then we could feed those into multiple teams that are sharing a common cadence, a common definition of done, common estimating technique, and also the highly specialized shared people within that product group. And we would typically move a little bit faster.
How the Story Changes with Better Design
So now if we replay how that general manager would go through the process, if we had a better organizational design, then we could say, "You need to go see the point of sales product owner." And so they would go to the point of sales product owner and they would go, common stakeholders would be other general managers like, "Oh, that's a fantastic idea. We could put it up to the top. And all of our teams have the proper skills and abilities to actually see that feature all the way to delivery."
The Reality Check: Scrum in Name Only
And so a lot of times we will use this word, "We have scrum teams, we're practicing Scrum," but we've only done it in so much of the name. And that's okay sometimes if that's how you're getting started. I mean, I applaud that - start somehow, but we have to take it to another level at some point in organizational design.
If we don't do that correctly, Scrum will be very painful in your team, which it's doing its job. It will expose that problem, but we have to take it to another level.
Creating Effective Silos of Work
So next time you and your organization are thinking about practicing Agile and Scrum, have you thought about it to that next level and thought about the organizational design, trying to make silos - I know that's a bad word - but silos of work that don't have to cross teams very often?
Every now and then we'll get a feature they'll have to cross the entire organization, but for the most part, we want the teams to be able to handle their dependencies and handoffs within the teams and then within teams of teams in that organization. That is how we can be agile in organizational design.
Ready to transform your organization's design for true agility? Discover how Big Agile's comprehensive classes can help you move beyond Scrum in name only to create genuinely effective, cross-functional teams that deliver real value. Our expert-led training will show you exactly how to structure your teams and backlogs to minimize dependencies and maximize delivery speed.