The background
Principles misunderstanding
The way how CI/CD is designed reflects the few elements which are taken into strategy. The Agile principles are taken too literally here, therefore Organizations put much focus on self-organization of the teams.
I am not against this principle, I believe in it. However, there is a gap.
Let’s look on these quotes from Scrum Guide
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
That defines pretty well what self-organized team means, however, it never said that the team can do whatever they want and how they want.
One more quote from Scrum Guide
Development Teams are structured and empowered by the organization to organize and manage their own work.
This quote shows clearly, that organizations often misunderstood the principles. This quote clearly states - structured and empowered by the Organization.
Team’s capabilities
The pipelines planning, creation and maintenance is very often solely based on Team’s skills and ideas. It is connected with previous point and has potential to disconnect the Team from the Organization’s level processes.
This way works for small projects, teams or organizations. But with scale the risks are raising. To name a few of them:
- misaligned processes between projects / teams / components
- metrics on high level (project / team / component) are not collected or cannot be collected
- different delivery strategies
- different deployment strategies
- variety of tools used (price of software, licenses, knowledge base, etc)
Design of pipelines
Without properly defined requirements, capabilitites, goals and processes it is easy to create messy, not functional, badly organized and not easy to measure pipelines. It is not that uncommon to see situation, when the team is forced to use two different pipelines (sometimes even in two different tools). Example is on the figure below.
Actually, this setup is quite often used. Reasons can differ, however, the final effect is always the same.
Another bad pattern can be spotted when the team in fact is constructed from multiple loosely cooperating “sub-teams”. Think about it like about organization within Organization.
This example is not very common in real life, fortunatelly. But it may happen, when team members work in small, detached groups, without proper communication and collaboration. It is easy to describe here all disfunctions related to Conway’s law.
Conway’s law
This paradigm describes the relation between the system’s design and communcation structure.
The way how the system is designed and connected reflects the communication patterns and channels within the Organization. Another words, if communication between teams is dysfunctional, the system will be dysfunctional too. Or, at least, very poorly designed.
Team topologies
Conway’s law and Team topologies book played very significant role in design of this framework. This book should take a very important place in the library of every DevOps Coach. Here you can learn more about this concept.
The example of the topology concept is on the picture below. The structure reflects the composition of the teams, relations between them and responsibilitites towards rest of the teams.
