The road to customer centricity

In Component teams break Flow we discussed the negative impact component teams have on Flow. In a follow-up blog post, From structure to culture, we then noted that promoting collaboration and customer centricity in a system organised around siloed teams isn’t going to succeed. To achieve customer centricity we need to look at the structure, first.

Removing silos becomes much easier once we move away from component teams and adopt feature teams instead. The concept of feature teams has been around for decades and it is well-known within the agile community. Unfortunately, organisations trying to embrace agility often don’t seem to appreciate how important feature teams are in making ‘agility’ succeed and end up focusing on practices and roles more than on structure and culture.

In this blog post we want to highlight the positive impact that feature teams have on Flow, organisational culture and business agility.

Similarly to what we did in our previous blog posts, we will start by looking at Product and Engineering. Then it will become clear that our solution opens the doors to incorporating other business functions, improving business agility and culture for the whole organisation.

From component teams to feature teams

In our previous scenario, we had the following roles in our Product and Engineering:

and built three component teams — each specialised in one area of our platform. We noted how a feature F would require increments A, B and C to be produced by the respective teams and to be “assembled” at the end before any customer value can be released. Let’s visualise this scenario again as a reminder of the notation we used:

We discussed that none of our component teams (even when cross-functional from a skill set point of view) can deliver something of value to a customer by themselves. To resolve this we need a structure in which a single cross-functional team can deliver customer value independently. Luckily, this structure is disarmingly simple:

We have a customer (customer segment) on the right hand side, a business backlog capturing the value proposition for that customer, a Product Owner/Manager working with a Technical Lead and a team of Developers whose job is to deliver whole customer features to the customer.

The key difference is that now Developers work across the entire stack, from idea to production. By design, a feature team is no longer dependent on increments built by other teams. We have eliminated feature-level dependencies.

Feature teams can now iterate on customer features —using Scrum, Kanban, XP etc.— and deliver measurable, incremental value iteration after iteration. Now that the backlog is outcome-oriented, measuring the value and the cost of each feature has never been so simple.

Code-level dependencies

It goes without saying that two or more feature teams working across the entire platform will inevitably touch the same bits of code while working on different features and therefore we’ll have code-level dependencies. Here we’re not discussing merging and integration — which are rather trivial — but the need for cohesive coding solutions.

For example, if one team is working on credit card payments for books while another team is working on credit card payments for consumer electronics naturally both teams will want to design both pieces of functionality in a cohesive manner, avoiding duplication and “reinventing the wheel” and ensuring that all code is reusable, simple, testable and architecturally sound.

To achieve this, Developers from different feature teams will collaborate in cross-team sessions and ensure that they’re maintaining a holistic view of the platform, as often as required:

In simple terms, Developers will spend 80% of their time delivering customer value, and 20% of their time coordinating with the other teams on code-level dependencies. Over time, this approach leads to a culture in which Developers are able and willing to work on every module of the platform giving us greater flexibility in how we allocate capacity.

The benefit to the business is clear: we no longer have to keep Developers busy doing the work they know how to do, instead we can assign them the work that needs doing, at all times.

When we had component teams, we had to organise the work around the teams. Now, with feature teams, we can organise the teams around the work.

The role of the Product Owner

In this structure we no longer have a split in product roles, i.e. a “technical” Product Owner working with delivery teams and a Product Manager working with the business. We have “merged” the two roles into one since feature teams are aligned to the business backlog. We will call this role the Product Owner — you can call it Product Manager if you like that better.

Our Product Owner now acts as an “entrepreneurial” Product Owner focusing on the market and providing clarity and prioritisation to the teams. With enough clarity around the goals and the objectives, the feature team will be able to effectively refine and deliver items from the backlog without requiring too much support from the Product Owner. We are freeing the Product Owner from Business Analyst type of duties and making space for the team members to pick up these skills which complement coding, testing, designing etc.

Access to the customer

In this structure, the Product Owner is not meant to be between the team and the customer. In fact, feature teams should have direct access to customers and customer feedback, for example by inviting customers to planning sessions, demos and collaborating with customers to refine the value proposition, continually.

If the customer is not physically accessible we have plenty of digital tools to capture and explore customer feedback. The feature team uses quantitative and qualitative data to learn how to improve the customer experience and what to focus on in the next iteration.

Feature teams take a primary role in finding solutions to business problems. It’s true that we expect the Product Owner to decide what gets prioritised, but once a priority and a goal have been identified and communicated, the team is empowered to collaboratively find solutions to business problems — they are not just implementing solutions identified by Product Owners, Business Analysts or even leaders from outside the team.

Customer-centric value streams

Once we have built effective feature teams, we can extend them to include more business functions (Marketing, Sales, Customer support etc.) needed to deliver value to a particular customer or customer segment. In other words we’re building customer-centric value streams.

When building value streams we’ll face a scenario in which people coming from different areas of the business (IT and non-IT) are still thinking with their “functional hat on” and find it hard to contribute to feature teams in an iterative manner: they might be new to agile ways of working and might struggle in making the iterative mindset work for their discipline.

This is where an Agile Coach can help. Not only by clarifying how incremental and iterative delivery works but also by building the right environment to make collaboration and experimentation happen across the different functions. Colleagues from Tech, Marketing, Product, Support, Finance, HR etc. now working in customer-centric value streams will share the same business goals, focus on the same customer and will have to find a common language to bridge between the different functions and enable collaboration.

Can we merge the business backlogs?

We have made the assumption that we need three business backlogs — one for each customer segment — and we’ve “allocated” one feature team to each backlog.

In reality, because our feature teams are capable of picking up any feature from any backlog and work across the whole platform, we don’t even need three separate business backlogs: we could work off one single business backlog and have the feature teams pull work from it in priority order.

Who do you need to make this work

By moving to feature teams, we’ve built a system optimised for value delivery, where feedback is naturally faster and everyone is focused on customer outcomes.

To maximise collaboration we need to pay attention to the type of talent we hire. We’ve already discussed the Product Owner role, which needs to be business focused. What about Developers?

We need Developers who want to do more than just having their heads down coding. We need ‘Product Developers’ who are passionate about delivering products (and services) to customers.

Product Developers empathise with customers and can work with colleagues from other business functions with whom they share a goal.

This might not be everyone’s cup of tea, but with the right balance of skills and experience and by focusing on talent acquisition, we can build such a culture and sustain it over time.

Performance management and objectives

Now that we have feature teams, the Product Owner is no longer the only one who is responsible for outcomes: delivering customer value is everyone’s responsibility, by design.

Therefore we can move away from milestones and deliverables, and use outcome-oriented drivers such as KPIs and OKRs instead. Driving with outcomes instead of outputs will also help collaboration: for example, when Developers are no longer working on fixed deliverables, they will be more likely to engage with Customer service and Marketing to understand how to improve customer experience and product quality. And this feedback is now first-hand information since Product Development, Customer service and Marketing live in the same value stream.

In the old world, with component teams focused delivering outputs, we were tempted to measure progress against fixed scope and fit fixed scope into iterations.

In the new world, with feature teams, we no longer articulate objectives around deliverables. Instead, we can work towards shared outcomes and collaborate to achieve them, with simple, creative solutions, iteration after iteration.

Thank you for making it this far. We hope you enjoyed this read. Let us know what you think!