Slowing Things Down in a ‘Hurry-Up’ Situation

By Jeremy Duvall

With COVID-19 upending everyone’s “normal”, engineering teams are operating at one of two speeds: indefinite on-hold or ludicrous speed.

I get it. Hospitals are scaling-up to handle patient overflow. Universities, colleges, and schools are going 100 percent online learning. Public health officials are hurrying to track the disease while coordinating testing, quarantines, and treatment. Federal, state, and local governments are managing emergency response and relief efforts. Amazon’s fulfillment network and every grocery and restaurant delivery service is swamped with demand from people in self-isolation. And every business from global corporations to mom-and-pop shops is feeling the impact and either closing shop or scrambling to adapt.

If you need to build new or scale-up existing software systems at all, you need it now.

In the world of software engineers, crisis situations usually mean late nights (sometimes all nights) and lots of caffeine and takeout. There’s some twisted romance, I guess, to doing whatever it takes — no excuses, no complaints — to get the job done. Cue the dramatic music. Type faster. Prop your eyelids open with guitar picks. Sleep when you die.

But honestly, it’s kind of toxic. And it leads to bad code. Dangerously bad code. Even deadly. The kind of code that can make a crisis situation worse rather than saving the day.

It burns out software engineers too. Messes with their health. Screws up their lives. Noble sacrifice? No, sorry. Too high a cost. Besides, there are better ways to handle these “hurry-up” situations.

Slow. Down.

First step? Slow down.

Slow. It. Down.

Then take a little time to think carefully and plan strategically. What do you need to accomplish? When does it have to be done? How can you get it done with optimal efficiency?

Optimal efficiency is not “as fast as possible.” It balances speed with building things right. Building them for security, stability, and scalability. So that you don’t save a little time early only to lose a lot later. So that you don’t end up killing someone with your code. (We’re talking life-and-death crises here, right? So seriously… don’t kill people with bad code.)

That said, there are obviously times when you have to move fast. For many of us, now is such a time. And in such crises, you might sacrifice some of your usual processes. You might not build the ultimate solution to endure for all the ages.

My company sometimes helps customers who have “go-fast” needs. Sometimes they’re just rushing to grab a market opportunity or win the next round of investment. And sometimes, like today, the crises crash over them and threaten their very existence or the lives of the people they help.

We still slow things down at the beginning and come up with a plan to build things right. But then we figure out how to build it faster.

Cut the Scope

Plenty of anecdotal and empirical evidence has proven that users usually only want or need around 80 percent of what you think they need. That remaining 20 percent is wasted time, money, and brainpower.

Cut the scope to what’s really meaningful for the crisis at hand. Take the time to understand your backlog, and bucket things into categories that help sort out your prioritization.

We often use a sliding scale:

• Mission critical. This must happen or our business will disintegrate.

• Highly sought. This will delight our users and we really want this out.

• Could live without. This is important, but not critical to our business.

• Unproven. We don’t know if this is important or not yet — so it should be on hold until we know more.

Attach real customer reactions or conversations with stakeholders to each item in your product backlog and bucket your stuff into these labels. Note that these labels should change all the time as you continue to learn more.

Prioritize building the mission critical and most of the highly sought items. Build them right. With deliberate work by high-velocity, high-quality teams of people who have the time to get enough sleep, see their families, and keep their lives in balance so they can do their best work.

Strip Down the Scrum

Suspend traditional SCRUM workflows.

There, I said it. May the church of Agile forever excommunicate me.

In a hurry-up situation, heavyweight processes — like four-hour planning meetings, two-hour retros, and 15-minute stand-ups each day times five days for a grand total of one hour and 15 minutes a week — doesn’t give the engineering team enough time to get anything meaningful done. Especially since a crisis may last only half a sprint and you have to get something out ASAP.

We recently faced this with a customer with an urgent need. We put a temporary hold on sprints and went full Kanban to clear everything in the time box. Everything was fine.

Don’t be afraid to experiment with your process. A good team can adapt to any well thought out process. If you rely on a particular process to push your efficiencies, you should take a hard look at the culture of your team. Process should enable, not define, who you are.

Keep Breathing

Seriously, keep breathing. Deeply. Look up from your screen. Walk around. Take a moment.

You’ve got this.

No sense pushing so hard that you mess it up and make things worse.

Stay calm. Take care of yourselves. You’ll be better equipped to save the day.