Dev Ops teams use a lot of tools. It’s part of the trade, so it’s natural that there is focus on the best ones to use. However, it’s not the tools or ‘methodologies’ people should focus on. It’s the delivery of potentially releasable software. The danger is that the focus falls on the former, not the latter. The tools and techniques are only there to help get the product delivered. Really, when it comes down to it the tooling is only there to help automate so that you can reduce the time of your feedback loop.
Let’s imagine we are senior managers at a company and we want to get a new product out to the right people, at the right time, with the right functionality. Lean and Agile principles, as well as the tools chosen can help teams do this better than traditional methods, of that I am sure. The common danger is that people become too focused on how they are working not what they are working on. Processes and Tools are only there to help us deliver working software.
This is supported by the first line of the agile manifesto: “Individuals and interactions over processes and tools”. Again, the tools are only really at their most useful when they are working to support people working together to deliver.
One of the teams I worked with really engaged with this subject over a beer at the end of the day. I asked them to consider this: how can we use these tools to liberate us from our constraints? How can we then use agile principles (such as fast feedback loops, responsiveness, flexibility, greater communication) to further reinforce that liberation so that Dev Ops teams are seen as a race to “yes, you can” rather than the current “no, you can’t”?
My contention was that if Dev Ops did this, they would be driving speed to market, improving competitive advantage and helping deliver quality product – rather than the most common perception that I currently hear, which is they are an expensive inhibitor of progress at the crucial final stage of delivery.
