Skip to main content

A Better way than Staggered Iterations for Delivery

January 10, 2021

There is a better way than staggered iterations for delivery that will keep you on the path to agility. Staggered iterations lead to more technical debt and lower quality software.

Updated to reflect the 2020 Scrum Guide! 

TL;DR;

The expected result of staggered iterations would be an increase in rework and in technical debt. If you are moving from a 4-year iterative process to a 4-month one you will see the value, but your process will be opaque and will only reduce your ability to deliver working software .

Yes, your cycle time will be reduced, but you can do so much better. Move all requirements for shipping your software into your Sprint. If you need testing then it needs to be inside of the Sprint. A general rule is that: If you need to validate something outside of the Sprint; User Acceptance, Security audit, regulatory approval; Then you need to make sure that all of the work required to pass that outside validation is doing inside of the Sprint, with no further work required from the development team.

- Martin Hinshelwood 

For example, this means that if you have 6 weeks of animal trials, followed by 6 weeks of human trials to validate that your pacemaker firmware is good, you can’t have those things happen inside of every 2 weeks Sprint. Instead, focus on what you can do to make those things pass. If they don’t pass then do a full route-cause-analysis and bring that new information to your Sprint Retrospective and make sure you put measures in place to make sure it does not happen again.

A better way than staggered iterations for delivery

I have seen many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. They believe that by creating a timbox for planning, development and testing that we can get closer to agility and move away from our traditional models. Unfortunately, the actual result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. In many cases, it can be a significant step backwards that will take many painful years to rectify.

A better way than staggered iterations for delivery

staggered-iterations-for-delivery

I have heard this called many things. Water- Scrum -fall or maybe Scrummerfall but whatever you call it the reality is that this is just small waterfalls and in the case above not really that small at all. This is often how organisations respond when they are told to “do agile” and they end up figuring out how to not really change, and do the same thing that they have always done.

This is not the action of a Professional Scrum Team , but that of, at best amateurs and at worst cowboys.

The problem with staggered iterations for delivery

In the diagram above we have an 18-week cycle from inception to delivery. That’s more than 4 months between ideation and delivery with a lag of 2 months to even get feedback with a 2 month lag for all subsequent feedback. Worse this is the most expensive kind of feedback as the Coding and Testing teams have already moved on from the thing that is getting feedback and the result of that feedback will be more expensive to implement. Indeed worse yet if QA finds something that needs fixed we have maximised not only the cost to fix but the meantime to repair as the developers have moved on. And what do they do with that feedback? How is it prioritised? Do they quit what they are doing immediately and fix the previous iteration or do they wait until after they deliver this one? What if they are blocking QA? Does QA sit around till the end of the iteration after the one they reported the problem in?

The solutions to staggered iterations for delivery

We need to foster teams over individuals and make those teams responsible for the delivery of working software. To get that we need cross-functional teams that can turn ideas into that working software. And we need to do it often.

  • Cross-functional teams – We need to have everyone on the Developers that is required to turn the Backlog Item into working software. If you were a property developer you would have access to joiners, plumbers, plasterers and electricians. You would create a team of individuals that was sufficient to complete the daily work on-site with experts on hand as needed. This is the same process for Developers  . You should have all of the skills that you require on each team to turn the forecast backlog items into working software each and every iteration. Have experts on hand for those tricky items but minimise the dependency that you have on them.
  • Asynchronous development -  Ideally you want all of the disciplines that you need to complete each backlog item to work together to deliver the software. This is more than handing off between disciplines but moving towards everyone always working at any point in time. This is a hard one to achieve but is the responsibility of the team to figure out how; To achieve asynchronous development you will need a modern source control system  .
  • Test first – Test first is about not doing any work unless there is a measurable test that elicits that work. Creating tests from acceptance criteria will make sure that your team is working on and understands the next most relevant thing to be worked on and that you have built what the customer wants. Additionally, creating unit tests before code will make sure that your coders are working on the most relevant problem, and that each line of code that they complete does exactly what they intended. The long term benefit of this is that we now have an executable specification that will result in an error if a future change breaks existing functionality.  You are doing it wrong if you are not using test first.
  • Working software each iteration – If you don’t create working software at the end of each iteration you have no way of knowing what really needs to be done to create a working increment . If you do four iterations of two weeks before you think about creating a working increment, how much work (re-work really) is left that you need to complete to really be done? To really have shippable quality? If you don’t have working software at the end of each iteration you are making sure that your business can’t ship out of band, no matter how much it wants to; Professional Scrum Teams build software that works  .
  • Quality Assurance requires no testing – If you consider that all testing is done as part of the sprint, then the only thing that needs to be done as part of the QA gate is to review the test results and coverage and determine the sufficiency of those results and coverage. If you are taking more than four hours to QA two weeks of development then I would suggest that the Developers  work is not sufficient.

