Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Code Deployment
Last Post 28 May 2014 04:59 AM by Ian Mitchell. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Abhijit Kundu
New Member
New Member
Posts:10
Abhijit Kundu

--
25 May 2014 11:00 PM
    When delivering a Sprint ---Does the actual code deployment in production take place before or after the sprint review meeting?
    And when does the retrospective take place in respect of live code deployment?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1543
    Ian Mitchell

    --
    26 May 2014 01:37 AM
    Each Sprint must deliver a potentially releasable increment to the Product Owner. The matter of release is therefore orthogonal to the work done in the corresponding Sprint, and is at the discretion of the PO.

    Note that this does not preclude the possibility of making a release, or indeed multiple releases, during the Sprint itself. Also, there's nothing to stop the Development Team from making the deployments if both they and the PO are willing to support that arrangement. The important thing is that, even when something like continuous deployment into live is in force, the PO has ultimate control over each release configuration and can therefore account for the Return On Investment each one yields.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    26 May 2014 01:40 AM
    Hi Abhijit,
    deployment is not part of Scrum, because Scrum is a framework for developing products, not for delivering them.
    This means, the deployment in production happens whenever the Product Owner feels like it. Usually he will decide this after the review, because then the product increment is transparent to him.
    The retrospective takes place directly after the review. Again, deployment is not part of Scrum and should be decoupled from the Scrum events in order not to become an impediment.
    Abhijit Kundu
    New Member
    New Member
    Posts:10
    Abhijit Kundu

    --
    27 May 2014 08:33 PM
    Thanks Mitchel and Ludwig.. In similar lines, this is a typical question with options..

    When should the Product Owner ship or implement a Sprint increment?
    A. At the end of every Sprint.
    B. When the Team feels is done with every Sprint.
    C. Whenever the increment is free of defects.
    D. When it makes sense.

    My pick is Answer D..

    What would you guys feel?
    Kelly Hellinx
    New Member
    New Member
    Posts:6
    Kelly Hellinx

    --
    27 May 2014 10:26 PM
    My answer would be D too.

    A - It's not necessary to release the increment. I can be done, but it's not mandatory.
    B - It's up to the team to provide a possibly releasable increment but the team doens't get to decide when to actually release it. That's up to the PO.
    C - The increment should be potentially releaseable. Your definition of done should say that it's free of known defects. TDD should help in that.
    D - When it makes sense to the PO, he/she can release an increment whenever he/she feels like it. Seems like the most logical answer.

    HOWEVER:
    In some (most?) environments, the people who work on the increment (Development team) will also be the ones that release it.
    Releasing software takes time and preparation.
    So if the PO decides to release it, one or more people on the team will invest time in it.
    This will affect the velocity of the team during the sprint.
    How should one handle that?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1543
    Ian Mitchell

    --
    28 May 2014 04:59 AM
    > Releasing software takes time and preparation.
    > So if the PO decides to release it, one or more people on the team will invest time in it.
    > This will affect the velocity of the team during the sprint.
    > How should one handle that?

    Each increment *must* be potentially releasable. If sufficient time has not been spent in preparing for release, then the potential for doing so can't be there, and the Definition of Done is either inadequate or is being improperly applied. With a good DoD, if the PO decides to release then the implementation of that decision should take negligible time.

    The original question is a bit harder that one might suppose, because both A and D are valid answers. A is valid because a PO should not negotiate a sprint backlog or goal without release being the aim. The PO *should* therefore release at the end of every sprint, even if it is not mandatory to do so. Remember that in Lean terms, a failure to release increases batch sizes and the depreciation of stock-on-hand.

    However, if we are limited to one answer only, then D is certainly the best. A PO should never release if it doesn't make sense to do so.
    You are not authorized to post a reply.


    Feedback