Scaling Agile (but not in the way you think…)

Facebook

Twitter

Linkedin

For more than a year now, I’ve been working with clients that have agile scaling problems. But not the kind of scaling problem everybody is talking about – one product and lots of teams. No, I’ve been busy trying to sort out what to do when you have one team supporting a multitude of products with different architectures, stakeholders, technology stacks and whatnot. This is what I’ve learnt, so far.

I’ve googled and googled, asked people and read books that supposedly should describe this situation, but not with much luck. I have obviously read the wrong books/blogs/tweets/what-not, because I haven’t really found that much written about it. And if you look at my colleague Henrik Kniberg’s infamous video PO in a nutshell, it seems simple enough. But sometimes life isn’t as simple as in a 15 minute video 🙂

Why is this a problem?
Having a team that needs to develop and maintain several products results in a multitude of problems. Some are easy, some are harder.

The more easy problems are things like understanding the development environment. Different programming languages, different test and stage environments, different ways of deploying the products to the environments etc.
These kinds of problems are quite straightforward to solve. Try to make the ways of working with the different products as homogenous as possible. Document the things that are hard to remember, minimize the different technology stacks where possible and so on. This will of course be hard as different products might be from different generations. It is not unusual to see a mixture of PL/SQL based systems, c#, VB, Java, JavaScript and rails being handled by one team.

The biggest issue I have had to work with is not technological though. It is that teams working with several products tend to un-team and become silos instead. That is, Jane has been with this company for ten years, so she knows about the PL/SQL-system, so she solves all the things with that system. And then Joe thinks that rails is fun, so he tries to grab all work with that. And so on. Sooner or later, people have their favourites and forgets about how to work with the other systems.
Even worse, sometimes management, or perhaps the Product Owner, tries to enforce this behaviour. ”Well, Jane is our most experienced PL/SQL developer, of course she should work on that system.” Bye bye self organization and pull systems.

So what you get is not a team, but a bunch of people working with different things that happens to sit together. Planning meetings becomes tedious since different team members are only interested in their parts. The rest of the time they look at their phone or whack away at the keyboard, while the rest tries to have a meaningful discussion. They are now working in different silos within the team.

The Product Owner becomes a Team Owner
The Scrum guide is designed for having one development team, one Product Owner and one product to handle. In this setup, where there are a multitude of products, it becomes hard, if not impossible, for the Product Owner to be  on top of all stakeholders, visions and roadmaps, detailing User Stories, keeping tabs on the ROI, and all the other stuff a PO is supposed to do.

In order for the team not to break down due to task switching, it is important that the team knows what the focus of the sprint is. So priorities becomes even more important than normal. But it is not so much about priorities between User Stories for a product, it is about priorities between products.

This leads to the Product Owner becoming more of a Team Owner in the sense that she shields the team by making sure the priorities are straightened out before sprint planning takes place. She needs to make sure that all stakeholders goes to her instead of the team. She needs to make sure that all stakeholders are ok with the priorities between the different products constantly.

Suggested solution: time multiplexing
Let’s say you have 4 products that is maintained by one team, and that the sprint length is 2 weeks. If you choose to work with one product at a time, each product gets focus approximately every two months. How agile is that?

To make things even worse, I’ve seen sprints being ruined by a bug in production in another system than the one the team is focusing on. What happened then was that the stakeholders of the product that the sprint was supposed to focus on got very angry, and wanted the team to focus on their product in the next sprint, to compensate for this ruined sprint. And then all things crashes 😃

So one solution to this problem that I use is time multiplexing. That is, each sprint has a focus on one product, but have room for little things on other products as well. So, again, the Product Owner for that team must really get into details of things so that it is possible to deliver small things on a couple of products, and something bigger on the focus-product.

Incidents and bugs
Having seen the effect of what bugs in production can do to this situation, I cannot stress enough the importance of avoiding them. Invest heavily in automated testing, on all levels, to remove as much manual regression testing as possible. Test cases are also a good way of remembering what a specific product does. So browsing through test code is a fast way of giving you an overview of the product.

Also use mobprogramming, or at least pair programming to get more eyes on the code to avoid mistakes and getting rid of code reviews.

Suggested solution: split your team
At one client there was a team consisting of ten people, handling several products within different product segments. It was global user handling mixed with CRM-systems mixed with in-house back office systems. This was too much to make all team members understand what was happening in all different areas. The silos were very obvious, and people were demotivated by the fact that they had to listen to, estimate and discuss things they really had no idea what the heck it was. So the solution here was actually to persist the silos!

We split this team into three teams, were one became a CRM team, one became the global user handling team, and one team took the rest. This made at least two out of three teams able to focus wholly on one product, while the last still had to be able to handle many products. So they focused on unifying architecture and technology stack where possible.

The result was happier people, effective meetings, and better output. Team members finally knew what their focus should be.

Summarizing
Scaling agile isn’t only about using the latest scaling framework to know how to make a release with 100+ teams. Sometimes, you have to handle a situation were it is the number of products that have scaled. I have tried to solve it with splitting big teams and trying to avoid silos within the teams. Also, by having focus on one product per sprint but allowing minor changes to other products as well, you keep some agility at least.

This is based on my experiences. I would be glad if you would like to share your’s, or point me to sources of information that I have missed!