So, I got to speak at Test Leadership Congress 2019 next June. As a grim Finn I usually keep my composure, but when I got the mail from the organisers that I was accepted as a speaker, I danced. Getting to speak at conferences is always a tremendous honor and a unique opportunity to share something that might benefit people in their daily struggles. But it is something quite special when the stage is in my absolute favourite city in the world, New York.
I have tons of ideas what to speak about in June, but the core idea of my presentation is “that everything else in DevOps”. Majority of DevOps presentations are about tooling, about different technological solutions for tackling in collaboration, building the software, task automation, deployment, production usage, etc. but it is rarely addressed how DevOps entwines with culture, leadership, management, business, team building and of course testing. For example one common topology in DevOps is that business acts only as a feeding mechanism for a development team, which has only partial control over operational functions and there’s no feedback loop from production to business or other elements of development and operations. Bandage is applied in the form of CI/CD pipelines, higher automation coverage and methods such as SAFe, but nothing really improves.
First thing to fix here is the relationship between the people in business and technology. Sometimes it might seem that they’re not even the same species, but once you find that common thread, that relevant reference that all can relate to, you get a common goal that all with gladly pursue. I will present few references from our context, but copying those is not the point. Instead try to understand what happens in that reference and what are the reasons for doing things the way they are done in that reference. If that proves difficult, ask. That’s why I will be there.
Something about the reasons. There will always be people who want “feathers on their caps” by forming another huge transformation program, but you have to fight this in every turn. Why? Because in huge transformation programs feedback loops grow too long and you are bound to get feedback only from things you did a month or two ago. If you’ve played video games with massive lag, you understand what I’m talking about. Steering, resourcing, quality control and pretty much everything is quite impossible with massive lag. And worst of all, feedback from production is also gotten way too late. More and more people understand that only a portion (studies indicate that one third) of well defined, well designed, well coded, well tested and well deployed features bring actual value to the company. There are ways to improve these odds, but bringing latency to feedback loops and slowing down feature throughput isn’t one of them.
The only way to learn anything about working together and going through everyday challenges in continuous deployment is to form a context that is manageable by everyone involved. So yes, something small. Something that benefits internal or external customers. An app. A service. A widget. Anything that requires you to practice all stages of DevOps cycle and set all the tools, processes, whatnot in place. Once you have that mechanism in place and some practice rounds under your belt, you can scale that to pretty much anything. You can even start preparing for that huge transformation program. And you are way wiser than few weeks ago when you had no practical reference points. You will also learn tons about things you really need and don’t need. Forming a support team that works in shifts seems easy on paper, but wait until you do that in practice. The company that provided your container platform was just bought by a bigger player with new rules for licencing, support, version control, etc. What should you do? Before you released into production four times a year and you had time to test everything, but now you’re releasing into production ten times a day. What should you do? You are out of toilet paper. What should you do?
Join me in the end of June and I’ll tell you. 😉