Implementing scrum in a multi-product environment

One of the challenges we have faced since the start of our journey of implementing scrum, is how to be true to the scrum process whilst operating in a multi-product environment.

Scrum is built around the principles of ongoing sprints with a product backlog involving a single product, or at least, a single product owner. In this environment, the process of build-fix-improve is made easier by the fact that there is always the next sprint right around the corner, with a product owner as an integrated member of the team.

In our team, we have responsibility for a multitude of products, encompassing a number of product owners across a number of organisationally and geographically disparate departments. The product owners are not able to take much time out from their normal duties to sit in with the development team, and sprints on a particular product can be separated by many weeks or even months.

So, what do we do? The ultimate answer is I suspect still unwritten. However, for the moment we ensure that we are at least able to chain a few sprints together back-to-back, try to ensure that each product is slotted into our sprint cadence sufficiently in advance to be able to book required time with the product owner, and ensure that the last sprint in a chain is structured in such a way as to allow for the fact that the subsequent release will be the last for a while. Any bugs after that point are slotted into our support and maintenance time to be treated the same as the rest of our support work.

One challenge we still face is dealing with the effects of the planned slots having to move due to changing organisational or emergency requirements. This has led to us having to carefully negotiate the prioritisation of various projects with each Product Owner, but this has been, so far, a very amicable and positive experience.

One of the impacts of splitting sprints is that of context switching. We need to find the right balance between being able to shift things around and finding enough chains of sprints to get back up to speed and productive on a product. I suspect I will blog more about this as the year goes on!

Leave a Reply

Your email address will not be published.