Our scrum product team is ready to release, but releases are delayed by the creation of training materials and business documentation

Question

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!

Answer 1

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.

Answer 2

The general advice that I'd offer is get these stakeholders more involved in the Scrum events.

For training, getting the training documentation embedded into the product would be good, I think that would only be a partial solution. Get the people who are writing training content involved closer to Sprint Planning to see what changes are planned, throughout the Sprint as changes are implemented and integrated, and at Sprint Review to see everything. The more closely they are aligned with evolving the training material with the development of the product.

For socialization with stakeholders, since this is an internal system, having a staging or pre-production environment for regular feedback is a possibility. Involvement at the Sprint Review to synchronize with the Scrum Team would be helpful. It is important to not let the Sprint Review turn into just a demo. The primary purpose is to synchronize on changes and adjust the Product Backlog to reflect the changing environment.

Sprint Review and Sprint Planning are good opportunities to handle the key aspects and approvals from senior leadership. Senior leadership is almost certainly a key stakeholder who should be involved at Sprint Review, but also understanding the Sprint Goal and selected Product Backlog Items out of Sprint Planning can keep them closer to the ongoing work to be able to more easily understand and approve changes when necessary.

I'm not sure what organizational policy changes entail for your organization, but incremental change management can be helpful. Incorporate as much of the change management process as possible into your Definition of Done for each Product Backlog Item. Some things may make sense to do on a per-Sprint or per-release basis rather than a per-Product Backlog Item basis, but shifting as much as possible to a continuous process can help reduce code freezes and be able to deploy changes faster.

Answer 3

A few suggestions:

• Release behind a toggle - this allows you to test in production, but without making the release visible to the customers
• Get the people you need to train involved earlier in the work, for example they could take part in user acceptance testing
• Speak with the people responsible for change control and explain the agile approach to them - suggest they look at ways to speed up the process