T-shape in one Product Area
Dear community,
I ask for your assistance :) Long story short, the case:
We have multiple Product Areas in the company. In my department, we have 4 Product Areas. According to the original idea, everyone in a product area is a T-shaped professional, which means that all the teams in one PA have the same backlog, can easily share bugs, etc. 3 of our PAs are absolutely okay with that, they have interconnected products, so everything works the way it was supposed to be. I am working with the 4th PA, and, unfortunately, this PA includes everyone, who did not fit the previous 3. Due to that, we have a lot of small, different products. Sometimes they have no connection to each other at all. I would also add that our system is a hardcore legacy (most probably you don't even know the language we use, just believe me :) ), so it is a real pain to learn more about the new product. I am not even talking about all the products we have.
The problem:
At the given moment we have "one backlog" on paper but in the real world, we still have multiple backlogs. Each team in a PA has a set of products they know and work with. The idea of T-shaping brings true horror to the dev teams' eyes (which I find fair). And now, one of the teams is overloaded with bugs. They cannot share it with other teams in PA as that would be done in any other PA. RTEs are promoting the idea that we finally have to start our T-shape transformation but the dev teams will be super against that decision.
From my point of view, the issue we have happened not because of T-shape but because we have a mix of everything in the scope of the Product Area. No doubt I may be blind, so this is why I am here.
The question:
Do you see any solutions here? Should we go with T-shape anyway?
Cheers!
I am not even talking about all the products we have.
That's right, you're not. Why not? Why not begin with the actual products you have, and who is accountable for them, so there is a clear line of sight to product value?
The way I understand your situation, you have 3 Product Areas and 1 Product Dumping Ground. In agile practice, the focus is mostly on products. Products have backlogs. Products have goals. Products have owners. Products have changes needed or wanted in order to keep them viable. Products have teams that do work on them.
Product Areas are usually a way to group like or related products together for future planning, budgeting, marketing, etc. A bunch of unrelated products are usually not conducive to a Product Area. Every one of them will have different needs, different skills, different audiences.
Do you see any solutions here? Should we go with T-shape anyway?
My suggestion is that you need to realize that your "one-size-fits-all" solution does not truly fit all. Use empiricism to learn and adapt accordingly.
Hi Alina
I am fully agree with Ian and Daniel that we should focus on "what is the product"
Reading through your details, it seems that you're having main product backlog and mini backlog
. if you'd like to create a single product then we should have a single backlog and focus on first 2 main features
. if you end up with multiple small product from each backlog then it is time to review it with stakeholder
it is also worth to review "definition of done" of each product to close it
Thanks, everyone! I absolutely agree with your point of view, and I really appreciate your time!
May your burndown charts be amazing for the next year :)