The No-Huddle Approach to Rapid Software Delivery

Taking inspiration from American Football to move at speed

icons from icons8.com

Over the last few years I’ve been specialising in rapid exploration and development of new software solutions — and one of the many approaches I use I have now named the No-Huddle Approach, because of the similarities I’ve seen with a approach in American football.

The typical offensive approach in the NFL

In American football, the goal is to score a touchdown at the other end of the field. The team trying to score (the ‘offence’) has four attempts (‘downs’) to move 10 yards or more — if they succeed, they get another four downs to move another 10 yards. And so on — until they score, turn the ball over or fail to make 10 yards and have to punt the ball back to the other team.

Typically before each down, the offence gather together in a ‘huddle’ where the quarterback relays the play-call to his team-mates — i.e. what pre-designed play they’ll do — throw, run, who runs what routes, who blocks etc. They then break the huddle, get into formation at the line of scrimmage and execute the play.

The no-huddle offence

However — in certain scenarios, the offence goes no-huddle - where before each down they don’t form a huddle, but instead get into formation immediately and execute a play.

Why? For a number of reasons:

• To tire out the defence (opposing team) by having less breaks between plays.
• To give the defence less time to get organised or get different players onto the field.

and most relevantly to us today:

• When the offence has limited time and needs to score as quickly as possible
• e.g. when there’s only a couple of minutes left in a half or at the end of the game.

Peyton Manning, the retired Colts and Broncos quarterback, was a master of the no-huddle offence — and one of the best to ever play the game. He knew what he needed to do, and he (I’m presuming) trusted that with all the practice he and his teammates has carried out throughout the year(s) working together they could execute the required plays without a huddle.

The typical agile approach to rapid solution delivery

Most software teams use an “agile” approach — basically a process / set of guidelines on how to run projects and get work done. There are many variations of agile but for our purposes we’ll define these typical parts of the process:

• Teams have a goal in mind — not scoring touchdowns, but releasing a new product, or making a major update to an existing one.
• Work is broken into ‘sprints’, usually 2 weeks in duration, and within those sprints a number of tasks (or ‘stories’, ’issues’ etc.) are carried out. i.e. Four downs to move 10 yards or more.
• Before and (usually) during sprints there are various meetings (or ‘agile ceremonies’ such as ‘sprint planning’ and ‘sprint refinement’) where tasks are discussed and planned i.e. like those NFL huddles.
• These planning meetings can be simple or complicated, short or long, depending on how much granularity goes into it.

The No-Huddle Approach

I’ve developed a new approach with characteristics:

• One week sprints.
• A weekly demo with all stakeholders where the previous week’s progress is shown, and based on feedback, the plan for the next week is discussed.
• Sprint planning & sprint refinement meetings are suspended, or at least they are kept to a bare minimum, where tasks are discussed quickly, at a very high level.
• Daily ‘standup’ meetings (quick meetings to discuss progress / blockers) are maintained.
• Daily communication with colleagues/stakeholders/users/testers via Teams, Slack or email etc — there is no waiting for scheduled meetings to discuss important items.

This approach assumes the following:

• There is no need for regular long meetings to plan individual tasks or to discuss the priority of tasks because the team knows what is needed to achieve the project goals, and how long it will take.
• Such matters can still be discussed — but on an ad-hoc basis as needed.
• The individuals on the team are highly skilled, experienced, and very comfortable working together — trust in each others’ abilities is essential.
• Tasks are accomplished at speed — productivity is high, resulting in significant work to showcase and gain feedback for, at the weekly demos.
• “IT” and “the business” are in direct communication — there are no in-betweeners or middle-people. The people building & designing the solution talk directly to the people who own it and the people who will use it.

So basically — like Peyton Manning and his high-scoring offences, teams need to know what to do and be able to to it quickly, with minimum discussion needed.

When is this appropriate for use?

The No-huddle approach isn’t suitable for all projects, teams or situations. Typically it’s suitable when:

• There is limited time — not two minutes at the end of a game, but when you have only 8 weeks to get a product live.
• You know what’s needed — it’s not for a project where you’re not sure of the solution. It’s for when you’ve decided what to build and just need to get it done.
• As said above — you have a highly skilled team that needs minimal supervision. This isn’t an approach for a junior or inexperienced teams.

The weekly demo is the key part

For me, the most important part is the weekly demo. In a football game, there is a clear deadline — you have to move 10 yards or score in four downs or the other team takes over.

With one-week sprints you have to show progress each week at that demo or you’ll fall behind on your schedule and your stakeholders may lose confidence in the team’s ability to meet the deadlines. Nothing focuses the mind more than knowing that each Thursday you need to show something great and get feedback on it.

It is flexible

This approach is not set in stone and can change as is needed. During a project, you may need to take a step back to decide what to do — e.g. take a few days to decide how to design an architecture, how to design a new API, or how to respond better to a business change of direction.

It’s perfectly ok to slow down the delivery and have more meetings to plan properly what’s needed — but once it’s decided, there is no need to break it all down into granular tasks on a project board, and velocity can once again increase.

Warnings

The No-Huddle approach is of course not perfect and you should be mindful of:

• Burnout — going high-speed is a temporary approach when time is tight, not for all year round.
• Similarly, working extra hours is not part of this approach — going fast does not mean working late at night and at weekends. If software teams start working extra hours it shows that either team effectiveness is bad or that the project deadlines are unrealistic and need to be changed.
• People may view the approach as unorganised — whereas the opposite is true. I was discussing No-Huddle with a colleague last week and he said “it sounds like a ‘winging it’ approach” i.e. making it up as you go along. This isn’t the case — this approach is for when you know exactly what to do, and trust your team to get it done.

The key to keeping people confident in the approach is:

• Do what you said you would — deliver each week on your promises.
• Constant communication — make sure everyone knows at all times what is going on, and why.

Final note

This No-Huddle approach is not about making your teams work harder, it’s about helping them go quicker when it’s appropriate to do so.

As a tech lead who’s lucky to work with fantastic colleagues, I love it — I love the weekly demos, the increased communication, the ability to pivot quickly when needed based on feedback, the satisfaction when something of value is delivered quickly for our partners and customers.

Any thoughts or comments on this, please let me know below, I’d love to hear what other folks are thinking! Thanks, Andy.