Release sprint most crucial for Big projects

> 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.

Are there any automated test? I would also be afraid to release a mission critical software continuously without any automated tests :-)

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?

> 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.

>>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.

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.

In our organization, Scrum was introduced for a couple of development teams, but the whole company isn't (yet?) very agile but still a bit “waterfully”. Especially with the "real" releases, approx. twice a year, there are a large number of additional release steps and required documents that we would never be able to deliver ) - in terms of time and in terms of personnel Other department resources – with every “normal” sprint release (i.e. presentation and trying out in the review for the stakeholders.

This causes enormous additional stress in a "real" release, because not only does it have to go through the automated tests, but also a lot of manual tests with a large number of connected laboratory devices (which we do not all have permanently available), with manual controls by experts in the laboratory departments (which do not have time for extensive full tests at every sprint) - and with the "argument" whether, for example after finding and fixing bugs when testing a "Release Candidate-1", all manual tests have to be carried out again (even if not all components are affected by a bug fix) - or if the extensive automated tests are not run through is sufficient.

Specifically, the product management department demands that we have to test every further “Release Candidate "again completely - also manually - before the approval is given, since they do not accept bugs in the version they are looking at - for the purpose of a final user acceptance test. (Note: They anyway have a look at every sprint increment to evaluate the software from a user perspective).

Do you have experience with such problems? And also how to deal with an organization and general conditions that we can't change so quickly, but can still make agile software releases?

Thank you for your tips and considerations

Daniella

Any manual process greatly slows down flow.   This is even more evident within an Agile framework like Scrum.



Until you automate the manual processes in your software delivery workflow, nothing you try differently (such as Agile) will have much effect at all.

My advice is to work on automating your test process, and then begin considering how you can reduce or eliminate the many toll gates in your delivery workflow.

Thanks - we discussed this also in the last Retrospective and the team (including PO) agreed in enhancing the areas of test automation (also including test benches with our different decives and as much as possibole end-to-end tests...).

But still the problem with reducing / elimitating the other  toll gates - I like the expression!

I will see how I can reach our stakeholders best to convince them...

I'm going to share a slightly different perspective.  A Sprint produces a potentially releasable increment of value.  When and how that is released is dependent on many factors.  And there is nothing in the Scrum Guide that says the framework will make your ability to release to the public be faster. It just helps to ensure that you are able to consistently release high quality work that is wanted/needed by the stakeholders.  

In my opinion, your team's release is to the process needed by the organization to support your "real release".  You are still delivering potentially releasable increments of value to the stakeholder on a cadence that is sustainable and predictable.  In this situation, the stakeholders are the people controlling the "real releases" or your company in general and not the end users. Modify your expectations to reflect the reality of your organizations need for a controlled public release and focus on your abilities to consistently get as much value into those public releases as possible. 

I very much agree with Daniel Wilhite's comment above.

Too many people associate "release" with putting the change into production where it's visible to end-users. However, that's not always the case. If you are building a complex hardware/software system, you may release the hardware and the software to an integration team that produces the next iteration of the system for integration test and then release to the end-user. If you're in a regulated environment, you may release your work to a team responsible for formal validation. Or you may just be working with a customer that cannot tolerate change at the rate the developing organization can provide it and the release is to a staging environment.

Focus on ensuring that each Increment is something that could move to the next steps in the process without impeding those people from doing their job. If you're handing your work to a systems integration team, they should be able to integrate your product with other products with very high confidence. If the next step is formal validation, the Increment should pass through validation without any significant findings. If the next step is a staging area, it should be useful as a demonstration of the current state of the product under design.

Regardless of who you release to, involving the downstream stakeholders into review and feedback loops and responding to that feedback can make the application of agile methods useful to the organization.