Agile Principle 6: Fast But Not So Furious

Agile development is all about frequent delivery of products. In a truly agile world, gone are the days of the 12 month project. In an agile world, a 3-6 month project is strategic!

Nowhere is this more true than on the web. The web is a fast moving place. And with the luxury of centrally hosted solutions, there’s every opportunity to break what would have traditionally been a project into a list of features, and deliver incrementally on a very regular basis – ideally even feature by feature.

On the web, it’s increasingly accepted for products to be released early (when they’re basic, not when they’re faulty!). Particularly in the Web 2.0 world, it’s a kind of perpetual beta. In this situation, why wouldn’t you want to derive some benefits early? Why wouldn’t you want to hear real user/customer feedback before you build ‘everything’? Why wouldn’t you want to look at your web metrics and see what works, and what doesn’t, before building ‘everything’?

And this is only really possible due to some of the other important principles of agile development. The iterative approach, requirements being lightweight and captured just-in-time, being feature-driven, testing integrated throughout the lifecycle, and so on.

So how frequent is *frequent*?

Scrum says break things into 30 day Sprints. That’s certainly frequent compared to most traditional software development projects.

Consider a major back-office system in a large corporation, with traditional projects of 6-12 months+, and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. The overhead of releasing the software is just too large to be practical on such a regular basis.

But consider a web site, a web-based product – or even more dynamic something like my blog. There’s no rollout overhead – it’s an automated central deployment to all users, and for the blog it’s a single click. No-one’s paying for the service. If something’s wrong, no-one dies. And it can be rolled back as quickly as it’s deployed. There may be thousands of users, even millions of users of a web site every month. But none of them need to be trained. And you can evaluate the impact on the user experience, and the user’s behaviour, through metrics within 24 hours and on an ongoing basis.

In that scenario, 30 days is a lifetime!

Competitors won’t wait. Speed-to-market is a significant competitive edge. The value of first-mover advantage is potentially enormous. Whilst it’s not always the case, research shows that those first to market 80% of the time win; and end up clear market leaders.

So how frequent is *frequent enough*?

Think carefully about your own situation. Think about the two extremes I’ve described above. Think about what’s right for you; your organisation; your product; your market; your customers. Think about what’s right for *you*, in your *particular situation*. There is no right or wrong answer. Only what works for you, and what doesn’t.

What is fairly important is to make this a positive decision to decide what’s appropriate for you. And then to stick, if you can, to a regular release cycle. A regular release cycle allows you to plan. It allows your infrastructure and ops teams to plan. It allows your business colleagues to plan. It allows your launch events, marketing campaigns, etc to be planned. And because agile development works to a fixed timescale, these plans are assured.

A regular release cycle also allows you to learn more effectively. Your estimating might be good, it might be bad. Hopefully it’s at least consistent. If you estimate features at a granular level (ideally less than 1 day) and track your velocity (how much of your estimate you actually delivered in each Sprint), in time you’ll begin to understand your *normal* delivery rate. And when you understand this well, you’ll be surprised how predictable you can be.

And let’s face it, managing expectations is really all about predictability. If people know what to expect, they’re generally happy. If they don’t, they’re not happy. Maybe even furious!

So, in agile development, focus on frequent delivery of products. And perhaps even more importantly, focus on consistent delivery of products.


Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
41 Corsham Street
N1 6DR
United Kingdom


101 Ways Limited
No.1 Spinningfields
Quay Street
M3 3JE
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at