Team Topology and MVP

1 Aug 2022 | Lean Inception

I have been running Lean Inception workshops – a workshop to align a group of people about the MVP — for many organisations contexts. Therefore, I have seen many different teams and many different MVPs.

The other day I was helping a Platform team plan a Lean Inception.  Then I came to the realisation that the MVP and the challenge for figuring out a plan for the MVP is quite different depending on the team topology type. I opened several remote Lean Inception boards from my previous engagements. I reflected about each team, their Lean Inception and their MVP.  I had a really nice book from my bookshelf, staring at me. Then I started writing this post.

Mathew and Manuel on their amazing book Teams Topologies classify the teams into four fundamental topologies:

“FOUR FUNDAMENTAL TOPOLOGIES
• Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
• Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams
• Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
• Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed. “ – from Team topologies 

Let´s look at each of these team topologies and the typical way of working with MVP.

Stream-aligned team and MVP

Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain

Most MVP examples we find on the internet are for Stream-aligned team. A product or a business domain must evolve based on validated hypothesis. The MVP provides the means for that as it is the building block for faster build-measure-learn cycles

In search for the product market fit, the Stream aligned team must run many fast experiments, many MVPs, many minimum and viable things to provide the most learnings and insights.

Once the initial path is validated, the Stream aligned team should work towards building a solution or a product. They want to plan the MVP, the minimum few features to be made available to a few users of their stream of work for validating the next set of hypotheses.

Typically, a Stream aligned team will participate in a Lean Inception workshop to align about the MVP. They might invite external stakeholder to take part in the workshop. These are people from other teams that might influence and/or be very interested in the direction of their stream of work.

Are you planning a Stream aligned team Lean Inception and find yourself inviting too many external stakeholders? Perhaps this might be an indication that the streams of work are intermingled. Consider reassessing the teams. Consider running other types of workshops before the Lean Inceptions. You should first untangle the streams of work, then run your Lean Inception to plan your stream of work MVP and the following increments (the work for your Stream aligned team).

Platform team and MVP

Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams

Who is the final user for a platform team stream of work? The answer to this question triggers the conversation about the platform team MVP.

One might say the Stream aligned teams’ developers are the users for a platform team work. Another might say that user of a product released by a Stream aligned team is the final user for a platform team stream of work.

Both are valid arguments. This makes the MVP planning for a platform team more complicated. The platform team, on its own is not delivering anything to the final user. Therefore, whatever is the MVP for the platform team, it must help validate some hypothesis for one or more Stream aligned teams.

Scenario 1 – Simple

In the simplest scenario, a platform team (or a few members from the Platform team) are allocated full time to a Stream aligned team to plan and build the Stream aligned team MVP. Typically, both teams will participate in a Lean Inception. Then the platform team members will plan their work alongside with the Stream aligned team, with the common goal of building and validating the MVP.

Scenario 2 – Complicated

In a scenario a little more complicated, the Platform team works, at the same time, with more than one Stream aligned team.

As a platform team, you want to understand all Stream aligned teams work roadmap so you can plan yours. The challenge is to get every Stream aligned team plan, a detailed and predictable plan. Even if you try to have a fix plan, you know that the Stream aligned teams plans will change, and your Platform team plan will have to change as well.

If the Stream aligned teams are agile and work with MVP, they work incrementally, building only a few features at a time; therefore, requesting only a few things from the Platform team. It is your job to best shape these few things in an order that makes sense to incrementally build and validate the Platform usage.

But it is not easy to understand all Stream aligned teams’ roadmaps and MVPs. Usually they do not have the detailed roadmap, or if they do, they will ask you to build everything for yesterday because they already need all Platform features, from day one.

You want to get your hands on each team MVP plan. You want to know what is the minimum each team is building so you can also build the minimum necessary for the Platform team. It would be awesome if, magically, all teams participate on a workshop and then you have each team MVP plan.

Do not try to organize a large workshop to plan all teams MVP with everyone on it (believe me, I tried and failed miserably!). The Stream aligned teams will have different streams of work, different goals, therefore different MVPs. Instead, each Stream aligned team should have their own Lean Inception, decide, and plan their MVP and the product increments.

You, as a Platform team member, should be invited as a stakeholder of each of these Stream aligned team inception. You should participate, at least, to the inception kickoff and the inception showcase where the Stream aligned team shows their plan going forward.

Once the Platform team has understood the MVP plan for each Stream aligned team, then they should plan the Platform MVP and the following increments to best support the Stream aligned teams.

This scenario requires constant communication and coordination. If the Stream aligned teams are agile and work with MVP, they will learn with the final users, the plans will change, there will be pivots, and the Platform team must adjust accordingly.

If you follow this scenario and start complaining about the communication and coordination overhead, consider rethinking the teams’ organisations . Consider letting some people from the original Platform team join the Stream aligned teams (at least for a short duration). Consider focusing the Platform team in new areas where the platform can evolve as a product (then they became themselves a Stream aligned team for an internal product).

Enabling team and MVP

Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.

An Enabling team should help the other teams to work effectively with MVP and other important capabilities. This team might use the concept of MVP as the simplest thing to validate something towards their Enablement goal.

They should use the MVP concept in the hypothesis development driven form, such as:

We believe that <by performing this Enablement MVP>,
Will help us achieve <expected results>
We know we are getting there based on <these metrics to validate the hypothesis>.

An Enabling team goal should not be to build products. Therefore, an Enabling team should not, themselves, be running experiments for the business and the products. They should not be planning the simplest set of features to help validate a product direction.

Instead, the Enabling team should help other teams experiments for the business and the products. The Enabling team should help other teams plan the simplest set of features to help validate a product direction. The Enabling team should help other teams work effectively with MVP! Typically, Enabling team members are great at facilitating workshops such as the Lean Inception.

Complicated Subsystem team and MVP

Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.

Complicated or not, I rather use the product thinking for this type of team as well. Of course, things get more complicated as there is a deeper degree of mathematics/calculation/technical expertise in the type of “products” created ty these teams.

Is the work of this team used by a final user or by other teams? The answer to this question varies from organisation to organisation.

As per the team topology and the MVP aspect, if you answer that it is used by a final user, then much of what was written on the Stream aligned team and MVP applies.

On the other hand, if you answer that it is used by other teams, then much of what was written on the Platform team and MVP applies.

One thing to consider is that an MVP, for this type of team, most likely will include some extra activities, not only experiments and features. The “Product” might be a little more elaborated and you might have to consider some mathematics/calculation activities besides the typical user facing experiments and features when planning a MVP. These teams typically will change and adapt the Lean Inception workshop to best full-fill their needs (for example a Data Mesh Lean Inception) .

In any case, you must keep following a hypothesis driven development style to validate each and every Complicated Subsystem teamwork outcome:

We believe that <this MVP>,
Will help us achieve <expected results>
We know we are getting there based on <these metrics to validate the hypothesis>.

 

 

Paulo Caroli

Paulo Caroli is the author of the best-selling book “Lean Inception: How to Align People and Build the Right Product” (the first on a series of books about Lean Strategy and Delivery). He's also the creator of FunRetrospectives.com , a site and book about retrospectives, futurospectives and team building activities. Caroli writes on this blog frequently. Receive the next post in your email. Sign up here .
MVP philosophy and the Justified True Belief

MVP philosophy and the Justified True Belief

Lately I have been listening and reading about philosophy and I came across a theory that got me thinking about hypothesis driven development, Minimum Viable Product (MVP) and validation. It is accredited to Plato from around 369 BC with the name of Justified True...

read more

Pin It on Pinterest

X
X
X