Large enterprises are unwieldy. Their people might be competent and their visions might be sound, but turning around the proverbial tanker takes time.

Libraries have been written about change management and “Business Agility” but the truth is pretty simple: more people = more communication = more time needed. You can gain some efficiency here and there, but it seems to be an iron law: big is slow.

The main obstacle for large corporations is not that they have a lot of people. It’s that they have a lot of people in charge. When your project gets started, a team is appointed and they get cracking on building the next big thing. The first month goes according to plan and then a classic pattern emerges. As soon as they get some momentum, the team attracts the attention of “hidden stakeholders”.

All of a sudden there is an architecture committee that needs to be involved. The company has decided to document specs in a certain way and your team was not aware of that. You’re building it in Angular? Didn’t you get the memo that we’re consolidating to React?

It’s easy for a one-man team to grind on that singular vision for a start-up. As long as he believes in the product, it’s on track.

Large companies are not so lucky. It’s rare for a vision to stay the same for an extended period of time. There is always a new, more important product. There is always a new program or management that has a different idea.

The enterprise kitchen seems to be equipped with a revolving door that supplies a constant stream of too many cooks.

The natural reaction is to block them out.

“We’ve been working on this for months. It’s too late to implement your API standards now.”

That sounds reasonable, but in a large enterprise, you can’t ignore the powers that be. That always ends up with a confrontation and your political weight might not be up to the task. One of these stakeholders is heavier than you.

You can’t ignore them and you can’t turn around your entire tanker every time some other stakeholder shows up. So: what can you do?

Short iterations are the answer. Instead of having a Big Hairy Deadline at the end of the year, build small iterations of your product and make sure you end on “backlog zero”.

That is different than the Scrum sprints approach where you stuff a year full of features in a backlog and then evenly spread those out across two-week sprints.

At the end of your iteration, your backlog should be empty. That gives you the opportunity to manage the influx of constant changes. Think mini-projects, not sprints.

“If it’s that important to the company, we’ll dedicate the coming month to rewriting our API to fit the new standard.”

The delivery will be a lot slower. A lot of software will be rewritten. That’s the cost of more communication: rewriting. Slow and expensive, but at the end of the year, you will have shipped a product that is supported by the company. Something of value.

We focus too much on “agility” and speed of delivery. That makes sense for a start-up whose superpower is a quick turn-around of new ideas.

Large enterprises have a different skill set. It’s OK to go slower as long as you build a product that won’t get cancelled in its first year.

Large bulky enterprises can still deliver great products if they have a Lean mindset. If your company skips “backlog zero” and believes in first-time-right, it might be time to update that CV…