The Telephone Game (that is engineering from hell)
Back in a previous article (how far do you go) i mentioned a game of telephone. If you've never played the premise is simple, find 10 people and send a message down the line of people by whispering it and
by the time the 10th person says it aloud the message is off. Here's a real world example that is so expensive, it has completely outdone Virtu's efforts of the most expensive game of telephone.
I worked for a company, no names, in the biometric identity space where sprints are ruled by rumors. Not one single developer had a matching story with a product "owner" that described the direction of the work. Its ok
if the business is moving at ludicrous speed and changes the direction of development a lot. Changing direction for the sake of business has been studied at lengths in order to avoid the situation i'm describing. Its called Agile,
i'm sure you've heard of it and if not check this out. The health and growth of a business can be gauged by how many direction changes its management imposes on developers but not without moving as a unit. If there is a problem where not one
developer, product owner or manager can corroborate, agree or understand collectively what the direction and the finite units of work are for a single sprint you can undoubtedly find a miscommunication in the chain.
The "chain" can take many forms, its an abstract notion for anything with links in the process. But the most important, without any contender is the value chain.
As a DevOps engineer, I will wager, that if you bring this article to your manager you will get a look with a sideways head. It is because the definition of DevOps is lost, unfortunately our success along with the company's depends on it. The reason your
DevOps manager won't understand this is because he or she is not a generalist. Instead, your manager is from one of two backgrounds either a) The Ops team and DevOps has been cornered up in that category or b) Someone close to software engineering, like a CTO or a VP of Engineering. Neither of these
people have a ton of concern with product owners and probably have never heard the term Value Stream but its evident they're all struggling with how to turn requests from the top into units of work on some level. Ironically, you will have a difficult time convincing managers to open the silo door or if you're like me
and just do it anyway, you'll have a somewhat less difficult time explaining how you got some good results by thinking and going outside the box to cure this ailing game of telephone.
Why does this happen? There are lots of reasons messages from executives get mangled on the way down to the hands and keyboards of developers. Sometimes a lot of requirements are left open to interpretation. Other times, a critical link in the chain isn't very engaged with their job. Sometimes, one of the avenues into the backlog doesn't have any control layers.
Whatever the cause you can count on reason for them Conway's Law. Melvin Conway.. a sixties programmer, I hope he surfed and listened to awesome music, gave us this adage which is true in practice a thousand percent of the time:
Conway's Law; "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.""
If thats true, then your system is only as good as the companies ability to communicate. Because of that, I see a Corallary:
Corallary: If a system design is constrained to a company's communication structure and value streams are a reflection of a company's communication structure then system design should instead reflect the value stream and communication structure should reorganize to reflect the identified value stream.
What does that mean? Its simple but you have to know what a value stream actually is first:
Value Stream: The feedback loop into which future work arises.
An example of a value stream:
1) Your website offers a service
2) Your service and therefore website's popularity is at the mercy of its customers
3) Your customers congratulate, complain and request modifications, fixes for bugs or new services through all kinds of avenues (like calls, emails, etc)
4) Management reviews these and tries to align them with other, sometimes unrelated, directions of company success
5) Mid managers meetings with executives to highlight these directions and get prioritized
6) Backlog gets populated with epics, tasks and other varying scopes of work
7) Units of work get created and prioritized
8) Developers complete the work
9) The work goes out into production where customers again vote on its utility
Those points in time are all the links in the chain. Chronologically, each step is a perfect candidate for miscommunication to occur. As a DevOps engineer, you're the one with the skills to eliminate this and with that Corollary the problems that arise from the game of telephone structure will be eliminated.
Ok well whats an example of a system design that reflects a value stream?
The head of the value stream is the ingestion points of all things that produce actionable work. Removing the constraint of communication structure eliminates the mutation of actionable work. We're then left with a system design with ingestion of actionable work as a first class citizen and the paradigm for design changes to a more business centric one.
Independent of the shape of organization structure, adjacent or hierarchical teams, the design itself comes between the source of work and developers and nothing else.
The goal is self sufficient dev teams that have foreground visibility into their customers; A tenant of Devops culture.
This is a huge jump for a lot of companies who are starting from antiquated work flows, strict hierarchical structures, and slow processes designed to catch mistakes a general fear of loss of control is usually at the top of the emotion list. Either find a team desperate enough to try anything or suggest a hybrid approach to keep things reasonable. Autonomy is often the bane of complacency, so we want that! Distrust or low confidence from managers to dev teams usually comes from dev teams visible complacence. Its a bad cycle, if you remove the chains and blinders devs will feel more responsible and make more decisions on their own, increasing ownership and envigorating them to push further, build better relationships and foster the creativity that make history. That type of ownership cannot be won with strict pecking order and siloed units of work. Fortunately, this isn't just the beginning of a better culture its a way to respond to customers by eliminating miscommunication.