The Agilian Two-Week Sprint
There is a good reason why experienced Scrum teams gyrate towards sprints of two weeks long. Why these teams prefer to shorten the sprints to one week when desired and are hesitant to extend the sprint beyond three weeks. It is the inability to plan beyond the threshold of two weeks and the desire to validate their work periodically through the Scrum rituals. Sprints of two weeks imply that all rituals are performed every two weeks as well. For experienced teams that means more value instead of more overhead.
Experienced teams understand their limitations when it comes to plan beyond two weeks, to maintain the same priorities for more than two weeks and to accurately predict the amount of effort needed to solve a problem that has never been solved before. These teams thrive on continuously receiving feedback on what to do next, where to go next, which problem to solve next.
In the last 10 years I worked with many teams that were at different stages of adopting Scrum as their way of becoming more agile. The experience I gained as coach to these teams has proven to be invaluable when working with leaders to make their business more agile.
In all but a few cases teams that were used to the traditional waterfall method to do projects started out, when adopting Scrum, with monthly sprints. These are quickly adjusted to four-week sprints to allow for more convenient planning. When asking the teams about this, I usually got the response that the sprint rituals were considered overhead and were taking too much time out of the team’s busy project schedule. Their justification for performing the rituals nonetheless was that since the rituals are required when adopting Scrum, the teams tried to optimize the ratio productive time vs. scrum ritual.
Whether a team will succeed in adopting Scrum is, in my experience, heavily depending on the team’s access to a Scrum coach. Too often I have seen organizations taking up Scrum by sending their project managers off to become certified Scrum Masters with the assumption that their experience as project manager and the newly gained knowledge would result in success. Especially when not coached by an experienced Scrum master, teams often continue to do waterfall but make the waterfalls smaller. The 12-month project turns into 12 one-month smaller projects. Not necessarily all resulting in a product release. Each individual month is divided into the normal waterfall phases, analysis, design, implementation, and the buffer phases called testing and documentation. Whenever the end of the month is near, you always have documentation and testing to sacrifice and still meet the deadline.
One 12-month project turns into 12 one-month projects.
As teams become more avid in adopting Scrum, I do see that the waterfall phases will become less pronounced and the Scrum rituals find their way onto the team-agenda. If not only because the recently certified Scrum Master did know the answer to the question “Which rituals are required to implement Scrum?” on their exams.
Scrum comes with a set of rituals that are mandatory from a purist Scrum perspective. Planning, Retrospective, Demo and Stand-Up are of course introduced because they have proven to be effective ways to increase productivity and quality of the product, but only when you do implement the rituals as intended. Again, when your Scrum master is not experienced and not guiding the team on how to make these rituals valuable for the team, these rituals will soon seem to be a waste of time. Probably rightfully so, several hours down the drain with every sprint. Now you see why it makes sense to do Scrum and perform the rituals, but not too often. The reason why many teams stick with the four-week sprint is that they experience the rituals as a waste of time because they do not get from them what Scrum promises. Limit your Scrum Ritual Overhead to the minimum. Four-week sprint it is.
Agile Project Management and its Application in Medical Practice | Data Driven Investor
Realistically speaking, "Medical practice" is one big complex project. It is becoming even more complicated and…
You benefit the most from your sprint rituals when you perform them often. At least, that is my experience. Although it is not the reason why I always try to stick with two-week sprints wherever I go, it does imply performing the rituals once every two weeks.
The reason why I prefer two-week sprints, is simple. I cannot plan more than two weeks ahead. In this I am not unique, far from it. When I plan something beyond two weeks, it will almost for certain be wishful thinking and does not mean anything. I have yet to meet somebody that can predict what they will work on two weeks from now and that are in engineering. Of course, it is possible to plan for more than two weeks ahead. In fact, one can plan for months in advance. It would require work that has been done before, several times in fact. And that would not concern engineering work. Engineering is solving a problem. And problems are solved only once.
Limit your Scrum Ritual Overhead to the minimum. The Four-week sprint is your solution.
I admit that I can only say for the next two weeks with a level of confidence what I will be able to achieve in that period. I will only commit to those achievements. Anything beyond those two weeks is so likely to be impacted by something unforeseen that it would be lying when committing to deliver the results that would be expected. And it is not specifically me, it is simply the human inability to plan.
Realizing that I can only plan two weeks into the future, it makes no sense to plan for anything beyond that timeframe. Planning sessions will need to be held once every two weeks to be anything close to effective. Or rather, to result in a reliable committed delivery of new features.
As you plan every two weeks, it stands to reason that everything you do in those two weeks is intended to deliver some value to your customer. In other words, at the end of the two weeks, you will have something to show your customer. Something that is worth a demo. If not only to demonstrate that you did not waste time. This is not trivial as sometimes it feels like if you did not achieve anything significant. So why demo?
Experienced Scrum teams determine at the start of each sprint what the purpose or objective of the sprint will be, and consequently what will be in the demo. Often I have come across teams that also discussed how to demo their achievements. Even teams that are not literally developing something, but instead provide guidance and coaching to other teams can use this technique. I have been part of a team that coached other teams to become more agile. We did regular planning sessions and flagged the stories we felt worth sharing with the rest of the organization.
As you and your team worked on your product for the duration of your sprint, reviewed your delivered features against your committed stories. After you have demonstrated the value of your work, it is a good moment to talk within the team about how the team fared during that sprint. What did you do right as a team and where do you need to work on your team dynamics?
I would argue that teams that do not think it makes sense to periodically touch base and see how they can improve the way value is delivered to the organization, are dysfunctional teams. These are teams that do not see value in discussing their internal relationships, values, and behavior. Like any other relationship, being in a team needs work.
The two-week sprint turns the Waterfallian into an Agilist.
I am always stunned when managers do not motivate their teams to at least do a retrospective at the end of the sprint. Trust me, each hour spent on a retrospective is probably the most valuable hour to be spent, because this is where the team bonds and reinforces its internal relationships. Something that will allow the team to act as a team instead of a group of individuals. You do not want to do this once a month or once every four weeks. You will want to do it often, at least once every two weeks. A team that was build, needs to be maintained. Relationships that are forged need attentive partners to sustain.
As I explained before, the two-week sprint is great from a planning perspective. And by performing the Scrum rituals periodically without much time in between, they are meaningful. A demo every two weeks generates momentum and a positive ‘we achieved something’ vibe which is motivating. The retrospective every two weeks ensures that there is not much time between establishing as a team what bad behavior to drop and what good behavior to adopt.
The two-week sprint is perfect also, because it makes your waterfalls even smaller, until the point you understand that waterfall is not suitable for Scrum at all. And this is when you become truly agile. The two-week sprint turns the Waterfallian into an Agilist.
On the go and done reading? Check out this continuing piece of pure fiction.
The text very explicitly communicates my own personal views, experiences and practices. Any similarities with the views, experiences and practices of any of my previous or current clients, customers or employers are strictly coincidental. This post is therefore my own, and I am the sole author of it and am the sole copyright holder of it.
Special thanks to my lovely wife Olcay, as well as my dear friend Sytse who took the time and made the effort to review my article. I am confident that the article’s quality was significantly improved by their feedback.
Gain Access to Expert View — Subscribe to DDI Intel