Agile Releases in a "semi-agile" Organisation?
(Note:I already posted my question here: https://www.scrum.org/forum/scrum-forum/5712/release-sprint-most-crucia… but maybe it's better to start a new forum topic? - I'm new here, so I do not know what is best, my apologies)
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
If work of release quality is only delivered twice a year, Scrum has not yet been introduced. Moreover, it is very unlikely that empirical process control has been established. Are these matters understood by the organization, and does the lack of empiricism present a problem?
It is not necessary for the whole organization to be agile in order to see some benefits from agility in the development organization, as long as the interface between the plan-driven and agile parts of the organization is well defined and managed. There are cases where the end-users or downstream customers of the output can't receive it at the same pace as it is produced.
In cases like this, it's important to identify what it means for the agile development teams to be "done" with their work. If this product is regularly integrated and done, there is a potential handoff into your formal release process frequently - perhaps as often as every Sprint, but it could go several Sprints. The requirement of Scrum is a potentially releasable increment at least once per Sprint. This doesn't necessarily have to come at the end of a Sprint nor does it have to be released for any downstream processing.
In a situation like this, I'd focus on figuring out what the team needs to produce high-quality products on a regular basis. It seems like simulators for devices would be good to improve confidence that the integrated product will work later on. Moving as much testing into automation would also be beneficial, even if some of that testing has to be redone manually later on. There may be ways to incrementally produce some of any kind of documentation artifacts or inputs to those documentation artifacts on a Sprint-by-Sprint basis, as well. All of these can be incorporated as process improvements in the Sprint Backlog or into the team's Definition of Done.
If you set the foundation for agility and quality, you can demonstrate value to the rest of the organization. If the owners of the downstream processes don't want to improve their processes, the product development organization can far outpace them. That is, the quantity of high-quality work that can be done in a release may be more than they can consume without significantly overhauling their processes.
Thank you for your feedback!
Concerning Ian’s questions: I would say that work of release quality is delivered much more often than twice a year, usually after every sprint (3 weeks) – and the sprint increment’s build is already used by our internal customers (other departments) using the new features for their daily work. But the "real" release to external customers requires so many more steps (because partly a regulated area) that the company only does it twice a year.
And to Thomas, yes, the product is regularly integrated and done, and you are right: There is a potential handoff into our formal release process frequently - actually in almost every sprint, although there is usually not a real release to external customers.
Simulators, we already use but unfortunately exactly the testing with simulators (which was in the last weeks partly the only option during the Covid-19 home office period) caused us problems during the last sprint before the release, because it did not find a performance bug that only occurred when several real devices were connected. In other words, we should definitely put more effort into improving our simulators so that they really create trust…
Concerning test automation: In the last Retrospective, the teams also decided to put a lot more effort into the test automation including load tests and performance tests (even if some of that testing has to be redone manually later on), and to have a number of the most important devices in permanent operation in the form of a test bench always running in every sprint.
So thank you for confirming that we are on the right track here!
And yes, it is important, to find ways to incrementally produce at least parts of the necessary documentation artifacts on a Sprint-by-Sprint basis – at least where our department is authorized to create them. It’s a good hint to include it as process improvements in the Sprint Backlog or into the team's Definition of Done, thanks!
As for the artifacts of the other departments, which will also be needed for a "real" release, I will try to clarify with my colleagues whether they might be able to do some things also earlier or maybe even create them on a sprint basis.
Perhaps in this way we will really succeed in gradually bringing the owners of the downstream processes to an “agilization” of their processes.
It is definitely worth a try (or more)!