Tag Archives: stop the line

Encouraging people to stop the line with both carrots and sticks

2012-02-10-Carrot-and-stickIn my last post, I described a work challenge around delivering high quality products, noting that despite repeated encouragement, members of my team were reluctant to stop the line, even if that meant sacrificing quality for speed. I offered a few thoughts on why this was the case, including mixed messages from leadership, aggressive deadlines, our tendency to fall in love with technology, and peer pressure.

In this post, I’ll describe a few things we’re doing to try and correct the situation. Some of these things are what I’d call “carrots,” or rewards that come with stopping the line to focus on quality. Others are “sticks,” or penalties.

Carrots

Celebrating line stoppers
If someone stops the line, we celebrate it publicly. At our all eCommerce team standup this week, we discussed a project that didn’t go as planned, thanking the person on our team who stopped the line and slowed it down, helping us avoid a big mistake.

Using numbers
Products that are well-designed and well-executed tend to outperform those that aren’t. Regular KPI reviews encourage our product teams to do their best work. Sometimes this requires stopping the line.

Holding design review meetings
Last month, we instituted design review meetings with our team’s leaders (it’s a riff on Ed Catmull’s “Braintrust” idea). At first, our teams were afraid they’d be micromanaged.  But a month into the new process, they see the value and appreciate the attention. And they’re quickly becoming more detail oriented.

Showcasing great design
When something is designed well, we share it, far and wide. Being a team that focuses on quality products is becoming a point of pride for all of us. Building “good” things is boring – our products should be great. We want our people to be able to tell the difference between good design and great design, and to aspire to create the latter.

Finding evangelists within the team
I’m actively recruiting people on the team to promote the value of stopping the line. I started with our UX people, who seized the opportunity to get the rest of the team focused on the user experience. (As you’d expect, it was easy to get them on my side.) By now, the entire team has heard the message, and we’ve got lots of evangelists – and converts.

Sticks

Requiring rework
One great way to ensure someone on the team stops the line is to make it clear that the whole team will be starting over from square one if they don’t. When faced with the prospect of removing functionality from our sites and rebuilding it from scratch, stopping the line starts to feel like the much faster option.

Public shaming
This is a route we haven’t really gone down, since one of our core principles is to celebrate failure. Still, when we see poor customer experience, sloppy design, or performance issues, we let the team know. We favor blameless postmortems, but we also favor paying attention to details.

Instituting sign-offs
Our team knows that when they release code into the wild, they’re implicitly saying it’s ready to go. If we need to, we can make this explicit. This would be a last resort – sign-offs aren’t part of the culture we’re nurturing – but it’s an option if we need it.

These are just ideas, of course. If stopping the line and focusing on quality are important to you, you’ll need to work with your team to figure out how to make it happen, and you’ll likely need to revisit the conversation over time.

As leaders, we also need to model this behavior. This means there are times we need to stop the line ourselves, even when it’s our own work we’re doing and our own deadlines we’re missing. We need to make the same trade-offs we ask our teams to make, and have the same tough conversations we ask them to have with stakeholders.

What do you think? Have you had similar experiences as it relates to stopping the line to focus on quality? How have you addressed them? I’d love to hear from you.

 

Why is it so hard to stop the line?

taiichi-ohno-lean-manufacturing-1

Those of us who’ve adopted (and adapted) Lean software techniques owe a debt to Eiji Toyoda, and especially to Taiichi Ohno, who developed the Toyota Production System (TPS) and forever changed the way manufacturing – and eventually much of software development – works. According to Wikipedia:

TPS is grounded on two main conceptual pillars:

  1. Just-in-time – meaning “Making only what is needed, only when it is needed, and only in the amount that is needed”
  2. Jidoka – meaning “Automation with a human touch”

Core to jidoka is the concept of “stopping the line,” which means that when someone at Toyota identifies a problem, they’re required to stop production and resolve the issue. This ensures problems are addressed immediately, when they’re easier, less expensive, and less frustrating to fix.

Our eCommerce team has embraced this way of thinking. Our agile product teams are familiar with the Toyota story, and they understand the importance of identifying problems early. They sit together at tables, which makes collaboration easy, and they have daily stand-up meetings to make sure everyone’s on the same page. Best of all, they’re aligned around common goals, so they have the same motivation to improve the customer experience and their KPIs.

So why won’t they stop the line when they see an issue?

Stopping the line is really, really hard

Recently, my team released a couple of new features that weren’t up to our usual standard – experiences that were a little bit clunky. In both cases, after the projects were complete and the new functionality was deployed into production, we removed the new functionality from our site, sending the teams back to the drawing board. Weeks later, we’re still in the process of rebuilding these features, and we’re going through the work in great detail as a team to make sure we get it right.

Every single member of the team knew – weeks before launch – that the experience was less-than-perfect. And every single member of the team had been coached multiple times to stop the line. Even further, if you asked any member of my team if they understood the importance of stopping the line – if they agreed with it conceptually – every one of them would have said yes. And yet, nobody did it.

I asked three people why, and they all said some version of this:

Our team is working on becoming a well-oiled machine, and I don’t feel comfortable slowing things down.

The machine

Earlier this week I attended DevJam’s excellent Product Conference, and I was glad to hear its founder David Hussman discuss how product and agile are evolving. “We’ve gotten really good at building the wrong thing faster,” he said, and I couldn’t agree more.

My team was built for speed, and although I kept telling them to stop the line, I also told them a lot of other things:

  • “This new functionality is going to add a lot of revenue for our business.”
  • “You’ve got a long backlog.”
  • “If we get this done pre-holiday, it’ll be great for the bottom line.”
  • “Our Marketing team really, really wants this now.”
  • “It’d be great to get both of these projects done next quarter.”

By now you get the idea, and hopefully you see the problem. And it wasn’t just me. My team supports a lot of brands, and the brand owners, marketers, merchandisers, technology teams, senior executives – everyone, really, was in some way or other telling our product team to do more, faster.

In response, we became a machine built for speed. We got good at getting a lot of projects done, and we found a way to set and meet the goals we had before us. We implemented Test Driven Development (TDD), built automated tests, and found ways to get closer and closer to continuous delivery. And I’m convinced that every one of these things was – and is – the right thing to do.

The problem is that we did them at the expense of building great things.

In my next post, Encouraging people to stop the line with both carrots and sticks, I’ll describe what we’re doing about it.