Autonomous teams are an article of faith in modern software development. The shape of our value determines what we can do; it determines our trade-offs between agency and coherence. We all have a purpose, and we all have agency to do something, Simon Rohrer explained in his talk essence and accident in product development complexity at Craft conference. He suggested moving from product focus to value center thinking.
If you work in a vaguely complicated organization, the thing that your individual team delivers is not a product, Rohrer argued. Everything is a value stream. But quoting Chris Mats, the value stream, every quarter, every project, every initiative, every feature, changes. That is why he came up with the concept of value center:
As a team, every team in the organization, you are there because you are valuable.
Talking about products is the wrong language. You deliver value in fairly complex ways to customers.
The web of dependencies is the shape of your value. The shape of everybody’s value is different, Rohrer said. Some of these dependencies are accidental, some are essential.
Value designs organization, Rohrer argued. The shape of your value constrains what your organization can look like, and it also constrains how you can trade off between autonomy and coherence, he added.
Rohrer provided five questions for every value center at every level:
- What value am I delivering?
- How do we coordinate?
- How do we fit together?
- What’s out there for us?
- Who are we?
The five questions are based on a management cybernetics concept called the Viable Systems Model, invented by Stafford Beer in the 1960s.
A system’s purpose is what it does. We don’t get to choose our purpose, Rohrer explained:
We’re not what we ought to do, not what we think we might do, but we are what we do. That is our purpose today.
Rohrer quoted Ralph Stacey: Managers are surrounded by a world characterized by both stability and instability. The world they face is a paradox; it’s intertwined order and disorder. Most managers feel more comfortable dealing with order, but they have to be able to deal with both. He mentioned preferring coherence, because there’s a lot more disorder than order these days.
Summing up, Rohrer mentioned moving from products to value, from autonomy to agency and coherence, and from autonomous product teams to an organisation that is nested and networked. Networking is important; you don’t need to traverse the hierarchy in order to deliver value at all, he concluded.
InfoQ interviewed Simon Rohrer after his talk.
InfoQ: How can we visualize value shapes in an organization?
Simon Rohrer: I’ve been using the metaphor of simple and complex molecules.
A global public cloud operator, like Amazon Web Services or Microsoft Azure, might have a large selection of simple molecules like a file service (S3 in Amazon’s case) or a compute service (EC2). These are really standalone products with minimal dependencies; they might depend on the identity and access management (IAM) team & component. These are like very simple molecules: metals or water.
At the other end, much more complicated, is where I work: we have one product which is a trading platform. It’s made up of multiple dependent elements of value, but they only make sense as a product or service to our customers when linked together: pricing, risk analytics, trading capabilities, and so much more. These are like complex organic molecules: proteins, DNA, etc.
You can decouple technically how you develop and deploy these elements, but you can’t decouple their value.
InfoQ: How do you use the five questions to explore value?
Rohrer: The questions are phrased in such a way as to combine thinking about the individual contribution (person, team, team-of-teams / tribe, etc.) within the larger whole (person-in-team, team-in-team-of-teams, etc.): this balance is essential to maintain effective organisations.
What value am I delivering? If you’re in a team, you want to know why you’re contributing and what you’re delivering as an individual or a pair: e.g. what user stories you’re delivering this sprint – but with that view of why?
How do we coordinate? As a team, you need to understand this; for example, in Scrum it would be a backlog and a sprint plan. This is something you have to do together, not apart; otherwise you tread on each other’s toes.
How do we fit together? This is about integrating what you’re doing: your work isn’t just one damn ticket after another. In Scrum this might be the sprint goal (why do all these user stories add value), and it’s more than that too: how is this contributing to what Fred Brooks calls the "conceptual integrity" of the system? And why are we assigning more resources or time or focus to areas A, B and C than areas D and E right now – what’s that contributing to?
What’s out there for us? This focuses on what cybernetics people call "there and then" – what have we not been focusing on? What could come in the future that we should spend some time planning for, or what is currently outside our scope but might make sense to bring in?
Who are we? This is one existential but important question which asks more – what’s our purpose? We’re "the pricing infrastructure team" – but what does that mean? What’s our responsibility? How does that impact how we balance today’s work from planning for the future, and how we focus on all the other questions?
And the questions apply at all levels: team, team-of-teams, department, whole organisation!