If you've been on or worked with a significant number of teams in an Agile context, chances are you've heard something like this many times: "We could get a lot more work done if we had longer sprints." While our basic instincts may tell us this line of reasoning makes sense, evidence has shown us that this type of mindset rarely produces results that are favorable. However, many Agile practitioners have seen situations like this on more than one occasion. Based on our collective experiences, we would like to share some of our observations on the topic so that we can continue to have positive and interactive dialogue that will enrich everyone's lives.
There are many reasons why teams may be initially inclined to increase the length of the sprint. Below are some of our favorite experiences:
If we had longer sprints, we'd spend less time preparing for and having recurring meetings like sprint reviews, demos, and retrospectives.
If we had longer sprints, we could finish a lot more work per sprint than we do now.
If we had longer sprints, we could test more thoroughly.
If we had longer sprints, we could adjust for all of the changes that take place in our requirements.
If we had longer sprints, we could more accurately predict/forecast what we would be able to accomplish.
If we unpack the reasoning behind why teams might wish to make sprints longer, certain anti-patterns tend to emerge.
Anti-pattern 1: Teams are spending too much time preparing for sprint reviews/demos.
Anti-pattern 2: Teams are attempting to complete stories that are too large.
Anti-pattern 3: Teams are running "mini-Waterfall" sprints.
Anti-pattern 4: Teams encounter problems with code merges, integrations, and deployments.
Anti-pattern 5: Teams are relying heavily on individuals external to the team to get work done.
Anti-pattern 1: Teams are spending too much time preparing for sprint reviews/demos
For teams that are relatively new to Agile, there is a common misperception about what the purpose of a sprint review/sprint demo is, and this type of misperception can result in teams spending far too much time on preparation activities. As such, the time that is consumed by demo preparations will result in lost productivity by the team -- because it is valuable time that is not spent working on story completion.
At minimum, the sprint demo is a time for the team to showcase the work they just completed. Maintaining focus on completed work helps the team solicit and obtain responses (both favorable and unfavorable) from members of the stakeholder and/or customer community. As such, the sprint demo is a perfect example of frequent inspection and adaptation. Depending on variables such as the size of the team, the length of time the team has been together, and the length of the sprint/iteration, we've found that preparation activities related to the demo typically take from one to three hours (and when we say one to three hours, that does not mean the whole team sitting in a meeting for that much time preparing -- that means the total amount of time expended by any team member). If/when teams find themselves taking an excessive amount of time (let's say four to six hours or more) to prepare for the demo, then we'd suggest that further discussion take place during the retrospective in order to find out what could be done to shorten this timeline.
Anti-pattern 2: Teams are attempting to complete stories that are too large
One of the things that new teams in particular struggle with is writing stories in such a way that they are small enough for the team to realistically complete during a single sprint. If the team finds itself completing only a subset of the stories it commits to, on a recurring basis, there are multiple factors at work.
A proactive step that the coach/ScrumMaster and product owner can take is to focus their attention on helping the team split stories into smaller pieces. For instance, where a particular story touches multiple aspects of process or architecture, it is wise to consider splitting such stories into one or more smaller stories. We always strive to encourage teams to work with stories that have a high degree of both quality and value. At minimum, these two areas of concentration will help forge stronger and stronger bonds between business representatives and the technology team representatives who are building the new functionality.
There are many articles that provide guidance about splitting stories into smaller parts (story splitting). Here are two articles that we think are particularly good: http://www.agilelearninglabs.com/2013/04/introduction-user-stories/
Anti-pattern 3: Teams are running "mini-Waterfall" sprints
We have seen teams practice "mini-Waterfall" sprints in a number of different ways. One of the most common examples of this anti-pattern is a "development-only sprint," where a team only does development work during a particular sprint cycle, and then does testing of that work during a subsequent sprint. This is an anti-pattern that teams should avoid at all costs. While the thought may seem feasible in the short term, the long-term implications will often spell disaster at the team, program, and even release levels. To state the most obvious reason why this anti-pattern is so nefarious, it means that teams that operate this way do not produce working software at the end of every sprint.
Another common misconception is that work related to quality can't take place until the last few days of the sprint itself. Unfortunately, with teams built around specialization of labor, this is an all-too-familiar pattern of behavior. Unless the pattern is broken, specialization of labor will create a natural queuing approach to completing work during a sprint. A common scenario that we have seen on many teams is a "create and wait" approach to completing work. Teams can definitely break these patterns of behavior by decomposing stories into smaller and smaller units of work. Next, continual code integration can provide a means of testing continually throughout the sprint cycle. As coaches, we have always encouraged teams to select and implement as many technical "best practices" as possible so that benefits associated with automation can be realized. Finally, team members can partner with one another in order to learn new skills that will begin to break down the walls associated with specialization of labor.
Mini-Waterfall sprints are often the result of an exclusive, non-team-oriented mindset. By exclusive, we mean the common tendency to distinguish between developers and testers (and sometimes others, e.g., analysts, designers) as completely separate and distinct skill sets, where opportunities for pairing and mentoring are discouraged. A common manifestation is a QA versus DEV culture that is essentially a barrier to the team being able to reach its fullest potential. At minimum, functional managers and team members themselves have the ability to break down these traditional barriers and create their own subculture for the betterment of the team(s). This type of grassroots movement can provide some positive results, which brings team members closer together and ultimately yields higher team production with better quality.
Anti-pattern 4: Teams encounter problems with code merges, integrations, and deployments
Infrastructure considerations can help or hinder teams that are working within relatively short sprint cycles. At the very least, a subset of practices needs to be in place that can set the team up for success. Many of the technical practices associated with Extreme Programming (XP) are appropriate to mention in this context, such as:
Environment setup and code promotion/migration strategy
Version control approach (trunk, branch)
Code quality standards (code coverage)
Daily code check-ins and build routines
Continuous and/or automated deployments/integrations
Test-driven development (TDD)
Take the practice of continuous integration (CI), for instance. A great many articles and books have been written about this practice, but to boil it down to its simplest elements, CI can be seen as the fulfillment of two rules:
Code in the version control repository builds has successfully passed its tests and is ready to release.
Code in the version control repository represents all of the team's work up to a few hours ago.
Teams that can honestly say that, during each sprint, their code meets these two conditions have already put themselves in a position where they are more likely to be able meet their sprint goals on a consistent basis.
Everything else related to CI -- integration servers, automated builds, and so on -- is important, but all of those CI techniques are done in the service of being able to release software on demand. There may be business reasons not to release at a particular time, but CI focuses on making sure there are no "technical" reasons that would prevent a release from taking place.
Another common practice is called the "ten-minute build." The key thing to keep in mind (the desired end state) is not the specific number of minutes the build takes -- the point is being able to build deployable code on demand. For instance, when a new person joins a team, or when there is a need to wipe a workstation, it should be possible to download the latest code from the repository and run the build. Some of the other benefits of having a fast and well-automated build include:
Building and testing the whole system more frequently
Detecting bugs earlier
Reducing integration problems by integrating software frequently
Anti-pattern 5: Teams are relying heavily on individuals external to the team to get work done
It is not unusual for teams to rely on individuals or groups that are completely external to their team. For instance, database administrators (DBAs) are often not members of a specific Agile team but instead are called upon on an ad hoc basis to do work such as creating or deleting database tables. Other examples of specialty skill sets that often are not available as dedicated members of an Agile team include software architects, performance testers, and specialists in areas such as information security and accessibility testing.
For teams that are faced with these types of situations, there are number of approaches to mitigate the impact of external dependencies. To start with, during sprint planning, we recommend that team members be explicit about calling out the nature of the dependency on an external person or team, and that they also capture the impact of what alternative steps can be taken if the external entity is not able to keep their end of the bargain, for whatever reason. Simply stated, to the greatest extent possible, teams should seek to avoid situations where completion of a story cannot happen without the assistance of someone external to the team. For instance, the team might choose to rewrite a story such that only
the part that is within their control is part of their sprint commitment, and to either write a separate story (what some might call a "get from" story) or use another technique to call out the fact that work needs to be done by a particular team or individual.
When is increasing the sprint length a "good idea?"
We are going to resist the temptation to answer this question with the word never
and instead offer some practical, real-world advice. As Agile practitioners, we have often been asked to advise individual teams, multiple teams, senior managers, and even entire business units or companies. The reality is that in some cases, experience is the best teacher -- and by that we mean that there are cases where teams feel so strongly that increasing their sprint length will be beneficial to them that sometimes the best option is to have them experience longer sprints for themselves. For example, it is not until they try it in practice that they might realize that the particular problem their are trying to solve is at best only partially addressed by making the sprint longer -- and that they introduce other problems that they did not anticipate by making sprints longer.
Consider a case where a team complains about not having enough time to complete testing over the course of a two-week sprint. Chances are, this situation is an indicator of a problem that extending the sprint length will not fix. Suppose that the team in question is running "mini-Waterfall" sprints (see anti-pattern 3). If that is the case, whether the team extends the sprints to three weeks or four weeks, as long as they conform with that anti-pattern, they will still find themselves pressured to finish their testing at the end of the sprint. And worse, they will be delivering software less frequently and getting customer/stakeholder feedback less frequently, which in and of itself tends to create other problems the team did not anticipate.
As practitioners, mentors, trainers, and coaches, we encourage teams to keep the size of the sprint cycle small. Our collective experiences have shown us tremendous benefits associated with smaller durations from the perspectives of the team(s), stakeholders, and customers. Yet, at the same time, we believe that teams should be encouraged to find their own natural rhythm as it pertains to this topic as well as others. We hope that our observations will help aid in your Agile journey, and we wish you the best of success going forward. I've always remembered words I heard as a child: "Access to success is through the mind." Or, put another way: "Agile access and success are 100 percent mental."