Slow Scrum Process? Common Agile Issues and Fixes

Any startup can claim to be agile - but if your scrum process is slowing down, it's time to check for these common problems with your development process.

“Move fast. Speed is one of your main advantages over large companies.” Sam Altman, CEO, YC Combinator

Move fast? Easier said than done.

Every founder knows that familiar feeling of ‘moving too slowly’ — and the long nights, team squabbles, and agony that come with it. For early-stage tech companies, there’s nothing quite as frustrating as slow product development.

The root cause of missed releases and slow progress is seldom a lack of effort. More often than not, it’s because the team hasn’t implemented Scrum properly.

Learn new skills every week ->

Agile Lip Service

Ask an early-stage founder, ‘Are you agile?’ and you’ll probably hear the default response:

‘Are we agile? You bet we’re agile! Our development team uses Scrum.’

But probe slightly deeper and you’ll find out a dirty little secret. Many development teams that claim to be agile are far from it. They equate agile management with a scrum board and daily stand-up meetings — and agile isfar more than that.

Startups that don’t implement agile properly miss out on its main benefits: continuous process improvements, faster value delivery and building a self-managing team.

Stand-up Meetings aren’t Enough

A well-implemented Scrum process includes six time-boxed meetings, which involve the entire team:

• Sprint Planning — defining what to build
• Task Planning — defining how to build it
• Stand-up Meetings — daily updates
• Story Time — estimating new user stories
• Sprint Review — demoing new features to the company
• Retrospective — feedback session among the team

 

Simply put, if this is the first time you’ve heard about these meetings, you aren’t doing Scrum properly!

Cutting Meetings has the Opposite Effect

Some teams cut these meetings in the hope of freeing up more time to focus on development. Isn’t it better to have 10% more development time, rather than sit around in meetings?

But cutting Scrum meetings to save time is like taking the engine out of a car to make it lighter — rather than speed things up, everything quickly grinds to a halt. The whole point of story time, the sprint review and the retrospective — the meetings most commonly missed by dev teams — is to allow you to increase your speed over time.

Agile isn’t just about speed — it’s about learning how to accelerate.

If it’s Worth Doing, it’s Worth Doing Well

Great products are the result of great product development processes. Done well, Scrum has the potential to accelerate your performance in three critical areas:

• Product Delivery
• Planning Accuracy
• Process Improvement

(For a detailed article on how to implement Scrum, I recommend Scrum: A Breathtakingly Brief and Agile Introduction, by Chris Sims and Hillary Louise Johnson. For now though, I’d like to explain how Scrum helps you accelerate.)

Product Delivery

In Maker’s Schedule, Manager’s Schedule, Paul Graham describes how a single distraction can blow a whole afternoon’s worth of productive work for a developer or designer. Scrum helps create a focused environment for dev teams by locking down scope over a short period of time. This is called a sprint.

Each sprint has a clear and measurable sprint goal to deliver an increment of value to the customer. Small increments have many advantages over larger releases, including getting feedback from customers earlier in the process.

In the sprint review meeting at the end of each sprint, the dev team get to demo the completed features to the wider organisation, so everyone is kept in the loop and gets to learn what the dev team learns.

It’s obvious why teams that don’t ship regularly want to cut the sprint review meeting — they have nothing but code to demo to the rest of the company!

Predictably enough, those teams promising larger releases miss their deadlines, since the amount of uncertainty increases exponentially with scope. A lack of communication between the dev team and the rest of the company then leads to frustration and demotivation on both sides.

The sprint review provides the accountability and celebration that dev teams need to move tasks to ‘done’ and keep the whole company up to date.

Ship it. Demo it. Iterate.

Learn new skills every week ->

Planning Accuracy

If we are to deliver small increments to the customer every sprint, how can we reliably define what is possible? Scrum provides an ingenious, lightweight approach to estimating work.

In the story time meeting, the team play a game of ‘planning poker’ to estimate a set of user stories using story points — a measure of relative effort. Each team member has a set of cards with the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) on them. Why Fibonacci? Because the uncertainty of estimation increases with the size of a story — making debates about, ‘Is this an eight or a nine?’ pointless.

After the team reads out each story and its acceptance criteria, team members place a card face down on the table and then reveal them together, to compare estimates. As ambiguity is revealed, tighter acceptance criteria are added to the ‘definition of done,’ and larger stories are split into smaller ones. The process is repeated until consensus is reached.

Often it’s developers, not designers, that have the best feature ideas, because they are closest to the technology and best understand what’s possible. Story time involves the dev team at the earliest stages of design so they can input more feasible ideas earlier in the process.

By estimating stories in story time, and comparing those estimates to how much effort they actually took in the sprint review, a feedback loop is created. This increases the team’s ability to estimate more accurately over time.

Estimate. Check. Iterate.

Process Improvement

Feedback is essential to high performance. While many startups do one-on-ones, few actually run retrospectives as part of their scrum process — and this is perhaps the biggest mistake of all.

The retrospective is powerful because it creates a safe place for teams to openly share regular, lateral feedback, enabling them to self-manage. It’s hard to overstate the impact this can have on a team’s performance.

Asking team members, ‘What went well?’ allows them to recognise and celebrate what each of them is most proud of. Receiving recognition for work that you’re proud of is intensely motivating.

Asking, ‘What didn’t go well?’ allows teammates to listen and empathise with what each other finds most frustrating, increasing psychological safety and strengthening connections within the team.

And asking, ‘How will we improve?’ guarantees that one or two important changes that address major challenges are made every sprint. Just consider the radical impact of regular improvements after three months. Or a year . . .

Retrospectives and facilitated group feedback isn’t just for dev teams. That’s why I run retrospectives in my management teams, department teams — and even with my clients — as a primary feedback loop.

Empathise. Improve. Iterate. 

Keep Calm and be Agile

If you’re leading a tech company, you owe it to yourself, and your company, to learn agile principles and implement Scrum properly. There’s a reason that it’s the gold standard for product development.

No-one likes change — that’s human nature. Sure, you’ll find resistance if you try to change any process.

But if the ‘moving too slowly’ feeling is getting you down, maybe it’s time to be a little more agile.

Continue reading about project management principles:

• Struggling with your codebase?  Learn why tech rebuilds aren't always advisable. 
• Working on a new product idea? Here’s a handy guide to designing product principles. 
• Is your MVP too complex? Read my in-depth checklist to help build simpler products.   

Originally published Apr 3, 2019, last updated Jul 27, 2023