When it comes to defining organizational structures that support product development, it is important to remember the idea, introduced by computer programmer Melvin Conway in 1967, later referred to as Coway’s Law: “…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations….“. Effectively, this law means that overly complex and politicized organizations, with overwhelmingly complex communication structures, will produce overly complex systems and products.
We often see companies copy-pasting complex commercial frameworks (containing the word “agile”) that can be easily ‘unpacked and installed’ or, instead, over-engineering their own, home-baked complex internal models that comfortably support existing projects, programs and portfolios (Here, “comfortably” – means seamlessly fitting and really not challenging what is already in place: hierarchical complexity. Instead, weaving in new, over-loaded terminology to re-define old things). Usually, this is accompanied by claims of artificial success.
One of the examples of the above is artificial ring-fencing an existing what is usually known as a strategic portfolio with an “agile ribbon”, and mapping it to a portfolio-level layer of some commercially popular scaling model or renaming a “strategic portfolio” into an ‘agile theme’ or ‘agile folder’, or ”agile briefcase’, ‘agile body of work’, while renaming its supportive organization (hundreds of humans) structures into fleets, tribes (borrowed from Spotify model, despite its co-creators’ advice NOT to do it), families, etc.
This approach usually provides a temporary sense of satisfaction for an accomplishment. However, it is an illusion and is pain-killing effect is short-lasting.
Artificial ring-fencing eventually crumble.
Perhaps, not the most popular analogy these days (usually the case, when geo-politics are used) is the example with the former Soviet Union:
For more than 70 years, the fake ‘portfolio’ of fifteen republics was united by top-down, totalitarian, centralized regime. In the end, the lack of affinity between the republics (different cultures, histories, desire to be free and independent) had prevailed and resulted in a break up of the Union into independent countries that could’ve healthily co-exist in ways, other than being united by force.
…And the opposite is true too… artificially separating structures that naturally belong together, will eventually lead to inefficiencies and dysfunctions (again, no so popular geo-political analogy begs to be used here: erecting the Berlin Wall between East and West Germany to represent political spheres of control – is a very vivid example of how separation of people that share the same culture and history led harm and unhappiness). Of course, it takes time for an ecosystem to correct itself. But eventually, it does. And as in the above case…
Artificial separating walls eventually crumble.
In product development, “meant-to-stay-together” structures are often artificially separated because of internal politics and other reasons that are described by Conway’s Law: these are usually artificially separated system components (e.g. UI/front-end, business tier, back-end). This separation is the result and reflection of historical organizational design and spheres of control: each component is owned by its own component (or application) owner, who is focused on high degree of output, while designing his own component. This approach leads to a lot of sequential, asynchronously dependent and contractual work – a classic example of waterfall. When backlogs are created and teams are built around components (instead of customer-centric features) we see a lot of excessive hand-overs, end-of-cycle complex integration and local optimization.
What product development boundaries, and subsequently organizational design boundaries (not the other way around!), could be more supportive of customer-centric, adaptive/agile ways of working?
You may consider the following five (5) guidelines when defining your products/services and designing your organizational structures:
- Start small and expand, instead of starting big and then trying scale down (“sunk cost” fallacy is a well known problem)
- Perform enough due diligence when defining your products/services, to make sure that they are customer-centric and are defined as wide as possible, but not so wide that it makes them difficult for Product Owner to manage/own.
- Do not hesitate to challenge historically known projects, programs and portfolios. Most likely, many of them are ‘fake’ and represent a mirror image on existing organizational structures and spheres of control, and as such do not effectively serve needs of real customers. Therefore, they may have to be discontinued.
- Build teams around products/services in ways that enables each team support product development cycle from ‘concept to cash’ (or ‘from soup to nuts’, if you prefer), by touching all underlining system components, sub-systems and applications. Organizational design models that rely a lot on external workers (e.g. vendors) require special attention.
- Limit a number of teams that work on the same product/service, while servicing one Product Owner and working on the same Product Backlog (usually 2-8 teams is the recommended range).