culture

Continuous delivery can be a frustrating topic. Those of us who use this workflow will never go back to legacy ways of working.

I was recently in a conversation on social media about the role of a software engineer. As a SWE, what you bring to the table is knowledge of efficient algorithms and data structures for general computation.

Continuous Delivery requires an entirely different mindset from classical artisanal delivery. For example, we always prioritize operations over development. If we cannot deploy something to our production environment, then nothing else matters.

Whenever we want to solve a problem or build something useful, we have decisions to make about the tools we choose.

Hope creep is the plague of value delivery. We assume that since something worked in the past it will work again.

Should we use Scrum? Kanban? Is Kanban for support and Scrum for development? Is Scrum for newbs and Kanban for elites?

In my last post, we talked about common metric anti-patterns that are focused on the process instead of value. In this installment, we will cover alternatives that can help us remove waste and improve the flow of value.

I was speaking at a DevOps meetup in Finland recently and was asked, “what does DevOps mean to you?” I love that they started the conversation that way.

As we try to improve the flow of value to the end-user, the first item that usually gains focus is the productivity of development teams and how to measure it.

Delivering value to the end-users means we need systems that are useful, secure, and resistant to the shark-filled acid bath of the cloud environment.