Our ultimate objective is to help our customers be successful. We have strong opinions on what successful companies look like and what is important for an organizational culture to support sustainable success, but that is a topic for another time. For the technology organizations or departments we work with, our objective loosely translates to

Many organizations put their faith in Agile and DevOps practices to achieve this, but fail to get the results they are hoping for.

Last year I was invited to help the Queen’s Hyperloop Design Team improve their chances in the SpaceX competition. They had just been informed that they did not make it into the last round of the competition, so we focused on setting up the team for success going forward.

When it comes down to defining DevOps, the industry itself is guilty of muddying the waters, grabbing every opportunity to turn the newest hot term into a lucrative service offering, regardless of how that term is understood. This has lead to as many definitions as there are opinions with DevOps being described among other things as automation practices, a CI/CD pipeline, a philosophy related to maintaining IT infrastructure and even a job title. However, when Patrick Debois back in 2009 embarked on a mission to bring the Agile mindset to the world of IT operations by choosing Ghent, Belgium as the location to organize the first DevOpsDays conference, my understanding of his intent was:

Many teams claim to follow agile and lean practices, yet are still challenged to deliver valuable software on a regular basis. Often, agile practices increase the transparency and visibility of the delivery process and, in turn, the intrinsic quality of the produced results. This creates the perception of an agile delivery model from within the system but rarely is the outside perception aligned with that view.