Multiple increment delivery within a Sprint

Categories "Done", Kanban, Professional Scrum Master, Scrum 9 Comments Tags , ,

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:

  1. 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.
  2. 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.
  3. 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.
  4. Should we have mini reviews within the sprint? Not a bad idea. Nothing in Scrum prohibits it.
  5. 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.
  6. We managed the complexity in scrum in timeboxes.
  7. 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.
  8. 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.
  9. 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

9 thoughts on “Multiple increment delivery within a Sprint”

  1. Multiple deliveries and potential release points can represent multiple opportunities for validated learning. When faced with a complex problem and the need for creativity, this feedback can help to control risk so meaningful Sprint Goals are better met.

  2. “If they are in a complex situation and try Kanban, they have instituted functional swim lanes, removed cross-functional dialog”. This is a misunderstanding, Ken. The columns on a Kanban board are simply there to make the process more explicit, better than a mere “doing” column can. If you add Kanban to an existing Scrum environment, the team can detect bottlenecks when the WIP limit in a certain column is hit. If you simply have a “doing” column and you get a congestion there, you only know that you have a problem in “doing” (which is a pretty useless information for the team).

    All this has nothing to do with “removing cross-functional dialog”. Nobody in their right mind would want this.

    • Hi Matthias,

      My two cents below — welcome your thoughts in response.

      When you apply additional columns you risk trying to represent a complex problem in an overly simple way. While this may have its benefits, if your process is designed around linear sequential flow, are you really able to effectively utilise all of the opportunities to inspect and adapt?

      If we take a simple flow: Ready -> Unit test -> Code -> Integration -> System test -> Code Review -> Deploy -> Monitor

      I think that as more is learnt about the system, the problem and the solution, there is high probability that we learn that the work that we previously believed to be “done” as represented by a column simply isn’t good enough, or “done”. In the flow above, it seems reasonable that the code review could uncover issues with the unit tests, or the code. The ‘system testing’ phase could disprove the fundamental viability of the proposed solution, and work may need to go back to the start.

      The issue is that in a complex problem space, the exact approach to solving the problem cannot be ‘stamped out’, and the flow between different ‘states’ can vary substantially from one solution to another.

      I understand the benefits of being able to identify bottlenecks in a system, but I would be concerned that if this is important to a Scrum team, it is systemic of other problems, such as functional silos within the team.

      This is not to say that a team should only have a “doing” column, but that I don’t think I would expect a healthy team to need many additional states to represent their work. And if they do, I would have concerns over these columns’ ability to accurately reflect that state anyway.

      In less-than-complex systems, this undoubtedly changes substantially.

    • Ken is talking about swimlanes, not columns.

      Example definition: “A swimlane is a horizontal categorisation of issues in the Active sprints/Kanban board on a board” – Atlassian

      These categorizations will typically vary the quality of service in some way, such as by means of functional specialization. I suspect that’s what Ken is referring to.

  4. Interesting points, I agree with what you’re saying about Scrum/Continuous Delivery. Scrum sets the work tempo, delivery is about when you release value to the customers… that could be nightly, at the end of each Sprint, or after several Sprints.

  5. Pingback: Studying for the Scrum PSM II Exam – Thoughts on Software Management and Development

  6. Pingback: Increment - Solution Delivery Knowledge Center

Leave a comment