Wednesday, February 20, 2019

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 (MVP - Minimum Viable Product), money isn’t something that a startup can spend "foolishly" and the focus is usually on "staying alive".

Engineering


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:

Engineering


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):

Engineering


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

Engineering


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.

Engineering


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)

Engineering


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..."
...

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 PMI 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.

Engineering


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!) and there are a lot of people interested in your project. So, it’s essential that you build a Responsibilities Assignment Matrix. Something like:

Engineering


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?"

Tuesday, January 1, 2019

Service Studio Beta 101 (FAQ)

Service Studio Beta

What is it?
In essence, a stable version of Service Studio but with some additional features that are still to be released.

Wait. Stable?
Yes, a stable version. Unlike a nightly build (like Firefox Nightly), the Beta version contains the same code as the general availability version but with added features. You can expect the exact same quality in the Beta version as in the normal releases.

What's in it for me?
Two main things:
- You have access to "goodies" faster;
- You can help shape the product: your feedback will be used to improve the features before they get to general availability.

What's in this first version?
The first Beta version comes with a Forge Integration in the application list that allows you to quickly update your Forge components. From now on, there are no excuses for keeping outdated components in your factory. Also, automatic updates. Yep, this version of Service Studio Beta will be the last one you'll ever have to manually download and install! You don't have to do anything: you'll get new features automatically! You can read the quarter highlights at the OutSystems Engineering blog.

Service Studio Beta - Forge Integration


How often will I get these updates?
Whenever there are new features, there will be a new version and you'll get it. It can be daily. It can be 3 times a day. It can be once a week. Apart from the Beta version (because we want to deliver as fast as possible), you have a release plan at the OutSystems website. You can also check for the What's New page.

Will these automatic updates impact my work?
No. Service Studio automatically updates in the background and won't force you to close while you're working.

I'm in! Where can I get it?
Head over to https://www.outsystems.com/home/beta. It's the last version you'll need to manually install. Automatic updates for the win!

How do I send feedback?
Just like in the general availability version. Your feedback is precious.

Anything else I should know?
Head to this forum discussion and join us! Oh, and keep that feedback coming. Let's build a better product together!