The core concept behind timeboxed iterations is that, every sprint, the team delivers running, tested features. So every two weeks, the team gets together and should be able to demo the features they built to the product owner and customers. And in a highly effective environment, the product owner could say, “That’s perfect! Let’s ship that to production!”
And it would seem that if you are doing your iterations, and keeping up with your Sprint Backlog that committing to deliver the feature by the end should be easy for a team to accomplish. After all, it’s not asking a miracle of a team to show what they did, is it?
To understand, let’s look at the context of a large software company that delivers a boxed product. In order to deliver the feature, it of course has to be completed (both development and testing). It also has to be verified that it meets the business needs. And then the real fun kicks in – it has to be added to the production build, the documentation has to be created, the labels have to be localized (exposing potential bugs) and a whole host of other issues might come into play (regulatory approval, 501.3c compliance testing, etc).
So, if we need to do all that to deliver our software, how can we possible demo that we are going to deliver every sprint?
Magic 8-ball, how do we deliver?
In fact, it’s a common question. In a recent experience report, Chuck Maples, the Senior VP of R&D for Borland, admitted the difficulty and struggle of delivering every sprint:
To incorporate performance, scalability and integration testing, we would have to adapt our Scrum practices…This enterprise testing runs one sprint behind and we have a hardening sprint before each release.
It seems reasonable, doesn’t it? Delivering everything necessary to ship the software just doesn’t fit into our iterations, and we don’t want to extend them, so we just have a “hardening” sprint or similar fancy name with which we can get the real final preparations done.
But instead, what we’ve uncovered is a limitation of our process. We’re trying to shoehorn our stories into a process that doesn’t fit. So what can we do?
Change our process, or change our process?
The first thing we need to ask is can we do things in parallel to enable us to ship during the sprint. For example, can our language translation happen in parallel as we are developing? Or can we do a little more design up front to submit the applications for approval earlier? Perhaps we can employ automation to do single-click compliance testing, which we can even employ into our nightly builds.
Of course, anyone who has done significant localization efforts, or dealt with compliance testing knows that it is never as easy as that. Compliance auditors are often very picky about seeing things after they’ve been built. Localization companies are often quite expensive, so unless you have the people on staff, doing things on a week-by-week basis might be cost prohibitive.
To enable this, we should focus on what we’re trying to do. If we can’t ship the story, what is the point of finishing during the sprint? Why don’t we instead focus on what our real goal is – delivering working software. And if we view it from that perspective, then we can work on uncovering ways to work effectively within the parameters we have.
To do that, we start measuring the cycle time of our stories from concept to completion. We might find that when we batch the stories into groups of four to the localization company, they are able to work faster overall then trying to keep up every week or two weeks.
We might also discover that our bottlenecks in between “done” and “shipped” can be resolved by simply doing a small amount of additional work during the completion of the story.
Start with your organization
But before you go about tweaking the process, you have to be able to look at the overall workflow of what it takes to deliver the software. This means using tools like Value Stream Mapping to uncover what the true process is that your team and organization must follow.
It is this discovery, this research, which gives you a solid base to begin discovering how to work more effectively, ship more effectively, and most important, deliver solid running, tested features to your product owners and customers.