Vertically scaling product development

The title sounds like a “buzz thing”, but it’s not. Let’s explain this with a story. I might not be 100% accurate, I only witnessed the evolution since 2014.

From startup to unicorn at the R&D

On a startup model, like OutSystems back in the early days, product development was done by a small number of engineers, incrementing a single product line. This is normal on a startup, the product is typically small (the concept of MVP — Minimum Viable Product), money isn’t something that a startup can spend “foolishly” and the focus is usually on “staying alive”.

As the product and the company grew, the number of engineers also increased and, to scale, we had to break it into teams, with a clear separation of responsibilities but still one product line:

Because the product was “a kind of monolith”, our releases were still not that dynamic. As time passed, the product grew to a complete offer for the customer’s digital journey. This meant that we also had to transform our teams to be responsible for a given area of the product (much like Spotify’s model):

Of course, each of these areas grew fast and we ended up having multiple teams working for the same product line:

It started to get crowded. We needed a new strategy.

Vertical — Enablement teams

Up until now, what we saw was a kind of “horizontal growth”: you add people and teams but “all at the same level”. All the teams have the same goal (apart from infrastructure teams, release, etc): deliver value to external customers. This means that a normal story mapping session ends up with user stories looking a lot like these:

“As an OutSystems developer, I can…”

“As an IT Manager, I can…”

“As a Business Unit Manager, I can…”

…

The value is “driven” by external personas.

Mindshift — a new customer

To accelerate, we needed to be creative and change the way we work. You can imagine how messy a scrum of 20 people can be or 30 teams delivering for the same product line. We couldn’t go for this path and so we went for the “vertical” growth.

First, the basics

Remember back in the old days when you had to write assembly code? It worked, but we had to evolve. Then it was C, then C++ adding things like polymorphism, then Virtual Execution Environments like Java & .NET, then… I jumped a few steps but, in essence, what we created were abstraction layers. At the end of the day, the code still gets translated to assembly and machine code, but that’s abstracted from the developers.

Abstraction Layers

Why not apply what we’ve known for decades in this scenario too? Well, it’s what we’ve done: we created an abstraction layer of… customers! And this is key: customers. The abstraction layer is not on teams, engineers, product or tools, but customers. I know this is weird, but it’s how I feel everyone should see it.

As an enablement team, we should also be focused on delivering value to our customers. The difference here is that these customers are actually internal product teams (that ultimately add value to external customers)

The resulting user stories of a typical story mapping session of an enablement team look a lot like this:

“As an R&D developer, I can…”

“As an R&D manager, I’m able to…”

“As an R&D experience owner, I’m able to…”

…

An enablement team will, for example, create an API that will allow other teams to show really beautiful UI’s effortlessly. Looks good, but…

Heads up

There are lots of “tiny things” you must be aware when you are “enabling”:

Maintenance: If an enablement team is developing code to accelerate other team’s projects and those teams are the ones delivering new features to customers, how does maintenance work? When a customer reports an issue either through support or direct feedback, how does it escalate? Enablement teams never do maintenance? Do it all? You can go for whatever strategy you want, just make sure it’s aligned with the entire organization so you don’t lose quality nor teams are attacking less critical issues.

Public releases: Who will manage them? Are the enablement teams involved in the release process? Why? Why not? Again, do whatever fits you better.

Dependencies: We don’t do project management “by the PMI standards/guidelines”. We found that we have other ways of managing projects that work better in our context. But some things from the PMBok are very useful, even if it’s just the concept. Case in point: Gantt charts. In waterfall, they give you a great visibility on dependencies. And we need the same here. Whenever you start an enablement project, you are most likely in the critical path. So, make sure you properly align your plan with other teams to make sure your value deliveries will be on time of what other teams (remember, customers!) need.

VMs are Value Milestones. They represent the minimum value increment possible on a given project (sort of).

Responsibilities: You don’t do enablement “just because”. You are most likely working with/for other teams (customers… customers!) and there are a lot of people interested in your project. So, it’s essential that you build a Responsibilities Assignment Matrix. Something like:

This will help you be clear about who does what on which steps. And it doesn’t need to be about individuals or tasks, it can be Value Milestones and teams.

Working methodology: Will you do scrum meetings with all the teams? Weekly syncs? Sprint reviews together or kickoff a separate project? Will people move from enablement teams and sit next to other teams? Or will this break the team? Make sure you align people that will work together so there are no loose ends or context loss.

OKR’s: They are great in these scenarios where several teams are working together because it’s easy to have shared OKR’s and keep everyone on the same page. Make sure you have them.

These are the things I can remember as concerns, but there are probably more that I can’t remember at the time of this writing.

Summing up

Enablement teams allowed us to have a kind of vertical growth around product development. These teams will probably not have “big news” to share externally, but it’s ok. The question you need to answer whenever you start an enablement project is

“Are we really delivering the value that our “new” customer needs?”

Originally published at www.cesarafonso.pt on February 20, 2019.