Devopsdays 2020: moving from project to product - Edward Pearson¶

Tags: devopsdays

(One of my summaries of a talk at the 2020 online devopsdays Amsterdam conference).

The full title of the talk: moving from project to product: it’s time we stopped failing the business. Link to his slides.

Where did it all go wrong? In many organisations, IT is not fit for purpose. IT is failing the business. No: we are failing our business. “Our” is also potentially a problem when work has been outsourced…

In companies, often new features are quite big. Someone gets a good idea, gets management behind it, something is architected, UX is involved, frontend and backend devs get to work. And at the end it has to be put on the servers and maintained. And it has to start providing value to the customer.

Such a project starts to go wrong right at the start: where does the idea come from? Does it start with an actual customer need? Once the project gets underway, as described in the previous paragraph, it looks more like the 20th century scientific way of managing work. There are those that plan and those that do. There is one best way to do any single job. Workers need to be managed and monitored. They need to be trained to do their specific job well.

• Projects assume we know what the right thing to build is. This means we make key decisions right at the start, exactly when we have the least information.

• Project have to be funded. So: a pre-defined solution exists. Teams aren’t really expected to learn and adjust.

• Project teams are focused on short-term goals. Long-term maintenance is someone else’s problem.

• Projects focus on output, not customer value. Output: cost, scope, quality, time.

So: projects do not focus on customer value.

The future lies in products, platforms and services. Those are much more focused on customer value. Automatically we often get more cross-functional teams.

“Platform as a service” is important as an underpinning. To prevent hand-overs between teams, as much as possible needs to be provided as a service. Hosting platform, continuous delivere platform, monitoring service.

How does the product workflow go?

• You start with an idea, which ends up on a prioritised backlog. The customer can help with the prioritisation!

• When it gets out of the backlog, there’s commitment to actually create it.

• It is created by a cross-functional team. This might involve the customer.

• The value ends up quickly with the customer.

Top five guiding principles. What needs to change?

• Batch size needs to get smaller. You can move faster. And you can release more often. If you release more often, the pressure to get a half-baked feature in is lower.

• Focus. On actual customer value.

• Scope. It is agreed in advance and based on feedback from the developers and the customers.

• Funding. Based on actual customer need and customer value.

• Speed to market. Speed is “as long as it takes”. As fast as possible. What is the minimum we can do to actually provide value?

What do we measure? Output (project) or outcome (product)? Align your people to deliver what your customers value.