By Alexey Krivitsky & Ragnar Birgisson
Our project takes place in a distributed environment—the development team and product management are located in different geographical places. When we first came to the project, our job was to help establish an outsourced, offshore office for a project that had survived years of ad-hoc development with no fixed iterations and no pre-planned releases. The domain was not complex, but the poor code quality and the onsite absence (or remote presence) of the knowledge-holders made the start-up trickier than we and the project stakeholders had anticipated.
We spent the first three to four months learning the codebase (by fixing bugs and adding some new pieces of functionality). Finally we were ready to think about how we should approach our project. We knew we wanted to try an agile approach and, after much debate, we decided to try Scrum (how that came to be, how Scrum was introduced, how it should have been introduced instead, and how eventually it changed the way the company works are topics for another article or two—maybe next time).
Setting Sail for Scrum
When we first began, we chose to use four-week sprints. For our product backlog items, we used per-feature requirement documents that we called feature specs. A feature spec is typically a three- to five-page document with a feature description, main workflows, and the screenshots. Our feature specs were created by the remote product managers.
These documents worked to some extent. However, from time to time gathering the needed amount of specifications for the next sprint was difficult for the product owner. He and the product managers struggled to find the time to write the specifications. Even after they managed to write some things down, more often than not, the information they provided would not be enough for the developers to provide reasonable estimates.
The length of the sprints felt fine to the team, but management felt they needed more visible results. At the same time, we wondered if a shorter sprint would help focus the team and optimize performance. We decided to switch to the shortest duration deemed possible: a single week. We could always switch back if it didn’t work.
Some of the results of our change were positive. For instance, each week the stakeholders received more visible results. However, the drawbacks far outweighed the positive. First, the development team started to feel pressured by having to deliver every week. Second, it was quite difficult sometimes to deliver valuable functionality in a just a week’s time. Finally, the cost of starting and stopping a sprint felt quite high, both in time and emotional investment by the team.
Miles to Go Before We Sleep
After the rather disappointing results of our weekly sprints we decided to revert to four-week sprints.
Compared to the rush we experienced trying to deliver weekly, the next few months felt relaxed. As we began to adjust the process to our ideals (and our ideals to the realities), we managed to start collecting the specs earlier and with more detailed explanations for the programmers and the testers. Things were improving. However, when we looked closely at our sprint activities, we realized that instead of a four-week sprint, we’d really been doing three-week sprints plus a one week cushion for finalizing unfinished sprint tasks. This was definitely not what we wanted “our Scrum” to be.
Ahoy! I See Land
It had been more than a year since the project was outsourced. Things had improved, but were not yet where we wanted them to be. At that time, we made a fundamental change to our requirement management process: we substituted lightweight user stories (inspired by Mike Cohn’s User Stories Applied) for our mid-weight specifications.
As we had hoped, user stories increased communication between development and product management. They also raised our understanding of business needs by the team. As a result, inter-site trust and relationships improved. This, in turn, boosted the product quality (the increase in quality was also due to better planning through finer-grained user stories, a growing set of unit tests, and the increased size of the testing team).
Having achieved the conditions described earlier we decided to try out shorter sprints. What follows are the “hares” that we were supposed to hunt for by changing our sprint length. (Happily for the hare-lovers, some of the beasties are still hopping in the wild.)
- Boost the team’s performance. The team had been having a tendency to start losing focus in the middle of a sprint. To counteract this, they simply had another sprint planning meeting after the second week to find out the current status (though we used to maintain a burndown chart) and made corrections to their plans by redistributing the tasks. This was not an ideal situation.
- Get earlier feedback from the product management (user proxies) and thereby from the real clients. The user stories were usually available for review by the end of sprints. The high story-count of what had been developed within that three- to four-week period made it quite hard for management to ascertain the project quality and plan for fixes/changes for the next sprint.
- Let the company make more frequent releases. The company’s official plan was to have quarterly releases, but we wanted to provide the possibility of doing it more frequently.
- Remove planning difficulties. With monthly sprints, the product owner had to plan four weeks ahead, which sometimes was hard due to ever-changing business priorities. It was also hard for the development team—the large number of stories we had to consider made planning sessions long and energy draining.
- Learn faster. We had to wait at least four weeks to study the effect of any changes we implemented in our process. Also we often wished to make so many changes that we were not able to focus on all of them within a single sprint. Problems we identified during sprint retrospectives began to pile up in a queue to be resolved at some later stage.
Our Journey's Far from Done
So far the team has done three bi-weekly sprints. In that time, met the following goals (or captured the following hares):
- Boost the team’s performance. The teams started feeling more focused, which they like. They now also can remember most of the sprint’s user stories, which makes it easier for them to communicate their status to each other. Some of them claim, though, that if the complexity of user stories or internal system grows they will not be able to finish sprints this often.
- Get earlier feedback. This has been confirmed by the product managers: they were able to get clients’ feedback faster and obtain developers' estimates and updated plans faster, thereby reducing the whole feedback cycle.
- Decrease planning difficulties. This has been seen by all of the affected people. For Alexey (as a ScrumMaster), those planning days were the most difficult ones: too many stories to think of, too-long meetings to be kept organized. Now planning is almost as easy as the morning Scrums.
- Learn faster. Over the past six weeks, we’ve already had three retrospective meetings (compared to the maximum of two we might have had, had we followed monthly sprints) which were quite productive, and again, easy to do. The attendees were in no rush to list all known obstacles, since we knew in two weeks’ time we would be able to review it again.
The following goals have not been met so far:
- Let the company make more frequent releases. This is still a goal for the next quarter or two. Though quality has increased within the last months, it is still not possible to release the software just after any sprint without running one or two special bug-fixing sprints.
Are all of these positive changes a result of switching to a two-week sprint? No. Shortening the sprint length itself lent to the positive effect, but doing so would not have been possible without other essential changes, such as raising team motivation and moral, improving and increasing communication between product management and developers (with the introduction of user stories), and increasing internal product quality.
Should we have started with two-week sprints right from the beginning? We don’t think so. Again, we think we would have failed without those preconditions (trust, user stories, good quality, etc.) in place. By starting slowly and building these components, we were able to deliver more quickly and then naturally adjust the sprint length. After all, you must learn to walk before you run.
