“DevOps Free”​ DevOps (the hype-free series on accelerated engineering)

Sometimes it happens that a simple concept gets so embraced that a plethora of tools, frameworks (and … let’s say it, sometimes also lots of B.S.) start to appear around it to the extent the initial concept gets lost. Let’s be fair here, most of the tools, frameworks, etc, have a good intention behind. But commercial incentives to sell the tools and frameworks, among similar motives, end up in a mess and a big ball of confusion. Our little world of software / systems engineering is ideal for this phenomenon to occur!

For a while I thought of writing some ideas on “getting back to basics” of some common phenomena I happen to see on my work over the years. It’s not that people don’t get it right … it’s just that there is so much hype and options around initially simple concepts that one gets lost around them. This “B.S. Free” series of posts I’m starting today have the purpose of giving some very simple tips, on simple language, as buzzword free as possible, to get back to the basics and not getting lost in the jungle of acronyms and fancy stuff.

So, I though DevOps is a good example of such a thing. Ask someone about DevOps these days and answers typically will include implementing CI / CD tooling, reengineering to cloud architectures, migrating to microservices and of course, hiring “DevOps engineers”, among other stuff. All this is fine and each of those things is generally good in itself, but to my humble point-of-view, miss a much simpler starting point.

Truth is that DevOps was born as a way to improve flow through the whole value chain of software, from the very idea to its implementation and usage. Agile had paved somewhat the way to flow, so DevOps originated as a complementary idea (comparing Agile and DevOps as competing approaches is wrong, BTW). Many things we associate with DevOps today, such as C.I. / C.D. existed (though in less fancy incarnations) long before DevOps even had a name. For example, C.I. could well be tracked to the “don’t break the build” practice that Microsoft implemented in the 90s (and probably someone with some time and patience to dig in history could perfectly find other examples that predate the one I gave). Those things we associate with DevOps today were somewhat adopted by the DevOps movement because they help, but are not DevOps in themselves. Nothing wrong with that, but it’s good to have that in mind.

So, you want to do DevOps? It’s OK that you are researching tools and stuff because eventually you may need them. But before that, why not going back to basics? Something as simple as the following will shed a lot of light on where you really need to invest to improve flow …

  1. Which are the sources of your requirements? (this typically maps to users, areas, etc)
  2. Which are the stages through which those requirements go until they reach production? (this typically spans prioritization processes, approval processes, development, build, testing, more approvals, etc)
  3. How long does the whole process lasts typically? (this goes typically from days to months)
  4. How long would it be ideal for it to take? (though it’s cool to say we would like to deploy or release everyday, is that really the cadence your business needs or you are overacting?)
  5. How long does each stage last typically? (find worst case, best case and some middle ground scenarios and you will get an idea… you don’t need advanced analytics here yet)
  6. Which of those stages could be accelerated and how? (more in this later)

BTW, I’m not inventing anything new here … this goes back to lean / Kanban approaches to flow, but I’m intentionally avoiding ANY buzzword, framework and terminology.

As simple as it seems, going through each of the above questions will uncover lots of opportunities for improvement that, many times, are much simpler and cheaper than implementing C.I. / C.D. or rearchitecting your solution to a microservices architecture, etc. For example …

  • You may find that one of the sources of de-acceleration is a long approval or prioritization process. No matter how good your integration pipeline is, requirements will already be late when they reach them. Simple things such as time boxing that stage can yield lots of improvement.
  • You may find your build process is slow or too monolithic. This can be improved by simpler means than going full C.I. / C.D. and, honestly, cleaning up your build will definitely pave the way to C.I. / C.D.
  • You may find that some re engineering could help decouple some components which are modified / built /released more often than others. This can be done before even speaking of microservices.
  • You may find that a single group is attending requirements from sources (e.g. users) with very different time requirements and rhythms. Having both sources being attended as decoupled as possible can help reduce friction.

In general, once you have identified those stages where flow is impeded, solutions typically fall into the following types:

  • Eliminate the stage. Think what will be lost if you eliminate that stage. Many times I have seen approval stages that always yield “yes”. What’s the point in them?
  • Simplify the stage. Think what will be lost if you trim the stage to a simpler incarnation. A simple way to do this is to “time box” it. This typically applies to analysis and business case stages. When you time box them, you force to focus on the important stuff or otherwise, to work on smaller chunks of work.
  • Cleanup the stage. This is a variant of the previous one. Sometimes a stage takes time because is badly approached (e.g last minute asks to the security team to approve a design).
  • Automate the stage. This is typically comes after cleanup.
  • Decouple the stage. This applies typically to prioritization stages where you try to prioritize incomparable things, such as requirements from different business areas with very different needs, urgencies or rhythms. The best thing that can be done here is to decouple sources (e.g. have one team attending a source and another team attending other).

The list could be longer, but in most cases, you will find that your main de — acceleration points end up in one of those cases.

So, what I’m saying above is not that the cool stuff is wrong, but that simpler stuff could be done before spending a lot of money and efforts. And the simpler stuff can pave the way to the more sophisticated stuff. Once you do the above, opportunities to use cool technologies and tools will be more obvious and you will be in a better position to use them wisely.

So going back to how we started this little post … sometimes things are simpler in nature and get complicated as they become popular and fancy. There’s nothing wrong with that, but going back to the basics, speaking of problems to be solved in simple language (jargon free, buzzword free, B.S. free) will definitely help make better usage of the fancier stuff.


Originally published at https://www.linkedin.com.

Passionate, Driven & Hands-On Tech Leader 👓🚀 | Partner & Head of Consulting (Cyber, Agile, Tech, Digital) @ KPMG AR | Views are My Own