These things will all individually help and if you are doing all of them together your value delivery and quality should start to increase over time. Make sure that you focus on automating everything from the moment a Software Engineer checks in code, to it being continuously delivered to production  . In the age of agility giving you a competitive advantage in whatever marketplace you are in, any manual work is a risk.


What did you think about this post?

Comments (11)


Andy O.
01:29 am January 1, 2018

Thank you Martin.
What you wrote down makes sense but it's incomplete: you haven't covered UAT and deplying to RPOD activites.
Should those be part of a Sprint?
Please elaborate on those bits - you do know as well as I do this is where all the trickery lies.


Mark Chapman
02:53 pm January 2, 2018

So UAT - Yes to get a story to Done it needs to be accepted, so if UAT is required for the PO to do this, it should be part of working on a story in a sprint (another reason to keep stories small).
PROD - so ideally yes you should be releasing, but often organisations are a long way from being able to do this (or there can be a good argument that shipping something behind a feature flag is pointless), so I'd say you only release if it makes sense, but the code should always be RELEASABLE, so if something happens and you need to ship it now rather than in x sprints you can (even if you need a feature flag for partially done features).


Juan Mejías
05:42 pm September 24, 2020

- It would be "root cause analysis", I think
- I'm not familiar with the term asynchronous development, other than referring to coders working remotely (http://asyncmanifesto.org/) but, in the sense used here, "Moving towards everyone always working at any point in time": Shouldn't this be called synchronous (rather than asynchronous) development?


Alexandra
08:08 am December 7, 2020

Feedback: dead link @ https://nkdagility.com/you-... in paragraph "test first"


Saurabh Sharma
11:33 am December 21, 2020

Sorry Martin but some other spell checks -
1.validsate
2.timbox
3. outside validation is "doing" inside of the Sprint. - should be "done"


Saurabh Sharma
11:36 am December 21, 2020

Everything that is needed to mark a story/increment DONE should be done without the sprint.
Definition of done (DOD) should drive it!
If for some reason it looks a bit too off in terms of feasibility, go back to refinement and see if you/team is breaking down (slicing and dicing) the work correctly.
Rest as always is try-inspect-adapt!


Chase Flinn
09:31 pm December 30, 2020

My concern here is the testing aspect. You seem to focus on the unit testing aspect which should come before the code is written. Functional U/I test however, require deployment to a page so the test can interact with a U/I. This by definition has to come after the code is written, but I do encourage the dev team to be cross functional in the sense that our developers are able to write test, and our "testers" are able to write code and they frequently pair up to complete both components within the sprint for a story.


Christian Humphreys
10:11 am August 9, 2021

I read this article because it is included in the learning path for POs. Working with agile for nine years now, I had big difficulties to understand what "staggered iterations" are as I have never seen such a setup. Unfortunately the article doesn´t give much context at the beginning to tell what this is about.


Peixoto Nathan
07:14 am October 28, 2022

The context is giving further in the article, IMO.
Staggered iterations happen when increments have many flaws that create additional unwanted work for future iterations.


Thomas
12:20 pm March 8, 2023

Thank you for the great article. I fell into that trap for a B2B software, because of the departments of the organization requesting "human resource allocation superiority". Hence a staggerd approach between the departments personal within the team, and a customer that always got "undone" items that lead to escalations.


Timothy John
06:09 pm January 2, 2024

In the second block of text, your blog post says, "route-cause-analysis." Do you mean root-cause-analysis?