Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Doing XP with multiple teams working on 1 product (started in the Deployed Released thread)
Hello practitioners and Thanks for the concerns Steve. I think there is another question sitting in the thread below about "Deployed" and "Released". That's why I start a new thread.
I think the question is: "How does the Scrum Product Owner accountability work with multiple teams working on 1 product?" ? (and lots of influencers, providers, ? lovers of the product = stakeholders) Note:
Focus here:?
Every Scaling Framework has their own opinion on this. My experience by coaching teams and my opinion strongly influenced by me being a ScrumOrg Trainer and teaching Nexus:
PS SAFe has a Team Product Owner which is a strong 'smell' to me. More details here ? What have you seen working (or not) in a scenario where you have 1 Product Owner and 1 Product and X teams and Y stakeholders? Looking forward to experiences! THANKS Peter Gfader ---- A bit of context below ---- Major problems I observed with different orgs:
What usually works easily:
I have written these things up on my blog here??and a whitepaper with feedback from Jez. |
I work at a place that used to have 10 teams working on 1 product. (We have since moved on to 12 teams working on 3 products) But originally, we had 10 teams working on 1 product, and the way we effectively handled that is that each iteration the thematic feature set (epic) which the teams would work on were considered their own product for the course of that iteration.? Each iteration of the "product" that the teams were working on would either continue to be the same or switch to something?new if that new epic/sumproduct/theme was "complete". One advantage of this is that every team got to learn just about all parts of the product. brought to you by the letters A, V, and I and the number 47 On Fri, Mar 26, 2021 at 12:58 PM Peter Gfader <peter@...> wrote:
|
There are lots of possible "solutions", none of which solve all the issues in all the contexts,? The key to agility is facilitating each organization to continuously evolve their approach based on feedback?in their evolving context. My concern was not any particular solutions, but rather that terminology/principles that imply that the development team includes all the skills/concerns/people necessary to address all of the pragmatic deployment issues discourages too many of the potential solutions. On Fri, Mar 26, 2021 at 2:58 AM Peter Gfader <peter@...> wrote:
|
to navigate to use esc to dismiss