When IT organizations start down the path of using new methodologies like DevOps, Continuous Delivery/Integration, and Agile workflows, there is a bias to approach things the way you always have while trying to be open-minded and searching for opportunities to leverage the new to eclipse the problems of the old. It is rare for an organization, particularly one that has some time and history behind its practices, to fully embrace new approaches and go all-in from the start.

“It takes too much time away from our established process…”

“We can’t abandon existing infrastructure…”

“This money-making application over here, OldFancyThing, doesn’t fit a continuous delivery process, so we have to keep doing what we’ve always done and to do both is too hard…”

“But we’ve always done it THIS WAY…”

These are likely very familiar responses you’ve heard, especially recently. They’re also examples of reasoning from analogy. There are a lot of opportunities that are missed as a result of this sort of thinking in organizations.

How do you escape such tethered thinking? By insisting on reasoning from first principles.

Reasoning from first principles involves looking at problems from the ground up each time, distilling the actionable targets down to their most basic components. It takes more effort than reasoning from analogy and most people don’t want to spend the time or energy deviating from a working path. Also, the time and energy may not yield a new target or end state that is of more value than existing approaches.

Innovation requires both iteration and bifurcation, with the latter being the territory of reasoning from first principles. We’re familiar with iterative change; in fact, Agile methods essentially demand an iterative workflow but also require breaking down bifurcation into quick cycles of work. Legacy or waterfall project workflows essentially demand bifurcation but at the cost of reducing the impact of the change due to elongated development cycles, thereby reducing innovation. How many of us have been involved in a two-year project with waterfall structure only to have it be canceled around 18 months because the once-valued innovation was no longer that innovative?

For this reason alone, adopting Agile methodologies for your software development and infrastructure engineering practices puts you into a better posture for increasing productivity and delivering innovative value. Continuous delivery & continuous integration workflows are the moving parts of the Agile engine. Sprint stories and sub-tasks are the fuel of the engine, and the engine’s output is iteration and bifurcation over short spans of time. In a sense, you are almost guaranteed to succeed and grow, with minimal risk-taking. What are you waiting for?