Managing dependencies among multiple teams is a difficult agile project management challenge. On my first Scrum project, we started with only one team. That project soon grew to three teams, with the typical dependencies between them. I quickly arrived at what I thought would be a good way to manage those dependencies. I would stagger the sprint start dates by a week. The idea was that when a team went to start its sprint it would know the stories one of the other teams had recently committed to and which stories the other team was likely to finish.
Well, that part of my plan did work out well. But, overall, staggering the sprint start dates was a horrible idea. The biggest flaw in overlapping sprints is that there is never a time (except the end of the project) when all teams are done. One or more teams are always partway into a sprint. Some are planning a new sprint, others just planned a week ago, and still more teams will plan next week. This makes it difficult to give the full system to a customer for feedback or to an operations group for deployment.
A better idea is to have synchronized sprints, where all sprints end within a day or two of each other. Notice that all sprints do not necessarily need to end on exactly the same day. It is acceptable on a large project to have sprints that end over a two- or three-day period. In fact, there can be advantages to doing this. Allowing sprints to end over a two- or three-day period can make it easier for someone on multiple teams to attend all the review and planning meetings expected of someone on multiple teams. Additionally, it has the advantage in many cases of better accommodating remote team members who may travel into town for these meetings. A remote team member who is on multiple teams will find it easier to justify the travel time and expense if she can participate fully in each of her teams’ meetings.
Having synchronized sprints also does not mean that all teams must work in sprints of the same length. A project with multiple teams can accommodate different sprint lengths through the use of nested sprints. The most common use of nested sprints is when the various teams on the project cannot agree on a common sprint length, with some wanting two-week sprints and others wanting four-week sprints.
Don’t be tempted to overlap sprints. Instead, on multiteam projects, synchronize the sprints for maximum effectiveness.
More on sprint planning and scaling Scrum can be found in Succeeding with Agile.
Tags: large projects
We have done both ways in the last 18 months and we came to the same thought. We have stuck with 3 teams ending over 3 days. Great article Mike.
All for synchronised sprints but also for synchronised sprint numbers / names too.
I worked on a nine team project and like you mike many teams joined later and each team started their work their sprint counter started from 0. We did not see it as a issue until you started discussing the big picture and then you got something like “it will be done in sprint 4″, ” ah your sprint 4 in my sprint 13 and the other teams sprint 6″. It used to make your eyes water just thinking about it. We went to a consistent naming convention based on the month and the first or second half of the month. This work really well for us.
Thanks, Derek. I think almost every company tries (or at least considers trying) to overlap sprints. Almost all realize it’s just too hard.
Hi Mike–
I was thinking about sprint names/numbers myself a few weeks ago. How to refer to a sprint used to be such a common question. Quite seriously, this was one of those standard questions that I could count on coming up at *every* client I visited.
Oddly, I don’t get the question much at all any more.
I’m with you on consistent naming tied to the month. This has teams say things like:
–The June 10th sprint
–The first June sprint
–The second June sprint
–The early June sprint
–The late June sprint
which really help reduce confusion. Thanks for bringing this up.
Hi Mike,
I wonder whether needing synchronised Sprints to get to Done is a smell? Why can the customer only get a full system at these points? Is there some impediment or dependency which is stopping the flow?
I agree that synchronising Sprints is a good way to establish a cadence between teams in the short term. I’m not sure I’d recommend never being tempted.
Karl
Hi Karl–
It’s good to hear from you.
Each team in the specific case that prompted my post could quite easily get to done on its own with any sprint schedule. The challenges were things like getting stakeholders to come to sprint reviews when they were happening all the time. When teams synchronize their sprints, there is always the chance to combine a few sprint reviews (“your stuff only makes sense if they see what we did this sprint; let’s do our reviews together”). Even when sprint reviews aren’t combined, getting some busy, senior person to walk over here for a 45′ minute today, then another tomorrow, can be hard. It’s often easier to get someone to join one longer meeting. (Plus with one meeting, we can save money buy food only once
Plus, getting one release every two weeks (rather than 3 during that period) was, of course, preferable to customers. I’m looking forward to Office 2010 for the Mac but I’m not looking forward to a January release of it, then two in February, one in March, etc.
I checked above and didn’t say to never be tempted by this. I only used “never” when saying that if teams overlap (instead of synchronizing) there is never a time when everything has stopped and we can take a full snapshot of where we’re at. To me the benefit of this is like one of those families with on-the-go parents and kids who say “Do what you have to but everyone is home at 6pm for dinner.” We all go our way during the day (work, practices, friends, whatever) but it all comes together once per day (sprint). That’s one of the reasons why I doubt I’ll ever abandon iterations as a fundamental part of how I do software.
My company has been running Scrum for several years and we have syncronized sprints, meaning that they all start and ends on the same dates. We have 9 teams and a challenge we had was to get the stakeholders to attend the reviews (which ran over several days).
A while back we put all reviews on one day, in the same room, approx. 25 minutes per team. In my opinion this has been a success we have more stakeholders attending the reviews, it’s easy for teams to attend other team reviews making our development more transparent through the organisation.
BTW we do synchronized releases as well.
In our company where the system we build is very large and complex, synchronization is hard. On the other the size of the system forces us to big bang releases that happen 3 times a year (x3=9, for each supported version). The internal chaos around the release sprints is almost too large to be handled. This is why we’ve had to keep the sprints in sync.
Our clients needs vary so much that there are several recognized delivery patterns from which we have chosen the most poorest from the development point of view. Release seldom and release late. Which then goes against Scrum itself.
Thus I have started to think that by liberating the teams from synchronization we could force a refactoring of our delivery processes and make system components less interdependent. This would lessen the time to market and overall quality. And speed up the release cycle. Removing teams from sync could have positive effects when the company structure and/or old habits prevent making things better.
Hi Eirik–
This has been my experience as well. Thanks for sharing your story.
Hi Angry Poodle–
(I never thought I’d say that
You raise an interesting point. I wonder if synchronizing sprints creates unnecessary coupling between teams. I’ve never noticed this but I haven’t been on the lookout for it occurring because of synchronized sprints. I’ll start keeping an eye out for it. I don’t think, though, that forcing sprints to end at (about) the same time will create unnecessary coupling, but perhaps…
What I’m really after with synchronized sprints is to have a period where nothing is partially implemented. I want everything stable periodically so people can go hands-on with the software and know that if they find a bug, it’s a real but and not something that is there because Team #43 was only halfway through their sprint when we took the snapshot of the system.
We have a system that consists of roughly 100 productized components. We simply can not be stable at one single point of time due to the lack of resources and complexity of the system. Thus we dedicate few sprints for releasing where the system is freezed to a certain state before the release.
This way we force the syncing of teams, but we still have too much dependencies. Removing the sprint synchronization could be a tool to remove technical debt from our products.
But after the technical debt is swept away, keeping teams in sync is a worthy idea.
Hi Mike,
I really like your thoughts on this. We’re facing a similar problem at my company, and synchronizing teams could be lifesaver.
Although, what do you suggest happens in the case of sprints that are terminated prematurely? Let the team do a couple of weeks cleanup, or start a short sprint to catch up with the rest of the teams? Either way terminating a sprint can seem a bit more intimidating than it maybe should be.
/RB
Hi Rune–
Oh, great question. I should have thought to mention that situation in the blog post. If one team falls out of synch with other teams (on the same project) because of an abnormal termination, that team should run a slightly shorter or slightly longer sprint the next time. This will get them back in synch with the other teams. Normally it’s pretty easy to decide if it should be shorter or longer.
For example, if we’re doing 2-week sprints and abnormally terminate with 4 days left, the team do a 14-day sprint (2 weeks + 4 days the third week) to synchronize back up. Or if we’re doing 4-week (20-day) sprints and abnormally terminate 3 days into the sprint, I’d suggest planning a 17-day sprint.
[...] Synchronize Rather than Overlap Sprints – Mike Cohn explains why aligning Sprint end dates within one or two days of each other is a much better way to coordinate multiple Scrum teams. [...]
Hi
I’m working on a 5 team project with synchronized sprints. Each team is working in isolated branches till they complete any story before they push to trunk. The problem we are facing is that the synchronized sprints filters the pushes to the end of the sprints, which causes bottlenecks and story spillover. Efforts are made to finish some work earlier, but the natural tendency is to have it clump at the end (student syndrome). It also lumps the project manager’s heaviest workload all in the same period, the end and start of sprints.
How do your teams overcome these bottlenecks?
Hi Marc–
There are a number of things you can do, including bringing in work of different sizes so that work is finished at different times naturally, you can have a team “swarm” by working on one backlog item at a time so that team members learn new ways of working together and start to solve this problem for themselves, and you ask the team what they would do to solve the problem (including first making sure they and not you feel some of the pain of the problem). As for the project manager being busy at the start and end, you can try using a ScrumMaster instead and having the team take on the management roles performed by your current project manager.
Hi Mike,
Some companies are using the concept of Agile Release Train where sprints are synchronised, where at regular intervals there is a release (every 3 to 6 sprints), the last sprint before an internal release is a “harden” sprint for teams (I suspect bad teams need to harden their code but should be the exception).
Would you advocate the Agile Release Train concept as a good practical model?
Regards,
Ch
Hi Christophe-
Dean Leffingwell introduced the idea of a “release train” in his scaling book. I hear he’s elaborated on the idea in his new book. I’d want to read that before commenting on the idea.
Hi Mike,
I spoke on Friday to an engineer who used to work for a company implementing Agile Release Train and it failed: engineers spent too much time planning and C.I. tools were very poor. Since the model includes “harden” iterations, I think this is a sign that management may have used scaling to reintroduce some form of Waterfall model… So here is my question: when scaling Agile, should companies scale the scrum master role where, when scrum masters cannot remove roadblocks for their teams, they can find a Master of Scrum Masters who has enough power to help them out. Such roadblocks could be: change the way the organisation works, change the tools used, change product owners, change sw engineering practises, change the direction of the organisation if that prevents software engineers to do what they do best: delivering software? The role of the master of the scrum master would be to make sure Agile principles are fully applied at all levels of management?
Thanks
Christophe
Hi Christophe-
I’ve never seen a “master of scrummasters,” but don’t think it would be necessary.
Hi Mike,
I got it wrong. I was thinking that the governance model for Agile would be similar to the one for Waterfall so, at some point, somebody (designated) will help remove the roadblocks the scrum masters can’t (same as project managers ask program managers to help out). It seems that for LonelyPlanet, executives walk down to talk to teams in front of their task boards and, if needed, remove roadblocks (such as adding more resources etc). So, thinking about it now, my question was more: what is a good governance model for Agile? And the answer could be “get your executives to talk to teams directly!”? Interactions over emails and powerpoint presentations…
Cheers
Ch
Hi Christophe-
I think that’s an excellent way to think about it. Of course, many companies will still want something a bit more formal. I’ve written a bit about governance in this article: http://www.mountaingoatsoftware.com/articles/42-the-art-of-compromise