DevOps: A Nursery Tale

Once upon a time, there were three bears: a mama bear, a papa bear, and a baby bear.  The mama bear looked long-term at what needed to be done by everyone and made sure that everything was OK – let’s call her Ops.  The papa bear did all of the grunt work (and sometimes grunted during it!) – let’s call him Dev.   A negative stereotype would say that the baby bear played with things and cried when they broke.  But in reality, the young bear was an active learner, learning more quickly than anyone else, doing real-world testing and trying things that might otherwise go untested – let’s call the little one Qa.  They each had their own siloed roles, and nobody tried to take on anyone else’s role.  That’s just the way it was, and they were basically happy.

Then one day, Papa Dev and Mama Ops realized that they weren’t communicating well and didn’t like that, so they went to Dr. Venn, a couple’s therapist.  Papa Dev thought that a lot of his hard work was under-appreciated.  Mama Ops thought that Papa Dev needed to show more commitment to “the big picture” and be less secretive – that with better communication, more of Papa Dev’s time could be spent on useful work.  The therapist said, “You two need to communicate better and spend more time working together, and I know you both care about the quality of what’s going on.”  Dev and Ops agreed they did, so Dev and Ops agreed to communicate better.  Dr. Venn said he wanted to chart out how they interact with each other.

“Yes, but what do you do together?” asked Dr. Venn after making his diagram. “Do you really spend quality time together?  You know who you are, but how do you interact?  Because that’s where relationships are built.”  Dev and Ops thought, and realized that they focused on themselves, not on their interactions, and certainly not on productive interactions.  What if whenever they were together they concentrated on what benefited all of them instead of just themselves?  They realized that they were too self-absorbed, and spent too much time doing their own thing instead of really getting along and doing things together.  “OK doc,” they said, “How do we save ourselves?”  “Well, what if you thought of each other as much as yourselves?  Let’s think of you two more as a couple instead of individuals, taking each other into account.  I bet you can relate better as a family team with Qa, too, and maybe Qa can be part of your inspiration.

Qa had heard a lot of this, and wanted to help out.  Qa was good at counting things, and had the most time and access to be able to do so.  It turned out that Mama Ops liked this, and called them her little metrics.  Qa looked up to Papa Dev, and in the spirit of Dev work (Qa was born with it, but Dev thought it was from watching Dev work and modeling the behavior), could follow a similar “code” that Dev liked, and Dev called them his little automation test cases.  Dev and Ops talked excitedly to each other about Qa’s metrics and automation test cases, and found themselves communicating better with each other in the process.  Everything seemed more relatable.  In fact, let’s update that Venn diagram.

Mama Ops and Papa Dev started to feel less stressed, as if they’d bridged some kind of gap.  They started understanding each other’s roles.  They joined in and helped where they could, like they were on the same team.  Ops no longer felt left out of Dev and Qa’s time together where they seemed to talk a special “code” between them.  Dev asked Ops for direction instead of guessing or doing excess work that never got used, and they both appreciated how this cut down on meaningless work.  Ops was more clear about what was expected of Dev.  They realized they “owned” what they did instead of merely building things.  The quality of what they did improved.  They found problems earlier, when they could be more easily handled (and started to notice that they had fewer problems overall).  There was faster feedback too (nothing bottled up that came out badly later).  Their relationship improved while spending more time together, understanding each other better, and concentrating on helping each other instead of hiding from and sniping about each other.  They felt like they could get their day’s work done easier and quicker.  They were not siloed any more.  Everyone was more stable.

Dr. Venn liked how things were going, and suggested that they focus on continuous improvement as they go through their daily routines.  He reminded them to always think about the importance of collaboration, to always be accountable to each other, and to help each other to, well, help each other.

This has been fun, but now I’d like to break away from the story to make a few key points .  Family life and work life are not nursery tales.  I have oversimplified everything here, creating allegories that some might find downright insulting (I’m really just oversimplifying to make it overly simple).   QA is no baby – Qa is in fact the capable enabler of good things in this relationship, and I have edited this many times to try to highlight that.  Unfortunately, by emulating a nursery tale, I had these siloed roles that I had to match up to specific characters, casting QA by analogy into a youth role.  The marriage of Dev and Ops is always worth saving, and seeing each other’s value while avoiding “me vs. them” adversarial siloed roles helps.  Siloing, bad communication and unproductive corporate routine are the bad guys here – neither Qa, Dev nor Ops are inherently bad.  Marital strife and attempted resolutions of marital strife are not light topics.  I wanted to throw in a stakeholder/ steak holder pun in here somewhere, but that takes away from the seriousness here.  Everyone is part of an “us” — there is no them.  What I’m really trying to say here is that DevOps isn’t complicated, but still has much more detail than “Play nice with each other”.  The teams can work together as one intrapreneurial team towards a common goal in a logical way, concentrating on the areas where you excel, or you can abandon the collaborative approach and try a different approach which is likely to introduce communication and knowledge gaps into the system.  Given the choice, the better communication and knowledge while giving everyone what they want sounds preferable.

By the way, for a more serious talk about DevOps, please join us on Tuesday, Jan 31, 2017 @ 11:00AM EST / 4:00PM GMT for a webinar about DevOps challenges facing QA.