Expat in DevOps land

DevOps workshop with Richard Campbell (@richcampbell ) started for me with long faces and questions unasked from some of the audience. What is HR doing in our special “here”? I developed a product, I lead a team from product concept to product design to Go Live in little less than 1 year, it is up and running… so I raised my Product Owner head and walked through the DevOps minefield.

There are a few things in the presentation I particularly liked and I enjoyed putting them in writing. There are also a few things I did not understand, but there is always hope.

I liked how Rchard referred to a quality software as being an observable software. The contribution of UX designers is crucial and I agree. If the user clicks something and he is asking himself “…now what?” something is not as it should be. Simple is not easy. Everything from an interface that is important for the user should be observable by my 5 years old.

Measurements help us, but only the ones that create positive behaviors and are actionable. This is common sense and I have experienced the reality of this affirmation in my day to day work as well as the opposite of it. Measuring only the number of bugs is more likely to create a negative response behavior and determine the developer to slow down the work.

Only Ops work based on interruptions Devs shouldn’t! Shortcuts are killers, interruptions are killers and they all are waiting behind some corners called technical debts. If your scouts won’t find them, the client will. Better leave developers work uninterrupted for around 4 hours thus reducing the amount of technical debts. Is this even possible? I see floors sometimes emptier than meeting rooms. If your team has more than 40 people, can you even manage 3 hours of uninterrupted development time?

Breaking news for me — pizza is magic. The road to the magic button everybody is striving for, either it is the “Release Build” button or the “Disaster recovery” button is covered with pizza. Without pizza the DevOps culture that will increase efficiency will never be built. I suppose it works, but the side effects of so many pizzas should be well internalized and assumed..

Expand your influence-the HR in me agrees 100% here. Can you write code keeping your head up? Looking ahead of you, over the screen? No. Development is a “head down “job, but opportunities to expand your influence are “heads up” moments. And if you do not expand your circle of influence, your circle of concern stays bigger and suffocates you. Do both. Work and develop head down but “raise your head” from time to time, ask questions beyond your area of control, expand your influence. Take the hard things and make them routine. This should be the mindset.

Not easy to match the concepts presented with the reality from our projects as I see them. Agile seams to be called now simple: Software Development and DevOps should soon arrive to the same name. Now it tends to be a magic hipp spray that management heard about and is willing to invest some in order for the software to smell nicer.

Double happy after this session: I have learned something and I have succeeded to expand my circle of influence “inch by inch, little by little”.

With feedback comes quality. Give and receive. Do not be stingy. This article welcomes your comments.