Managing a Multi-Product Agile Team

Posted on by

Most agile sites and training do a pretty good job of telling and showing you how to manage a single product team. After all, having an entire development team (which would include product owner/manager, analysts, developers, testers, documentation) focused on a single product (or possibly a subset of a product) is very ideal. Unfortunately, those of us in a small company may not have this luxury. We are often in an environment that we have multiple products that we market individually and maybe together as a suite but only have one, maybe two development teams working on them. How do we manage a scenario like this? Which products do we focus on when? Which features for which products should we work on next? How do we get everyone working together to ensure we are getting through the highest priority items? I definitely don’t have the definitive answers to all these questions, but I can share some practices and techniques that I have tried. Please let me know if you find any of these useful or if you have any other techniques that have worked for you in situations like these.

Product Owner and Backlog per Product
Having a Product Owner (or Product Manager) per product sounds fairly obvious, but it is definitely not always the case in the environments described above. Often in these cases, since your products greatly outnumber your development team, you will have fairly extensive product backlogs. Since you only really have one development team, you may be tempted to try and have one product owner for everything and keep one backlog. With such an extensive backlog, doing this becomes very burdensome and overwhelming. We’ve found a much more manageable approach is to have a product owner for each product and keep the product backlogs separate. As always, the product owner is responsible for keeping his/her backlog prioritized and groomed, but having multiple smaller backlogs makes it much more manageable.

Use a Release Backlog
There are many people out there who will say that release backlogs should be avoided. This post on Mike Cohn’s blog is a prime example. If you are in the ideal state of one team focuses on one product, it makes perfect sense. However, in our case, with one development team but multiple products, a release backlog has come in very handy. As the previous section mentions, we maintain separate product backlogs for sanity’s sake, but since we really have one development team, we do still need to combine this into one comprehensive backlog at some point. The release level seems to make the most sense for this combined backlog. Prior to a release we will have a Release Planning meeting with all the Product Owners during which we will pull items from each product backlog into a single release backlog and prioritize the release backlog as a group. Nothing gets added, removed, or re-prioritized from the release backlog outside of a group meeting. We then meet just before the end of every sprint to quickly review progress and discuss any potential changes desired to the release backlog.

Focus
As I mentioned in a previous post, focus is very important. With such extensive backlogs, you need to find any way possible to focus your development team. One of the newer things we are trying on our team is putting more emphasis on setting sprint goals. We try to pick one or two “themes” to focus on for a given sprint. This has the side effect of often limiting a sprint to work on one or two products, but not always. However, it does seem to be doing a good job at helping provide focus to the development team and help keep them from feeling that they are constantly jumping all over the place doing one seemingly random ticket after another. The other very important thing to help with this problem is to ensure the problem and intent are well documented within every item on which the team works. What is the problem this story is solving and how does it fit into the overall strategy and vision of the product? Grouping the stories into themes often helps provide this to a degree, but don’t take that for granted, always be sure this understanding is there.

Conclusion
Small software companies can present unique sets of problems that are not always talked about often as most sites and training focus on large organizations and large teams. Many sites talk about how to spread agile practices across a large organization and how to scale to multiple agile teams, but what do you do when there seems to be enough work for multiple teams but expanding at that pace just isn’t feasible at the current time? As I mentioned at the beginning, I definitely don’t have all the answers here, but these are some things we are trying that seem to be helping. They are all in different stages of maturity, some fairly new, so I’m sure we’ll change things around in the future as we learn what works and what doesn’t. I’m very interested to discuss these sorts of problems with anyone else that may be experiencing them and exchange ideas. If you use any of these ideas please let me know how they work out for you.

  • Waldemar Antonowicz

    Hello,

    that’s a good point of view and some really helpful ideas. In our company we are dealing with the same problem – small team and 3 different products (combined in one suite). While your ideas seems to be good to try in our team we can’t find a good solution to manage critical issues. Critical issues have about 1-2hr due time (e-commerce system) and each time they occur we have to break out the sprint. It’s really hard to be agile and solve the ‘criticials’ aat the same time :( Any ideas on that?

    Regards

    • http://www.developmentblock.com Matt Block

      Hi Waldemar! Yes, it is indeed hard to be agile and deal with critical issues. We struggled with that exact issue as well. Hopefully, moving to agile will allow a focus on quality that will decrease the occurrence of those critical issues :) I will assume you are doing scrum since that is what it sounds like. While there are many possible solutions I will focus on the first thing I would try.

      I will start by saying missing a sprint commitment occasionally isn’t bad. In fact, I would argue that we want to miss occasionally, if we are always meeting our commitment I would guess the team can probably accommodate more work. Do we want to be meeting commitments often? Definitely. But the fact that we don’t think we will meet our commitment this sprint isn’t necessarily grounds for aborting a sprint. I encourage teams to aim for 80% success. So 8 out of 10 sprints you should be meeting your commitment. If your average is starting to creep above 90% I would encourage the team to take more risks. If the average is dropping below 70% I would encourage the team to back off their commitments a bit.

      That said, it sounds like due to these critical issues, your team is struggling meeting commitments and are likely below the 80% success mark. I would encourage the team to commit to less work. Explain that the production issues eat into the available time for the team and thus some time has to be reserved to address those issues. This can also be a good way to communicate the importance of technical debt issues to your product owner. We had to back off commitment due to production issues. Here is a story that will improve the stability of the software and thus reduce the occurrence of critical issues, allowing us to increase our commitment.

      This becomes a bit of a balancing act finding the right balance between reserving too much time and not enough, but the key indicator to watch is how often the team is meeting their commitment as described above. During those lucky sprints where no critical issues occur the team can obviously adopt work and deliver more than promised!

      I hope that helps! As I mentioned there are several other things you can try as well, but this would be where I would start. Let me know how it goes.

  • http://twitter.com/devblock/status/213263967118823426/ (@devblock) (@devblock)

    Some discussion on handling “production issues” in #agile in the comments of this post. Any advice to share? #scrum http://t.co/8paCWhBb

  • http://twitter.com/RevioCTO Thorbjørn Sigberg

    Interesting post. We are in a simlar situation. We also have separate product backlogs, but we also do separate releases/sprints for each product. Even though we have one development team, in practice we split them up, so that 2-3 people are working on the same product / project.  So any one person are rarely working on more than one project/product at the time. 

    Smaller issues / support issues are handled via KANBAN, while larger projects are handled as releases / multiple sprints. We never commit to more than 6hrs per day to the larger projects, to be able to have some headroom to handle support and critical issues. As you mention in your latest comment, we will of course deliver more to the project if the time is available.As we have more products than team members, and dedicate 1-3 persons to each product at any given time that means we can’t work on all products at the same time. This is an acceptable consequence of being able to work more effectively and ultimately deliver more at a higher quality.

    We use JIRA to create virtual boards where the team members and myself can track both products/projects individually, and also combine the boards to display everything that is going on. That way we can also get a view of what the entire team is working on.

    • devblock

      Sounds like a good arrangement that is working well for you!  Thanks for the feedback.