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.
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.
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.