How to slow down and go faster

In my previous article please don’t organize for speed, I shared this paradoxical quote from Cisco’s Scott Cherf:

To go faster, slow down. Everybody who knows about orbital mechanics understands that.

Say what? Slow down to go faster?
What do you think Cherf is talking about? Not rushing? That’s probably most people’s first thought. I bet most of us have had the experience of rushing to get a task done and screwing something up in a way that makes us have to go back and do the work over.

tides_30709_md

Another possibility is that he means we should follow a plan. That would make sense in the context of orbital mechanics too. The wikipedia entry for orbital mechanics relates the following:

The consequences of the rules of orbital mechanics are sometimes counter-intuitive. For example, if two spacecraft are in the same circular orbit and wish to dock, unless they are very close, the trailing craft cannot simply fire its engines to go faster. This will change the shape of its orbit, causing it to gain altitude and actually slow down relative to the leading craft, missing the target. The space rendezvous before docking normally takes multiple precisely calculated engine firings in multiple orbital periods requiring hours or even days to complete.

Feedback cycles

I obviously have no idea what he means, but I really hope he’s talking about feedback cycles. A feedback cycle in a software company is any repeating communication loop that allows the company to see problems and solve them. Customers calling support provide a feedback cycle about a piece of software. If support notices that a particular feature gets more support calls than others, it gives the organization the idea that they need to work harder on making that feature more usable. Another feedback cycle happens when a developer runs some unit tests, finds a regression introduced by his or her work, and fixes it.

Every organization has feedback cycles, and software companies tend toward relying on their longest feedback cycles. Why that is is anyone’s guess. The example of customer support calls indicating a usability issue is one of these long (and expensive!) cycles. It’s long because the feature went through the full pipeline from design to release. It’s expensive because customers won’t stay customers for very long if they have trouble using the software, have to call support too many times, or both.

moon_phases_24125_md

Long feedback cycles cause the frantic pace

It sounds counter-intuitive until you experience it for yourself, but long, expensive feedback cycles like this are usually what drive software organizations into hectic rush mode. A software team that doesn’t recognize usability issues until dozens of customers complain are going to be fifty miles down the road working on something else by the time they hear about the problem. So now they have to either stop what’s already in flight or figure out a way to keep it in flight and also take on the usability work. Of course they’re going to do the latter.

Next some critical bug fixes come in and they have to be finished now, too. Add on some production issues. Now, marketing comes by and requests the ability “just to demo” the new feature that’s not done yet, because they want to market the next version at a national conference next month.

And all of this is on top of all the work already pulled into this iteration.

Pretty soon, the team feels like the wheels are coming off, and no one can stop the train from crashing.

boy_7185_md

How to go faster

The usual way that teams respond to this insanity is to avoid doing some things and delay doing others. The team can’t ignore critical bugs, production issues, or great marketing opportunities, but there are only so many brains and hands. It seems like the problem is a simple math problem. We have X things we can get done and X+5 things to do. We have to cut five things. Which ones?

What if the problem isn’t the number of things that need done, though? I don’t think it is. I think the problem is using long feedback cycles instead of short ones.

Shorter feedback cycles can help this situation because they will prevent work that doesn’t need to happen. Much of the work that doesn’t need to happen is simply the time that’s required for communication between different teams, time that is worse in long feedback cycles because more teams are involved.

But a larger class of urgent problemsTM are simply urgent because they’re in front of customers. Another way to say it is the company is relying on a feedback loop that includes customers.

Based on my experience in software companies, most of the deadline stress and “urgent mode” work that a software team is drowning in is from their own inability to take advantage of shorter feedback cycles to find and correct issues before they’re in front of customers. Consider the following items and ask yourself how much of the stress and urgency in your software team comes from these:

  • production environment issues
  • bugs
  • re-working deliverables because what was delivered wasn’t what the customer expected
  • technical debt making the software hard to change for the customer

And that’s probably not even all of the issues that fall in this category.

79643_quarrels_md

Why won’t software teams use shorter feedback cycles?

If it’s so obvious, why don’t short feedback cycles that don’t include the customer get more use?

Above, I mentioned unit tests, one of the key early feedback cycles in software. The friction in unit tests is that developers have to take the time to write them. If the developers agree not to write unit tests, the code can get merged in sooner. When there’s a rush for delivery, the pressure is on to skip this vital step. The side effect, though, is that code merged in without unit tests has more bugs, and by the time the bugs are found and fixed, either via a later round of testing or by a user in production, it causes more work, it’s more expensive, and it’s ultimately slower. When the developer slows down to write unit tests, they speed up.

It’s not about unit tests, though. Studies have shown that bugs are more often the result of poor understanding of requirements than defects introduced during implementation. For a good summary of these, see Damian, 19991. So the truth is that the part of your organization involved with understanding the customer, designing the product, and specifying the requirements is most likely to blame for schedule pressure. That would indicate that you need to pay most attention to feedback loops that don’t include coding at all!

What about the usability example I gave? The one where customer support calls are revealing a problem area in the product? Is there a way to shorten that feedback cycle? Of course! There are a lot of inexpensive usability tools and practices that organizations can employ to improve usability and that produce a short feedback cycle. Go check out the wonderful book Undercover User Experience Design by Cennydd Bowles and James Box.

51899_unitmeascub_md

Take time to choose the earliest possible feedback cycle

Carefully consider feedback cycle options. My experience is that companies have a kind of groupthink going on that prevents them from realizing the best feedback cycle for the job. In one place I worked, everyone was really gung-ho about A/B testing. So they A/B tested everything. Unfortunately A/B testing is (again) an expensive, long feedback cycle that requires releasing software out to customers before getting feedback on it.

There are lots of good uses for A/B testing, but getting feedback fast isn’t one of them. It’s also expensive since the options have to be implemented, and one will be thrown away. On top of that, A/B testing often becomes about throwing things against the wall to see what sticks. A better way is to hire an interaction designer who helps develop the A/B tests. Meanwhile, consider the cost of the A/B testing and don’t do it if it’s too expensive for anticipated ROI. That way the A/B testing is done with two provably valuable options and someone has their eye on the big picture.

The point is: use the earliest feedback cycle possible. Everyone will benefit their company if they push back when the company goes down the path of using a wrong feedback cycle. The best thing you can ask about any new work is: “why are we doing this?” The second best thing you can ask is how the team plans to get early feedback and correct course if need be.

Short feedback cycles in a nutshell

Bottom line: if you want to go faster, slow down. To speed up by slowing down, strive to get work moved into the earliest feedback cycles possible.


1 Damian Herlea D (1999) Challenges in Requirements Engineering. Technical Report 99/645/08, University of Calgary. Calgary, Canada.

Leave a Reply

Your email address will not be published. Required fields are marked *