Question:
I recently had the following exchange that may be fill in some gaps in understanding how to use Scrum.
“You have been quoted in PSM classes as saying: “A Scrum project is only one Sprint long. A release of software may be the sum of multiple increments (and previously developed software, if any), or there may be multiple releases of software within a Sprint. A Scrum project cannot fail, only deliver unacceptable return on investment.” – Ken Schwaber
I have a question about that part: “[…]or there may be multiple releases of software within a Sprint … ”
- What did you mean with it?
- Is that an answer how continuous delivery works in scrum?
- What sense has the review then in scrum, when we deliver bevor the end of the iteration?
- Is the role of the review to inspect the impact of the during the sprint delivered value on the market?
- Should we have mini reviews within the sprint?
- Which Impact has the early delivery on the sprint plan and the stability of the sprint?
We managed the complexity in scrum in timeboxes.
- When there is need to deliver faster, why shouldn’t we short the sprint, even to one day?
- Why couldn’t the sprint length be dynamically adapted, during the sprint – I don’t mean sprint termination?
When the read your initial quotation and ask: are not we not close to Kanban, then, maybe?
Thanks
Anonymous
Questions followed by my replies:
- Is that an answer how continuous delivery works in scrum? That is a way that continuous or frequent delivery can be done within a Sprint.
- What sense has the review then in scrum, when we deliver before the end of the iteration? We choose what do set as the goal and focus for the next Sprint, as well as whether to fund the Sprint or not. Reviewing software is part of that decision.
- Is the role of the review to inspect the impact of the delivery during the sprint delivered value on the market? Could be, or just to see if the Product Owner can see it potentially being useable.
- Should we have mini reviews within the sprint? Not a bad idea. Nothing in Scrum prohibits it.
- Which Impact has the early delivery on the sprint plan and the stability of the sprint? They probably become more dynamic, but they do not shorten the Sprint.
- We managed the complexity in scrum in timeboxes.
- When there is need to deliver faster, why shouldn’t we shorten the sprint, even to one day? Go to a biology laboratory and see what rats going around in a wheel look like. A one day Sprint has a lot of overhead, as well as having to continually refocus. Bad idea.
- Why couldn’t the sprint length be dynamically adapted, during the sprint – I don’t mean sprint termination? The idea of Scrum is to grab a chunk of chaos and make it malleable to some degree of control. Your suggestion removes that and causes people to have to rethink prior decisions too often.
- When the students read your initial quotation and ask: are not we not close to Kanban maybe? If they are in a complex situation and try Kanban, they have instituted functional swim lanes, removed cross-functional dialog. Then they start with the metrics and optimize within the Sprint, rather than doing the best they can. Remember that the strength of Kanban is managing to optimize regular but complicated operations, not complex, unpredictable creative work.
Scrum on,
Ken
