Scrum eq no time for training
When can we fit training and migration to newer technology/designs within Scrum?
We are highly engaged in promoting Scrum in all aspects of the business and developers have improved their happiness, effectiveness and understanding 5x.
The issue we are finding is the teams are performing so highly, that's there is no time to research, training or trial new technology. For example, we are using an old DAL system that causes a problem in most sprints. However, the team has no experience working with newer DAL technologies.
As a team must have the skills and ability to complete all work forecasted within the Sprint, we can't add a BPI to solve this problem. Also, we should have a valuable increment. But R&D might not produce anything tangible or deliverable.
My suggestion is that we focus on implementing a new DAL to complete a single BPI item that's hitting the Sprint. Instead of using the old DAL, we focus on a small increment of value. During this process, the team will learn different technology at the same time as bringing visible value. However, in refinement we are finding that this is being broken into multiple BPIs for research, trailing, PoC and takes the full sprint, without any tangible increment.
In short, the team are performing so highly, that any deviation from their "know stack" will cause a drop (training, R&D, new architecture/frameworks).
I am interested in reading how other PSPOs and PSM are solving the problem of implementing new technology within a Scrum Team that is not currently competent/trained is said tech.
Thank you in advance.
There are lots of different ways to build this type of thing into Scrum.
Training can be done through a number of mechanisms, depending on the type of training. A simple way is to reduce the capacity of the team on a Sprint-by-Sprint basis to allow people to take time out of their day to do training and education. If there is a formal training session or class, this can be fit into the schedule specifically, otherwise it can be a specified level of effort devoted to training. The Sprint Retrospective can also be used to share knowledge, although I would want to make sure that some time is spent to reflect on the way of working, identify problems, and make concrete process improvements. If the education is closely related to the product, it can be built into refinement, either as a level of effort activity (similar to the reduction in capacity) or using Spikes, with the knowledge disseminated throughout the team as part of the Definition of Done for a Spike or through the Retrospective.
Exploring new technology that has a direct product impact is probably best done through the Product Backlog. Even if the product is not directly changed as a result of completing the work, completing it could have an impact on the Product Goal, the Product Backlog, or how the architecture and design of the product evolve over time. The Product Owner should be able to prioritize this work with other valuable work by expressing the potential customer or user value in doing it. Spikes are a good way to manage this, but failure to maintain your underlying architecture, tools, and technology is also a form of technical debt. If you don't pay back technical debt on a regular basis, you'll owe interest on it in a number of forms.
If I was in your specific situation, this is the approach that I'd likely take:
First, I'd suggest a Spike to "explore alternative DAL technologies" and timebox this effort at a Sprint. I'd want at least two Developers on the team to pair to work on this research effort to understand what's out there. This could mean upgrading the existing DAL system to a newer version or replacing it with something else. The initial efforts should produce a few options that make sense in the given context. I'd use either the Sprint Review or the Sprint Retrospective (or both) to communicate the findings to key stakeholders and the Scrum Team to make a decision on what to do.
The outcome of this guides the next steps. They could find that the DAL system used is actually good enough, but perhaps needs to be updated and the team needs to spend more time learning its capabilities. In this case, I'd suggest scoping the work for a technology upgrade and then education for the team. If the decision is to replace the system, I'd suggest that the team use some of their Refinement time over the next couple of Sprints to start to think about approaches for this work and create Product Backlog Items that can be ordered to do it, with some being research and prototyping and some being delivered changes to the product. Perhaps there's a way to slowly migrate to the new system or changes that can be done to make it easier to abstract the existing system and replace it or additional test automation to increase confidence in the work.
The one thing that I would encourage is visibility. For example, if you create a prototype, don't hesitate to talk about the prototype in the Sprint Review and how you can take what you've learned to improve the deliverable product. Be sure to explain to stakeholders, in their language, what the benefits and value in the work is and what the cost of not doing it is so they can understand what they are paying for and make informed decisions about the state of the product and Product Backlog.
we are using an old DAL system that causes a problem in most sprints. However, the team has no experience working with newer DAL technologies.
How would those new technologies impact the Definition of Done?