When talking about agile practices, the distinction between projects and products often comes up. The idea is that the limited lifespan of projects tends to be pushed onto the delivery team, which leads to the team being assembled at the onset and dismantled when the project completes. Agile practitioners advocate for a product view, where teams are dedicated to a specific product and deliver incremental value at a regular cadence, across initiative lifespans. This usually works really well, and I too favour a similar way of working in most cases. However, I have recently seen various examples of this idea being misinterpreted, which creates a situation in which teams struggle, largely due to their setup.
When Chris Chapman, a friend and colleague, referred to an article on LinkedIn to explain his growing disinterest in Open Space conferences, I started writing a quick reply. The quick reply soon outgrew the limitations for a LinkedIn response and therefore ended up as this blog post.
First of all: I love Open Spaces, absolutely love them. Second, it’s a shame there’s not more real ones…
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
“help our customers get the biggest return of their IT investment”
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:
“to decrease time to value supported by solid partnerships and automation practices.”
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.