Minimise unnecessary complexity

Description

To keep the system of work (e.g. structure and processes) simple, you might need to reduce unnecessary complexity before you start to scale. Scaling an overly complex system is likely to result in inefficiencies and reduced effectiveness of the scaled system, e.g. scale teams aligned to value streams not specialists.

Keep the scaled system simple, applying appropriate scaling approaches as needed and as simply as possible. Make small incremental changes, validate the outcome with evidence before introducing more change.

Complexity in Organisations

A great part of the literature on scaling starts from the assumption that the Product or the system of Products being developed is too big to be handled by one Product Owner and one Team.

But: is it?

Yes, many Products being developed are very complex and will require some form of scaling concept, but are we sure the complexity we’re dealing with is necessary? Fredrick Brooks in his seminal paper “No Silver Bullet” (http://worrydream.com/refs/Brooks-NoSilverBullet.pdf) examines various aspects of software systems and distinguishes between two types of complexities in a software: Essential and Accidental.

The Essential Complexity is the natural complexity of the problem being solved and it cannot be reduced, while the Accidental Complexity is the complexity added to the problem because of the way we work.

While Brooks refers mostly to the technologies used in building software, a similar reasoning can be applied to organisations: imagine you have a small product to develop, but all your Developers are working from different locations, with bad communication tools, with the customer very far away, using ancient technologies, ... The Product might be small and easy to build, but it is very hard to do so with the setup we have. Let’s call this Product Development Complexity where a part of that is Essential and the rest Accidental.

Now look at it from the perspective of a big company with many development centres who might be even competing for the company’s resources, a structure of management focused on their own careers, silos of information, ... and you can easily understand how the Accidental Complexity of the organisation might make your life very difficult. Trying to make such an organisation agile will give very limited benefits because the problems are not only in the Teams but mostly in an organisational structure that prevents focusing on Products.

So the process we suggest here is to divide the Value Stream[s] in your system in a way to minimise the organisational complexity in selected dimensions, hence creating zones where Product Owners can have a Scope of Accountability where they can be effective and make that part of the system adaptive, i.e. agile. While you might never be able to reach the setup with a single Product Owner having the complete Scope of Accountability, the goal to try and reach there is a powerful way to inform how you can re-arrange your company and reduce Product Development Complexity.

Rationale

A single agile team has a small coordination overhead within the team that a good Scrum Master will work to optimise. As we scale to teams-of-teams we now have additional complexity in our system of work supporting inter-team coordination, that increases with the number of teams in a non-linear fashion.

Even a small reduction of that complexity results, at scale, in large gains and might make a difference between the capability of delivering a product or drowning in overhead.

Relevance at Scale

While this principle is true in every company implementing agility, at scale it usually becomes a much larger problem: large product development is often spread among many departments, many component teams, …, which makes reducing the accidental complexity a huge but nonetheless crucially important problem to solve.

Related Principles

• Scale only when you need to
• Start small and scale success
• Organise around value streams
• Optimise the system of work for the majority of cases rather than the exceptions
• Maximise team empowerment and localised decision making
• Favour Teams with broader Solution Accountability
• Favour Teams with broader Business Domain Competence
• Self-managed teams
• Self-managed Team of Teams
• Maximise Team autonomy
• Provide an impediment removal service
• Minimum Viable Product Owners
• Each team "sees" exactly one Product Owner
• End-to-End Product
• Architectural cohesion
• Avoid Components
• Align towards business synergies
• Reduce factors increasing product complexity