If your software development team practices Scrum, are you required to deploy software only once during a sprint? That practice is clearly defined by Scrum, but is it a requirement? If you want to deploy daily, do your sprints have to be 1-day long?
I don’t believe so. Software teams using Scrum may deploy software as often as they like. In fact, doing so actually makes Scrum better because the team gets more feedback more often.
Here’s an example of how this might work. Let’s say the team settles on 3-week sprints. They hold a sprint planning meeting at the beginning, followed by daily stand-ups, a sprint review and a retrospective at the end. They also plan to deploy at the end of each workday. Let’s assume there are no deployments on the first and last day of each sprint due to planning and reviews. That means there will be 13 deployments during each 15-day sprint.
The basic philosophy is that whatever is ready at the end of each day gets deployed (preferably using an automated build and deploy tool). So one day’s deployment may contain nothing more than a bug fix while another day might include multiple stories and fixes. The team shouldn’t feel pressured to include something new in every daily deployment. Only changes and additions that are ready to go, if any, make the build.
So what does this approach accomplish? Why bother?
The answer depends upon your situation. The approach works best for cloud-based software systems. Using it in embedded systems or desktop applications development presents additional challenges that may prove insurmountable without a highly-efficient deployment system.
When the approach can be used, it gets new software into the hands of real people sooner. The feedback cycle accelerates. The deployments may occur on production systems or even on pilot/evaluation systems. Either way, new software will be exposed to business users and/or customers early and often.
There’s always a dark side.
The disadvantage to this approach lies in the feedback cycle. We want real people to use the new software right away and provide us with almost immediate feedback. If they do so, they’ll want feedback too. If someone finds a bug, they’ll expect it to be fixed quickly. If a new feature is confusing or burdensome, they’ll want it corrected right away.
This expectation has to be either reset or met. Resetting it means telling people that you want their rapid responses yet your team will take some time to evaluate and reply — not exactly a two-way street. Meeting the expectation means potentially disrupting the sprint plan — some stories may have to be moved to the next sprint. Flexibility is required.
You can make it work.
Whether your sprints are 1 week, 4 weeks or anything else, you can choose to deploy daily, weekly or at whatever interval works for the team. The approach encourages collaboration among the technical and business teams.
One last benefit is the reduction in Scrum overhead. Some teams don’t like to make sprints too short because they spend too much time planning and reviewing. If you deploy more often within each sprint, you don’t have to take on the added overhead that goes with traditional Scrum deployments at the end of each sprint.