The No-Huddle Approach to Rapid Software Delivery

Taking inspiration from American Football to move at speed

icons from icons8.com

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.

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.

  • 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.
  • 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.

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.
  • 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.
  • 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.

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.

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.
  • 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store