Systems thinking principles: Building a DevOps support model
It's time to embrace a DevOps support model. Everything we do has consequences, good or bad. We're interdependent. That's why no team should work in isolation.
A developer and I once discussed (possibly argued) quite enthusiastically about the consequences of the decisions we were making as a delivery team. An application program interface (API) we developed was to specification. It was beautifully documented. We had tested it thoroughly, and we were proud of it. By all appearances, our job was done. But we still didn't know how the downstream consumers of our API would receive it.
When asked, the developer's responded, "We don't care about that."
He felt that it was up to them to adjust their consuming service based on what we gave them, seeing as they were clearly told what we were delivering to them, and that we had “done it right”.
What ensued was an impasse, a robust "discussion" wherein I argued why that should be our business, based on systems thinking principles.
We agreed to disagree.
There are always consequences
Everything we do has consequences, good or bad. That's because everything, while it may appear independent, is always interdependent.
Interdependence is fundamental to systems. Our life is a system. Everything is a system.
Everything is also, conversely, a component of a bigger system.
Every component in this picture is both a component of a system,
and a system itself.
In the scenario on my project, as it turned out, we had not known about one of the mobile application team's requirements, and their whole application failed upon receipt of our API. The result was several weeks of API rewrites and retests. This, of course, is "waste," a topic for an essay on Lean, which is intimate to successful DevOps, but more about that on another day.
The consequences of poor software design, development and delivery -- of a poor DevOps support model -- are always felt, whether that be by the operations folk, or the customer, or the shareholders, or whomever.
Likewise, the consequences of teams that work "together" but don't consider the consequences of their actions endanger others.
Systems thinking principles in teams
Teams don't work in isolation. They're a part of system. Nowadays, we use terms like DevOps to describe this culture. ("Culture" is how we deal with work, not how many beanbags we have.) It means having a real DevOps support model.
While tools help us achieve these aims, it’s systems thinking and the culture that actually get us there.
While tools help us achieve these aims, it's systems thinking and the culture that actually get us there.
When we enable and educate our teams to be part of a system themselves, they consider not only the individual components of this system but also the system as a whole -- and the consequences of their actions.
Rethink your DevOps support model
The person who wears the support pager is the person who has the best view of the system's bad behavior and the system's supportability. This person knows all too well the consequences of the actions taken by those earlier in the lifecycle.
Traditionally, this person is operations personnel.
However, in Mature DevOps practices other personnel in the team carry the pager too. At my current employer, all developers and some QAs do too.
We do this because we espouse ownership (and consider the consequences) of the work our teams do.
In my case, I'm not a systems engineer and when I'm personally unable to resolve the pager alerts, I seek the assistance of someone who can. They're usually very willing to do so because they benefit directly from educating the rest of us.
It all dovetails
So much can be said and written about the dovetail of systems thinking principles, Lean, Agile and DevOps.
But for now, I will leave you with this summary and leave the door open to further discussions:
Supporting a system and empowering team members to support their system aids understanding of what causes issues, provides insight into regularity of recurring issues, and improves empathy and ownership -- and quite rightfully has everyone thinking in consequences and thus systems thinking.
