Here's an interesting one: Multiple Agile teams across multiple related, but separate products...
Hi All,
I've searched for this, but I've only seen posts regarding multiple Agile teams working on one product. My current situation is as follows:
- I've stepped into a PO role in a company that made the transition from waterfall to agile about two years ago.
- Before my arrival, there was not an official PO for the products that I am managing - the head of dev was working double time on her main duties and as the PO.
- Right now, we have three different products and three different agile teams working across those products (teams are not dedicated to a specific product).
- Of the three products, two have singular backlogs and one has multiple (to account for the fact that this product is highly customized for each customer, though has a partially shared common code base).
- We have three different team-level backlogs as well. The team backlogs contain stories that essentially point to the product stories.
- Currently, the setup supports the following needs:
- Providing for a method to combine work across the three products into team-level ECRs that require work across multiple products for new features / bugs / etc.
- Providing for one workflow on the product backlogs and a different, simplified workflow on the team backlogs. (product items require more initial and in-progress reviews by a broader team)
- Preventing one very large backlog across three products (there are hundreds of items across the three products).
- Currently, the setup is blocking the following needs (these are the main ones at least):
- Alignment with other product teams in the company, who have the basic setup of one team per product, and therefore one backlog per product.
- High level view of releases that span multiple products (burn downs, reporting, feature-level information, etc).
- The need for some version of sanity on the part of the Product Owner :)
Has anyone seen anything like this before? Were you able to combine things into some rational process? Any ideas on how to create higher-level views into the releases and to align with the other product teams that use one backlog per product? I've exhausted myself trying to find a solution to this one. I have a directive to ensure alignment between my teams and the other product teams in the company. I'm at a loss on how to accomplish this.
Thanks so much for any advice you can provide!
- Jon
I should also note that we have three sets of sprint planning/estimation/review/retros for the three different agile teams.
In Scrum, there should be one Product Backlog for each separate Product, each of which has a clear Product Owner. There can be multiple Development Teams which draw work from the same Product Backlog, and they will plan their own Sprint Backlogs which will result in an integrated and releasable product Increment every Sprint.
- What are the "team backlogs" you refer to?
- Why is there a desire to combine work or workflows across Products and Product Backlogs which are supposedly separate?
- Why do releases span multiple products?
@Ian: All good and valid points/questions. Such is my current predicament.
In Scrum, there should be one Product Backlog for each separate Product, each of which has a clear Product Owner.
- That'd be me, for all three products.
- What are the "team backlogs" you refer to?
- We quite literally have 3 additional projects in Jira, one for each team. This is in addition to the Product projects in Jira. Team stories will actually link back to bugs/improvements/new features in the Project projects.
- Why is there a desire to combine work or workflows across Products and Product Backlogs which are supposedly separate? - Why do releases span multiple products?
- Our system consists of three main components, each defined as its own Product:
- A configuration tool
- A central processing / execution / etc application
- Software that resides on various hardware elements distributed across large geo footprints
- We have three teams available to work on the three components, but each component may not have work during a given sprint (sprints line up for all three Products), so we cannot dedicate one team per component. At times, also, work must be completed across multiple components in order to create new features (or bugs may span across components). We're left in a situation where the "Products" (components) are not quite disparate and not quite unified. We have three teams because the number of folks, if combined, would be quite large.
- A new feature or bug is dedicated to a specific team, who handle all work across the three components, in one or more sprints.
My main challenge, something that I'm looking to solve, is to eliminate the team Jira projects and associated backlogs, and work solely from the Product projects (backlogs). Challenge is to maintain the current cross-team/cross-Product workflow while doing this, without creating a ton of overhead, complication, or 20 cross-links for every PBI.
Hi John,
Going to add to your conversation, with maybe another twist. Ian, maybe you have some exposure to this as well.
We have a scenario where in one functional product area, we have 4 applications, different technologies (think near end of life/ legacy). Right now we have 2 scrum teams that cover 2 applications each, both with it's own backlog, own product owner. The backlog / funding for all applications is being reduced, to the point where one scrum team could support all 4 applications if not for the varied technologies. Looking for a model or examples of how this has been handled in other organizations.
Assuming the skills were there, a single Development Team could support 4 products via 1 week sprints in rotation. Each sprint would service a different product, and each product would thus be worked on once a month for a different Product Owner. The provision of such servicing might be the Sprint Goal in each case.
Thanks Ian.
That's our challenge, the assumption :) The apps each come with different code bases, (C++, Java, PLSQL, etc) so varied skill sets I've not seen a model where you have 1 or 2 person scrum teams, but neither have I seen a model where you have 1 full scrum team supporting 3 or 4 technologies. Not sure it exists.
Hey John, did you ever get a resolution to this? I have a client with a similar issue and I wanted saw your post while looking for information on how they could resolve the issue and if someone out there had done it before.
Some important notes about Jira:
(1) Issues are created within a project
(2) Boards are built off of queries, and thus can display issues from multiple projects
(3) Reports (burndown charts, etc) are based on boards
(4) Workflows are applied to projects
(5) Different issue types within the same project can have different workflows
(6) You can reuse the same workflow on other projects (no need to recreate it)
I recommend adding a custom field to all issues called "team" that will have a drop-down of the three teams. You can then create a board for each team, by having your query filter issues based on that field. Thus, each team will have a single board where they can manage work.
Note that if you don't edit the permissions on a query for others to be able to see it, only you will be able to see the board made from that query.
It sounds like you may also want to edit the workflow scheme so that features (or something else higher up in the hierarchy) use a workflow that requires additional review checkpoints that are not in the workflow for issues lower down in the hierarchy.
(PS. I know that this reply is years too late for anyone already on the thread, but perhaps it will help someone new.)
Hello @john @Brandon,
I am curious to know what your solution was to the original problem
(1) Multiple small scrum teams (developers ranging from 1 to 4 max, in each team).
(2) Different product vision for each of the scrum teams
Is it even an efficient use of SM or PO in a scrum team with 1 or 2 developers ? Which is the best Agile methodology to use for small scrum teams ?