deploying mid-sprint with scrum (large ongoing 'brownfield' public web projects)

Question

Schwaber & Beedle's 'scrum' book (and the other scrum literature I've read) seems to focus on having a releasable product by the end of the sprint. Web development for an established site (at least in our case) consists of developing 'enhancements' (of various sizes) and many small 'fixes'. Deploying (to web) only at the end of the sprint would slow down our deployment of large enhancements (probably a good thing) but would dramatically slow down our deployment of small enhancements and fixes (i.e. the bugs hang around longer).

Are mid-sprint deployments heretical in scrum? Are sprints even applicable in our case? Have I misunderstood sprints entirely?

Answer 1

I really think deploying to production mid-sprint sounds like a bad idea. A real focus-stealer.

Maybe shortening the sprint length would be something for you ?

Answer 2

If you want to perform a strict-scrum driven development - then mid-sprint deployments are heretical. In my opinion is a strict-scrum approach not the best tool to use for scenario. I'd use a more classical approach where you have defined deployment-packages and tasks appointed to them. you develop on a single trunk and if all the tasks for a given deployment-package are done - you deploy it. But be aware of constraints within your code and project.

Answer 3

You could have a look at Alistair Cockburn Crystal "Orange Web" method. He adapted agile principles with the public web site constraints.

Answer 4

The completed work at the end of a Sprint has to be reviewed by the product owner during the review meeting. If you release mid-way, this may not be the case.

If you feel that the work is complete before the end of the sprint you can:

1. Add more work by picking highest priority items from the release backlog
2. Shorten future sprints

Given your work environment description, I would opt for 2.

You may also want to consider another agile methodology that may be more appropriate to your environment.

I would not release mid-sprint.

Answer 5

Having releasable content at the end of a sprint does not preclude mid-sprint releases. In fact, when your team has production support responsibilities, it is required.

I would ask a few questions about these mid-sprint releases though:

1) Does the incremental value of earlier release exceed the cost of deployment? 2) Have you assessed the risk of each of these mini-deployments to ensure they don't backfire and create more work? 3) Can you get customer feedback for these mini-releases to ensure you're releasing what they want? 4) Have you considered shortening your sprints?

"Strict scrum-driven development" (proferred above) is, to me, an oxymoron. The mantra is inspect and adapt. I chaffe at the suggestion that scrum is being wielded as a doctrine against improved responsiveness to your stakeholders.