Forums

By posting to our forums you are agreeing to the Forum terms of use.
Release sprint most crucial for Big projects
Last Post 23 Jan 2014 11:52 PM by Ian Mitchell. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Samridh
New Member
New Member
Posts:2
Samridh

--
18 Jan 2014 12:19 PM
    After end of every sprint there should be potentially releasable increment.
    But for big projects release sprint might be crucial before final release .
    More work and evolution is required for release sprint and it should include one more round of testing.
    For Example,dream project of Airbus Dreamliner taken a hit due to battery issue .It might would have been possible each n every component was tested but adding one more round of testin can save issues and brand image later..
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:571
    Ian Mitchell

    --
    18 Jan 2014 02:25 PM
    > for big projects release sprint might be crucial before final release

    If a "release sprint" is crucial, then by definition any previous sprints cannot have yielded a potentially releasable increment, and the rules of Scrum are not being applied. The rationale you describe has a greater affinity with non-agile frameworks such as SAFe.

    > adding one more round of testin can save issues and brand image later.

    If that is true then technical debt has been incurred. It is likely that the Definition of Done was inadequate prior to that round of testing, and therefore it should be challenged and improved.

    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    19 Jan 2014 07:09 AM
    Are there any automated test? I would also be afraid to release a mission critical software continuously without any automated tests :-)
    Robert Zuurbier
    New Member
    New Member
    Posts:2
    Robert Zuurbier

    --
    21 Jan 2014 10:18 AM
    I can see Samridh's point: when developing independent new increments over several sprints, but only releasing them together at the end of a 'project', you would like to test the whole project, right?

    Does anyone have experience with 'saving' increments for a bigger release? Or would this strategy be contrary to Scrum and therefore not be used at any time?
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:571
    Ian Mitchell

    --
    22 Jan 2014 08:40 PM
    > Does anyone have experience with 'saving'
    > increments for a bigger release?

    This is quite typical of "waterscrumfall" and it is regrettably very common. There will be very few releases...perhaps just one at the end of a project. This is often a symptom of trying to apply Scrum within a stage-gated organizational culture, where Scrum is applied to software development but not to integration testing or delivery.

    > Or would this strategy be contrary to Scrum
    > and therefore not be used at any time? 

    It's contrary to Scrum because Sprints would not result in increments that are potentially shippable. The Definition of Done is correspondingly far too constrained, and fails to address the full journey into production. Inspection and adaptation is compromised, both at the product level (wthich is not released in a timely enough manner to provide incremental feedback) and also at the process level, in that Scrum Teams are constrained by the rules of a dysfunctional organization, and cannot change its non-incremental approach to delivery.
    MrHinsh
    New Member
    New Member
    Posts:17
    MrHinsh

    --
    23 Jan 2014 05:15 AM


    >>Does anyone have experience with 'saving' increments for a bigger release? Or would this strategy be contrary to Scrum and therefore not be used at any time?

    It is very common and often required by marketing teams to roll up many increments into a larger public release. This is perfectly acceptable in Scrum as long as your increment is available for your Stakeholders to access to provide you with feedback. You need to be able to inspect and adapt every cycle and Scrum does require, although not explicitly stated, that your software be released.

    Released however means many things to many companies. Worst case only your Product Owner has access to the new increment. I would then recommend that your PO takes that increment and actively solicits feedback from as many people as possible to make sure that you are building the right thing. That means all you stakeholders: Managers, Coders, Testers, Sales, Marketing, Users and anyone else that interacts with that software.

    It is not contrary to Scrum to do what is best for your business. Just be careful and mindful that it would be contrary to Scrum if only the Scrum Team (Development Team + Product Owner + Scrum Master) saw the increment Sprint on Sprint.

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:571
    Ian Mitchell

    --
    23 Jan 2014 11:52 PM
    In Scrum each Sprint should result in a potentially releasable increment. However the target consumers of that release may indeed vary.

    For example it's fair and reasonable to limit a given release to a certain market segment. This might be done in order to sandbox a new Minimum Viable Product before general release is sanctioned.
    You are not authorized to post a reply.


    Feedback