Standardize how you talk about success, the key mental models you’ll use, and at boundaries to support coordination.
Allow as much local variation as you can. If you don’t have to standardize something, let teams experiment.
In this episode, Richard and Peter answer the question: “How much should we standardize across our organization? Is it important that our sprint lengths match, that we estimate the same way, that we use the same tools, that we report the same metrics, etc.?” Obviously, standardizing everything isn’t going to work, but neither will standardizing nothing. So, where do you draw the line?
Links mentioned in this episode
Learn More
Episode transcription
Richard Lawrence
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
Peter Green
Trying to Humanize Work is hard, but it can have a huge positive impact on the lives of the people we work with, and for our customers and the health of our businesses. If you’re trying to humanize your work, and you’re getting stuck or frustrated, let us know what challenge you’re facing. Send us an email at mailbag@humanizingwork.com with a few details about the situation, and we’ll share how we might think through your challenge right here on the Humanizing Work Show.
Richard
Before we jump into today’s episode, just a quick reminder to rate and review the HW Show in your podcast app, or if you’re watching on YouTube, would you please subscribe, like, and share today’s episode if you find it valuable to you. We really appreciate your help spreading the word about the show. And if you want to get access to more content we produce, not just the show, you can always sign up for our newsletter where we share one key idea every week. Sign up for that at humanizingwork.com/hwnews.
Peter
Today’s question is about the tension that often exists between a management desire to standardize things across teams, and the teams’ desire to have autonomy in how they structure their work. Ryan asked it this way: “How much should we standardize across our organization? Is it important that our sprint lengths match, that we estimate the same way, that we use the same tools, that we report the same metrics, etc.?” Ryan is a manager who wants to improve the system for a set of teams. Other times, we often get a similar question from team members who are concerned there’s too much standardization happening. After all, one of the agile principles states that the best architectures, requirements, and designs emerge from self-organizing teams.
Richard
Let’s acknowledge that there are real potential benefits to standardizing. When it’s done poorly, of course, it leads to frustration and demotivation, but there are some real benefits to standardizing some things across teams when it’s done well. For example, here are some of the motivations that kind of drive people toward more standardization:
It can be easier for leaders to get a sense of what is being done, by which team, and how it’s going. If everyone uses different tools, practices, metrics, and terms in their work, it can be really difficult to know how things are progressing across a number of teams.
There can be some financial benefits of standardizing on things like tools. If every team spins up a subscription to their own favorite tool, there’s probably a lot of duplicated costs, and not every tool variation actually matters.
Standardization can make it easier to coordinate efforts between teams or different groups in an organization. If every team is using different tools to track their work and to communicate, coordination and decision making across those teams is slow and inefficient.
Standardizing can make it easier for people who work with multiple teams, or for transitioning from one team to another.
And finally, we often see a motivation here, that’s kind of a desire to benefit from “best practices.” We all want to be good at our work, and it’s tempting to assume that what works well in one situation will apply in another. So, we’re often on the lookout for the best practice to apply. When something seems to be working for one team, or when something is recommended by an authoritative source, that can signal, “Here’s a best practice. We should use this all over the place.”
In practice, though, a high level of standardization tends not to achieve all of these goals or, more often, has side effects that aren’t worth it. We’ll discuss in a moment some of the problems of too much or too early standardization, but before we do, we want to talk about a few places where we do find value for some standardization, so we don’t totally throw out the baby with the bathwater, here.
Peter
Three places where we see standardization adding some real value are: how we define and measure success, how we think about the work, and how we coordinate shared efforts beyond a single team.
Let’s start with the first one, how we define success: As an example, if Richard and I worked on different teams in a larger company, and Richard’s end of year report described their very successful year by saying, “Our team reduced operating costs by 25% while maintaining top-line revenue,” and my team’s report described a successful year as “Our team increased top-line revenue by 50%.” How would a leader at the company know if either of those was actually a good outcome? How would the teams, themselves, know if those were good outcomes? There’s not enough context from those high-level summaries to know whether either of those results was actually a good idea or good for the business. Richard’s impressive cost-cutting could have been a result of laying off a key contributor and squeezing the last bit of revenue out of a frustrated customer base. My team’s 50% growth could have burned through massive capital, burned out my all-star team, and landed a big contract with a customer that was going to require a high level of ongoing maintenance for the next three years.
So organizations do need a standard way to talk about the outcomes that matter and the constraints we need to work within to achieve those outcomes. For this, we like an approach that some of our clients use here, called goals and guard rails. The goals portion of this is some kind of systems of Objectives and Key Results (or OKRs) for example, that provide clarity on how an individual or a team’s work contributes to a larger shared goal. The guardrails portion of it defines the constraints that the team or individual needs to work within. None of us have an unlimited budget, timeline, or set of options for how to achieve a goal, so the guardrails provide clarity on the logical constraints for that goal. When defining goals and guardrails, it works best when they’re derived collaboratively, both up and down the hierarchy and across the various parts of the business. And the best systems keep the goals and guardrails as lightweight as possible.
The second area where there’s some real benefit, is in how we think about work.
This one is a bit meta, but it’s important. Each of us have mental models for how we think about work. For example, we often begin our workshops by describing the Cynefin Framework for categorizing different types of problems and the best strategies for how to solve them. This shared mental model impacts everything else we talk about and informs why we’d make specific decisions in different contexts. Organizations need to decide which mental models are foundational to how they make decisions. Then, using standard language from these mental models speeds up every other decision. You probably don’t need Bridgewater and Associates’ 100s of principles, but aligning on a key few are important. How do you think about the system of work broadly, how do you think about your customers, and how do you think about human motivation, for example.
And then, the third area is “at boundaries.”
For example, two teams working together on the same backlog need some level of alignment on things that affect coordination: things like what tools they’ll use; sprint lengths and boundaries; how they estimate. Two groups like product and marketing need to standardize how they’ll coordinate on similar boundaries. Even at the large divisional level, there’s probably a minimal set of standardization at the boundaries, like reporting on finances and goals.
Richard
So those are the places where we like to see some standardization, now let’s talk about how standardizing causes some problems, and what to watch out for.
Often, standardizing causes problems because the standard, whatever it is, doesn’t fit the context on a particular team. For example, I’ve seen organizations decide that Scrum is the standard process framework to be used on all teams, and, as you know, we like Scrum for a lot of things. But then you’ll have a team that does a lot of emergent work like operations or support, and they immediately end up with a process that doesn’t fit their context. They’ll follow the rules, and they’ll plan for a sprint, and the plan gets blown up right away. The process just starts feeling like waste and overhead imposed on them. That team would be much better off with something like Kanban instead of Scrum.
That’s a pretty obvious and egregious example. A more subtle one I’ve seen was in an organization adopting Behavior Driven Development or BDD across a whole software development organization. BDD, if you don’t know, is a practice of using concrete examples in conversations to create alignment around what to build and then formalizing these examples into automated tests to drive development. It works great for teams creating new software with rich business rules. In this particular organization, they’d been adopting BDD on one team after another, and getting good results from it. Then we came to a team that was mostly responsible for configuration in an HR system. It didn’t seem like BDD was going to be a good fit for their work—it wasn’t going to add enough value there for the overhead it would impose, but their management insisted that, because it was the standard, they should take my BDD class and try to adopt the practice on their team. The team made a good effort, but it became clear pretty quickly that, as suspected, they’d be better off using different, non-standard practices for alignment and testing, and they ended up abandoning BDD.
Other times, and this is almost worse, the standard works well enough that it’s not obviously causing a problem, but it’s probably still not the best thing for a particular team. In that situation, standardization isn’t directly causing a problem, it’s just inhibiting local experimentation and improvement. We’re just doing what we’re told instead of finding something that really works for us.
I remember one team I worked with that was using story points to estimate, using the standard Fibonacci-like sequence of numbers because that was the organizational standard. That’s the way estimating works. The team had gotten good at splitting backlog items and wasn’t getting much value out of estimating. But they kept doing it, because it was the way things were done. There’d be lots of debate about whether this particular user story was a 5 or an 8 or a 13. Eventually, they’d just end up splitting the story, anyway.
Finally, that team decided, “You know what, let’s find a way to work around the standard.” So they kept doing, in a sense, the story point estimating, but they switched their estimating scale to have three options: 0, 1, and “too big.” (Everything else.) Zero meant, “too small to count.” One meant, “about our standard size.” And “too big” meant, “we’ll need to split this to get 0s and 1s.”
This team was fortunate that they could hide their experiment within the standard as far as the rest of the organization was concerned and so they did do some local experimentation, but they also never really told anyone else in the organization about it, because they had no incentive to admit that they were breaking the rules. More often, I see teams just never run the experiments because they don’t think they’re allowed to.
Peter
A lot of times, standardization may eventually make sense—there may be enough common context across teams, for example—but it’s just too early to know what standard to adopt. When an organization is first adopting an Agile approach, we like to see lots of different experiments running in parallel within the goals and guardrails we mentioned a moment ago. Then, teams can share what’s working and the best approaches can naturally become more standard.
This all goes back to that idea from Cynefin that we mentioned earlier: Best practices work in the clear domain, where things are predictable and where we’ve solved the problem many times before. But we’re in the complex domain with this kind of org change, not the clear domain, so best practices aren’t the right tool for the job. We need to experiment until we find the order.
Richard
So, to summarize, here’s our advice around standardization, back to the original question, “How much should we standardize?”
First, standardize how you talk about success, standardize on the key mental models you’ll use, and standardize at boundaries, where you need to, to support coordination between different teams or groups.
Second, allow as much local variation as you can. If you don’t have to standardize something, make space for teams to experiment.
And finally, be willing to add translation layers where necessary to support local variation (e.g. derive road maps from backlogs rather than making every team have the same kind of backlog—the stakeholders don’t need to be in the backlog details).
Peter
Please like and share this episode if you found it useful, and keep the questions coming! We love digging into these challenging topics, so send them our way and we’ll see how we can help.
Last updated