Our scrum product team is ready to release, but releases are delayed by the creation of training materials and business documentation
I'm working with a product team in a scrum environment developing products for internal workers, and we are experiencing some tension between our team's ability to deliver, and the business' need to train and equip users.
Can you point me towards any scrum resources or articles that help teams reduce the amount of overhead and documentation surrounding the launch of a product increment?
I think there is an appetite for migrating training into our product so we can have "living training" as opposed to creating it manually for each release, but I would love to learn more regarding best practices in this area.
I've used training as an example, but there are many tasks that currently happen after the completion of a product increment that slow us down from actually releasing, including:
- Training Users
- Internal Communication and socialization with stakeholders.
- Our POs do have great autonomy and authority to make decisions, but rarely certain aspects do need approval from senior leadership.
- Organizational policy changes and change management
What I'm really trying to avoid is long "code freeze" periods, where increments are paused so that we can develop the above materials & change management.
Thanks in advance!
This is something that's a problem for my organisation. Here are some things we do to make it less problematic:
Use a Release branch in source-code management (including the sources of documentation) so that future feature work can be committed and tested on the Develop branch without needing a full code freeze.
Regularly review the team's Definition of Done (either as part of Retrospective, or as a separate activity) to discover activities done for release that could (should) be part of a feature ticket.
Begin each story by having a Start-of-Story Conversation between the developer taking responsibility for the ticket and one or more other team members to identify what testing, documentation, policy update, approvals etc. need to take place as part of the story. This is also a good time to consider other impacts of the work, such as likely risk areas for regression.
Perhaps your policy updates and training can't actually happen until your product is released. But having prepared these as part of feature work, then the release activity is reduced to gathering together all the prepared pieces for the features actually included in the release and packaging them for delivery.
Don't expect the Definition of Done to be perfect after your first time updating it - my suggestion to regularly review is important. I'd suggest that you have this review after each of the next few releases; you'll find work that could have been done earlier, enabling you to release with less overhead (more accurately, with that overhead moved to be part of the feature work, getting you nearer to the ideal of release on demand).
Our Start of Story Conversation uses a template in our team wiki, that has a checklist of things we should examine to double-check that the story is Ready, and that all the risks and supporting work are considered before starting development. It normally takes 2-3 developers around five to ten minutes to walk through this and arrive at a shared understanding of what's included in a story, and what needs to be complete before it can move from one state to the next. Again, it's a living document, and the items in the checklist will be specific to your team and updated as you discover (in Retrospectives) oversights that could have been asked about before starting. (Actually, we choose one of several documents because we work on more than one product, and we have an additional one for non-product work such as infrastructure updates).
We still need "release sprints" in our team, but that's an improvement from taking two or more sprints to release, and we're still finding ways to move work to the left, so we haven't reached our limit as we aim to be able to release on demand.