Design for outcome-oriented teams

While developing an organisation structure for an Agile or Lean business, there is a strong focus on teams being responsible for business outcomes (outcome-oriented teams). These teams are opposed by so called activity-oriented teams (teams responsible for an activity).

To understand the why of the focus on outcome-oriented teams, we need to understand what is a business outcome. Selling a product and generating revenue is an example of a business outcome. This outcome is the result of a chain of activities, like marketing, lead generation, product development, testing and support. To achieve an outcome we often need to break the chain and define suboutcomes. These suboutcomes aren’t that valuable on their own, only in context. If the division continuous, we end up with merely contributory activities. The difference between outcomes and activities is similar to that between user stories and tasks. Activities serve outcomes, like tasks serve the purpose of a user story.

Activities that are no longer directly bound to business outcomes are more likely to be trapped in the pitfall of local optimisation. Activity optimisation is a common cause of silos and of lengthening cycle times. This is because when we organise by activity, no single team can own the outcome (since it broke the being independable requirement).

Careful splitting a business outcome

So we need to be careful how and to what extend we split outcomes. We want to keep both meaning (sense of purpose) and value. How to determine whether a division leads to a suboutcome of an activity? Good business outcomes are:

  • Testable
  • Valuable
  • Independently achievable
  • Negotiable

While splitting into suboutcomes we keep asking whether these suboutcomes remains independent and valuable business outcomes.

Is there still room for activity-oriented teams?

Some support functions in an organisation don’t own independently valuable business outcomes. They are activity-oriented teams, think of departments like HR, admin, legal, finance, controlling. Does this mean that they automatically become silos and should be disbanded?

If the realisation of an outcome is dependent on repeated successful iterations through some core value stream, these activities should not be conducted in activity-oriented teams. Activities that aren’t an integral part of a business outcome’s core value stream could be placed into separate teams without much risk.

However we should remain cautious. Activity-oriented teams tend to “standardise” their operations over time. Their focus moves away from offering custom solutions. Complaints from other teams about rule books and bureaucracy will be your signal.

Definitions

Definitions used in this post are found in Agile IT organisation design:

  • Outcome – An independently valuable and achievable business outcome.
  • Outcome-oriented team – A team that has autonomy and accountability for an outcome. For example a cross-functional product team.
  • Activity – Action that contributes to an outcome.
  • Activity-oriented team – A team that is responsible for a single activity. Usually a team of specialists (marketing, finance, testing, sales).
  • Cross-functional team – An interdisciplinary, outcome-oriented team. It may consist of hard-core specialists, generalising specialists, or generalists.
  • Value stream – A series of activities required to deliver a business outcome.
  • Silo – A unit (team, department) that tends to protect itself and doesn’t work well with other units.

Leave a Reply

Your email address will not be published. Required fields are marked *