One of the main features of doing Scrum is the 'Sprint' also known as an 'iteration'... When I first started using agile techniques around 10 years ago we used to work in a 10 week sprint, 8 weeks development 2 weeks testing (hopefully something unheard of today) over time it dropped to 2 weeks (which is probably the average today)... Since then I've experimented with the 1 week sprint and I've spoken with a few Scrum masters who have tried daily sprints.

Being agile contrary to popular belief doesn't in fact insist you work in iterations at all - it's a concept used in Scrum but if your an agile team using Kanban you probably won't have any iterations at all - working instead on a flow based system - albeit you may have the concept of cycles.

As you gain more experience in Scrum hopefully you'll find yourself and your team borrowing more and more Kanban techniques and likewise Kanban teams might find themselves doing more of the team building, collaborative Scrum based activities.

If you find your team is getting to the point where having to wait to the end of a sprint before deploying a completed user story is becoming an unhelpful concept and starting to look a bit archaic.. read on!

Before going any further I just want to point out that I'm certainly not recommending the scrapping of sprints and for many project based teams working in iterations is a very good model - However there may come a time where the process is working well and importantly the current model is understood by all involved that you might like to 'play' with moving to a very dynamic flow based system.

I was doing some agile work with a BI (Business Intelligence) team who had relatively small stories (usually no more than a few days to complete) and a business requirement for fast turn-around - In this case the iteration based model was actually causing bottle necks! By switching to a flow based system we were able to deliver working software within days not every 2 weeks!

We were able to rapidly reprioritise the sprint backlog and allow new work to enter (Something not allowed within an iteration/sprint based system)

We were also able to calculate some meaningful stats such as average lead time (The average time a customer waited from requesting a new task to that task being delivered)

We maintained a back-log but kept it small - It was the product owner responsibility to keep it maintained and ordered and the team pulled jobs from the top of the queue.

Again - I'm not recommending that any team moves away from iterations and indeed the iteration model builds in a number of safeguards that inexperienced agile teams will find useful in protecting it self from dangerous business practices and pressures - But, in a mature agile organisation where the business respects the decisions of the team a flow based system might be worth looking at and might speed up delivery.

Want to know more take a look at my blog all about Kanabn and Scrumban