Organizing by Customer Value

In a small one-team product, organizing by customer value is trivial. The more teams, the more they become like cogs in the large development machine. Like Charlie Chaplin in Modern Times, their jobs is to turn screws but have no idea how the customer will use the product… or who that customer actually is. How to scale and keep a customer focus?

Cross-functional Teams

Having cross-functional teams is important for keeping the customer focus. With functional specialized departments, we create process-steps and the previous person in the process becomes “our customer”. But these internal customers are not real customers. With cross-functional teams, we change the whole perspective and give an item to the team and let the team as a whole focus on a customer-centric feature. The team, being in a short time-period will need to figure out how to parallelize the work done within the Sprint period… and keep their customer focus.

Feature Teams

Like with cross-functional teams, feature teams focus on the customer and is a way of organizing around customer value. Feature teams take a customer-centric feature and “do it all.” It allows the team to speak the same language as the customers and to remove the barriers between customers and actual users… much less hand-offs.

Specialize in customer dimension

A common misunderstanding of feature teams is that it means abandoning specialization altogether. Part of this misunderstanding comes from the false dichotomy between either specializing in one component or not specializing at all—which we’ve covered extensively in our writing on feature teams. Part of the misunderstanding comes from the belief that specialization is a one-dimensional thing—specializing in a component. But specialization is multi-dimensional.

LeSS brings users and developers closer together because the user-perspective is almost always lost in traditional large product groups. Feature teams are one way of organizing by customer value but not the only one. The principle of preferring specialization in customer domain also leads to other structuring decisions. For example:

Banks create mobile apps for banking services on mobile devices. The product groups are typically organized by platform: (1) the IOS teams, and (2) the Android teams. These teams are feature teams and they are specialized in the technical dimension—namely, the platform. Alternatively, they can be organized in customer domains such as (1) mobile payments, (2) admin, and (3) reporting. This leads to the teams implementing the same type of features on multiple platforms instead of implementing many types of features on one platform.

Which specialization dimension is better? Traditional organizations tend to specialize in technology dimensions. Why? Perhaps that is perceived as more difficult and hence specializing in that dimension leads to faster development? But in LeSS we prefer specialization in the customer domain to increase collaboration with real users and remove hand-offs.

The assumption in traditional organizations is that specializing around technology is ‘better.’ But is this true especially as the industry matures (and ages) and polyglot programming is common? And is it true from the customer perspective? Scrum and LeSS have a tendency to prefer specialization into the customer dimension.