The SOLID principles for organizing work
Conway’s law states that:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
We also know from the DORA DevOps report that we want loosely coupled code. The SOLID principles can help us write code that has high cohesion and low coupling. I think we can translate those to work for organizations as well, and see how we can help the code be flexible through how we work.
The Single-responsibility principle
There should never be more than one reason for a class to change.
This is really about stakeholders. (See this blogpost for more on how it works in code.)
Aim for as few stakeholders as possible for a team
The stakeholder can be internal or external.
(I expand on what to do to achieve this in another post.)
The Open–closed principle
Software entities … should be open for extension, but closed for modification.
We want change to happen where it makes sense and only when needed. For organizations we get there by team design.
Create small, long term, self sufficient teams that collaborate.
Teams get better with time.
The Liskov substitution principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
How something is solved can change, and you should not have to care about it. The design of the base class helps us find the purpose of the object from the user perspective.
Internal services are internal products
Create internal services as if they would be sold to external customers. We want each part of the system to have a clear purpose and each team to have independent pacing of their work. It also makes it possible to swap it for “off the shelf”-solutions if the service is no longer a part of the competitive edge. (And let the team take on a new project.)
The Interface segregation principle
Clients should not be forced to depend upon interfaces that they do not use.
We don’t want code to be weighed down by conforming to rules that does not apply to it. The same is true for teams.
Let each team own their process.
There can not be one flavour of agile in a big company. Instead, each team should be provided with the time and expertise to learn how to improve their own work. Be clear with desired outcomes and core values, let the team do the rest.
The Dependency inversion principle
Depend upon abstractions, not concretions.
This is about integrity.
No micro management.
Give the team one stakeholder and the capabilities they need to fill one purpose for that stakeholder, then trust them.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about agile methodology, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.