Tag Archives: Team

Team

Two interesting reads on team structure and focus

(Re)discovered two interesting reads on team structure and focus this week that I like to share.

Pioneers, Settlers and Town Planners

pioneer, settler and town planner The Pioneers, Settlers and Town Planners approach help structure organisations and teams. It takes into account how activities and practices move from chaotic (poorly understood, uncertain, constantly changing, rare, future source of worth) to more linear (well-defined, predictable, stable, common, cost of doing business) and how organisations contain a mass of these activities and practices. Understanding this and using the right methods and tactics is important to creating a balance between the unstable but potentially high margin activities (chaotic) and the stable and low margin (linear).

McKinsey’s Three Horizons of Growth

McKinsey’s Three Horizons of Growth are all about keeping you and your teams focused on growth and innovation. This strategy framework requires you to categorize your goals into 3 different ‘horizons’. You can also split the activities of your team to the three types of activities that are related to fulfilling the goals for the different horizons. In that case, a team could spend (as a rule of thumb):

  • 70% on activities that are most closely aligned to your current business.
  • 20% on taking what you already have, and extending it into new areas of revenue-driving activity.
  • 10% on introducing entirely new elements to your business that don’t exist today.

This helps ensure that you consistently balance your focus between the needs of today (horizon 1), the future state of your business (horizon 3) and the steps that you need to take to get there (horizon 2).

Boek – Getting Teams Done – Spark

Getting Teams Done - SparkHet boek Getting Teams Done is een leuk introductie in Holacracy. Dit boek introduceert de methode waarmee leidinggevenden, teamleiders managers en zelfsturende professionals de teamproductiviteit naar een hoger niveau kunnen tillen. Holacracy wordt bijvoorbeeld ook gebruikt als organisatievorm bij Zappos (lees ook Delivering Happiness).

Getting Teams Done is geschreven in de stijl van Het Doel / The Goal en The Phoenix Project. De romanvorm wordt daarbij in dit geval afgewisseld met een non-fictie deel waarin wordt uitgelegd hoe Holacracy werkt en waar het een oplossing biedt. Daarnaast wordt in dat deel steeds het proces en de ondersteunende technieken uitgelegd.

Het boek Getting Teams Done is een aanrader voor iedereen die geinteresseerd is in Holacracy en zeker voor diegene die werkt voor een organisatie waar Holacracy of een variant als Spark ingevoerd wordt. Het invoeren van Holacracy of Spark vraag een zeer sterke discipline. Daarbij is het handig om hulp van buiten te hebben die buiten de inhoudelijke en andere discussies staat. Op die manier kan er sneller mee aan de slag gegaan worden en kunnen de resultaten eerder worden bereikt.

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.

Spotify engineering culture part I & II

I’ve been reading quite some article on engineering culture and ways of working. The videos on Spotify Labs are among the best sources I’ve watched or read in the last year on the subjects of agile and culture. Recently the second part of their series on Spotify’s engineering culture was released.

Spotify engineering culture part I


Important take aways for me were:

  • Agile over scrum
  • Principles over practices
  • Servant over master

Spotify engineering culture part II

Very cool that one of my favorite quotes by Mario Andretti was used in the video:

If everything seems under control, you’re not going fast enough.

To cope with this aspect you need a fail friendly environment and a limited blast radius. For the first focus on fail recovery instead of an fail avoidance. For the latter focus on a decoupled architecture.

A healthy culture heals broken processes! Growing organizations have growing pains. Culture can either magnify or heal them.

Update: Henrik Kniberg on Scaling agile at Sporify

The hour talk that Henrik Kniberg gave on Scaling agile @ Spotify is also available on vimeo:

.