From a recent community post:

Does anyone have any ideas or references for setting up the operating model (or team structure) when we are trying to move an organization from waterfall ways of working to a agile ways of working or from a project mind set to a product mind set?

Our leadership is trying to change the team structure to more focus on one or two products per team but I guess it has to be much more than that which basically means we need to look at the HR policies, the funding model and what we call as product because most of the time people just reliable the project as their product.Any recommendations on how can we set an operating model for agile transformation ?

There was some great guidance in response:

I'd be careful with focusing on products per team. We made the mistake of turning everything into a product and ended up with too many products, a lack of clarity on the products themselves and the organization didn't relate to the products defined by the teams. Teams don't need to own a product, teams need a mission and an interaction with other teams. They can work on a single product across many teams. Team topologies is a good place to start.  As a rule of thumb focusing on what either your customer thinks of as a product or your business / users, rather than the team is helpful.   What is often more useful is the identification of value and independent deployability for a team instead. A navigation menu or a search feature can be aligned to a team of the overall product is complicated but a user doesn't want a menu or a search feature by itself 

 

I weighed in with my 2 cents:

Good guidance here so far! Stream alignment is definitely valuable - working backwards from customer value, and clarity on core/supporting streams helps a lot. Define the dependencies and impacts of those dependencies across teams/streams. You don't need one team per product but single-threaded ownership is extremely valuable. One person needs to own sales, one person needs to own e-commerce, one person needs to own the shopping cart, all supported by teams. Each of those owners can own multiple products/features/streams, but that should be a calculated definition. If two people own something, who actually does?

This is an excellent guiding principle:
As a rule of thumb focusing on what either your customer thinks of as a product or your business / users

To put a finer point on that:

  • If you want to make the people who pay for your service happy, work backwards from what makes them happy.
  • If you want to make the people who use your service happy, work backwards from what makes them happy.
  • The former is helpful in the short term, the latter is helpful in the long term.

One other point is that a major advantage of agile methods vs waterfall is just shorter cycles / faster feedback. Smaller and quicker iterations of what you're already doing help a lot, but that's often very hard under the same org/arch structure, so it's valuable to think about reorganizing in service of improving iterations.

What do you think?