What if the servers break down?

Hello,
In my opinion is a bad idea that the development team that is adding new functionality to the product is also responsible of maintaining the product in Production environment. Working this way the team will be continuosly affected on his sprint goal for events outside the Sprint. This is something that the SM should manage with the Managment.

Regards,

Julio Mieza del Val

IMO, dev teams should also support their systems in production. They should "eat their own dog food." Said another way, by having dev teams support production, the dev teams get maximum transparency on the decisions they make, esp wrt quality and customer satisfaction.

Stephane,

See here for one way to handle production support issues that you describe:
http://ScrumCrazy.com/bugs

Charles,
You are right and maybe they should eat that food, but I think this is againts the SCRUM framework, because none of the tasks needed for put the server up (incluiding hot fixes) are in the Sprint Goal, and the dev team has to work only on the tasks of the Spring Goal in the whole Sprint.

Making the team working on task outside the Sprint Goal is a wrong approach for releasing SCRUM in a company, it would affect the sprints for sure.

Regards,

Responding to emergency Production Support issues could be a part of the Sprint Goal, yes?

The Sprint Goal can be just about anything a Scrum Team thinks is valuable.

Charles,
As far as I know The Sprint Goal is an objetive set for the Sprint related with the implementation of 1 or more items of the Product BackLog. If we add in the Sprint Goal this kind of unpredictable, unknow and unestimated tasks its going to be very difficult for the team the commitment necesary for finishing the tasks that really are adding value to the product.

Regards,

If the server breaks down, would the Development Team still be able to deliver a potentially releasable increment?

If not, then the problem should be regarded as an impediment to the Sprint Goal and handled accordingly. The Scrum Master should take a lead on resolving the matter, and the Development Team should self-organize to find workarounds. This may involve finding alternative release environments and/or renegotiating the Sprint Backlog with the Product Owner so the Goal can still be met.

If the server hosts the Product, then the PO would also have an interest in resolving this matter, such as by resourcing alternative hosting infrastructure.

In the team I work in, this is a constant issue. We are both responsible for delivering new functionality using the Scrum framework, and the (technical) support for keeping the production environment of our system up and running, including 24/7 (standby) support.

My employer says it is "DevOps" and I (the scum master) call it a pain in the *ss, but it is something we have to deal with. After a few sprints we know how much time we require for keeping the system up and running and take this into account when planning the sprint. If there are a lot of incidents I discuss the issue with PO and together we decide which stories can be dropped from the sprint.