In the last episode, I introduced "Conway's Law" - an observation of how our organisational structures influence our software structures. In this episode, I want to talk about how we can utilise this law when we want to improve problems in our software structures - commonly referred to as the "Inverse Conway Maneuver". Why you might be interested in this episode:
Or listen at:
Published: Wed, 11 May 2022 16:06:42 GMT
Links
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
In the last episode, I introduce Conway's Law, an observation of how our organisational structures influence our software structures.
In this episode, I want to talk about how we can utilise this law when we want to improve problems in our software structures - commonly referred to as the Inverse Conway Manoeuvre.
Why you might be interested in this episode:
- I'll give a recap of Conway's Law and the negatives you may be observing
- I'll talk about how the same law can be used to reorganise our teams to improve on those negatives
- And I'll give you ideas from the Team Topologies Book, which builds on this, by defining 4 team types and 3 team interaction modes for improving the flow of our software change
Okay, let's start with a recap.
Wikipedia describes Conway's law as:
"Conway's law is an adage stating that organizations design systems that mirror their own communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure - Melvin E. Conway
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields."
Because our organisations have traditionally been siloed by technical discipline, we find ourselves often needing to cross boundaries to get work done. Crossing that boundary became increasingly complex when parties either side had misaligned goals and incentives.
We quickly found we developed communications problems - a "them" and "us" mindset. And you may observe it in things like teams trying to reinvent the wheel, or complaining about insufficient cooperation, or blaming others, or defending their responsibilities.
We became siloed and fragmented as people.
Thus, is it any surprise that our software takes on those same characteristics?
Knowing of the effects of Conway's Law, that organisational structure has on software structure, we can use Conway's Law to influence our software structure by changing our organisation structure.
But this does beg the question, if we are going to change our organisation structure, how do we change it for the best outcomes?
It should, however, be noted at this point that there are no structures that will be perfect. There will always be trade offs. Certainly, we shouldn't be static. We need our businesses to be agile, to react to modern business demands, and with this comes changing business needs - and those changing business needs will need to be reflected in our team structures. But again, a balancing act against constantly rearranging our teams.
As I talked about in the last episode, organisations moving to small cross-functional teams are generally finding success.
By having small cross-functional teams with clear responsibilities, authority and resources for specific part of the software system find that they rarely, if ever, need to go out of the team boundaries for work to be done.
This greatly removes many of the negatives problems found within the traditional structures.
By having the team consisting of the relevant skills and authority, they become much more self-sufficient and thus will be more effective and able to adapt quicker and cheaper to changes in the market.
But there are still decisions and trade-offs to be made:
- How do we want our systems, and thus our teams, to be split?
- How do we ensure that disparate systems and teams work well together for the best outcomes?
- How do we avoid duplication of efforts between teams?
Repeating what I said, this is likely to be a balancing act and one that will be unique to each organisation.
Some advice on how to structure our teams comes from the book "Team Topologies: Organizing Business and Technology Teams for Fast Flow" by Matthew Skelton and Manuel Pais.
In the book, the authors recommend 4 types of team:
- Stream Aligned
- Enabling
- Complicated Subsystem
- And platform.
A Stream Aligned team is aligned to the flow of work from usually a segment of the business domain. This is where we expect to get the most benefit, and where most of our investment is likely to be placed - you may think of these like a Product team.
Enabling teams help a Stream Aligned team to overcome obstacles and also help to detect missing capabilities. This helps the Stream Aligned teams to gain additional knowledge about products, techniques and procedures. The Enabling team will likely be few in number, and will work mostly as coaches to the Stream Aligned teams to improve their capabilities.
The Platform team will be providing a compelling internal product to accelerate delivery by the Stream Aligned teams. Think of the platform team as being an internal supplier to your Stream Aligned teams. They're there to make it easier for the Stream Aligned teams. The Platform team would normally take on tasks that would otherwise likely be duplicated by the Stream Aligned teams and provide them as a service. The benefits of a Platform increases with the quantity of Stream Aligned teams using it.
And finally, we have the Complicated Subsystem team where significant mathematical calculation or technical expertise is needed.
The book also talks about interaction modes between those teams. It stipulates between the teams there should be at most, one type of interaction:
- Collaboration
- X-as-a-Service
- Or Facilitation
Collaboration is defined as working together for a defined period of time to discover new things (APIs, practises, technologies, etc). This may be two Stream Aligned teams working together to understand how best to achieve an outcome that requires both of them. Collaborations are expected to be short lived and should be for a specific purpose.
X-as-a-Service is defined as one team provides, and one team consumes, something as a service. Most often the Platform team will provide a "Platform-as-a-Service" on which the Stream Aligned teams will build upon. Think of that Platform team providing the foundations for the Stream Aligned teams to be working. This is likely to be a much longer lived interaction, with the Stream Aligned teams effectively becoming the customer of the Platform team.
And Facilitation is defined as one team helps and mentors another team - such as with an Enabling team helping a Stream Aligned team improve their Continuous Integration and Deployment processes - they are likely to be assisting with knowledge sharing, training and coaching to pass on those skills to the Stream Aligned Team. This again would be expected to be a short lived engagement and be for a specific purpose.
The book, through the 4 team types and 3 interaction modes, allow us to model our organisational structures with the aim of improving the flow of change through it. They recommend using the team types and interaction modes to explore how to reduce interdependencies and encourage self sufficient teams.
In the shownotes, I'll include a link to the Team Topologies website, which includes those key concepts, and I'll also include an article which describes the relationship between the Inverse Conway Manoeuvre and the Team Topologies very well.
In this episode, I've given you a recap of Conway's Law and the negatives you may be observing. I've then talked about how the same Law can be used to reorganise our teams to improve on those negatives - the Inverse Conway Manoeuvre. I then shared the key ideas from the Team Topology book, which builds on that Inverse Conway Manoeuvre by defining 4 team types and 3 team interaction modes for improving the flow of our software change.
Thank you for taking the time to listen to this episode and I look forward to speaking to you again next week.