Prior to the burst of the .com bubble the IT industry was obsessed with project management. Our projects always over-ran, they rarely delivered on their promises and almost never met the expectations of the sponsors. We looked to project management to help us improve the situation. The v-method saw a brief resurgence in popularity. Some companies built powerful project management departments. Some businesses tried spreading project management skills throughout their organisations. We tried both of these approaches at AOL and neither particularly worked.

Then after the .com bubble burst in 2000 another solution to managing software projects was proposed and the Agile movement was born. The Agile movement was so successful that I haven’t worked in an organisation using any other method for over a decade now.

The Agile movement was first and foremost a cultural movement albeit one that was augmented with tools. Agile asked that project sponsors work closely with development teams. Agile asked developers to deconstruct their projects and develop and demonstrate smaller pieces of, still valuable, functionality more often. Agile encouraged developers to use this capability to rapidly incorporate changing requirements into their projects.

If I may be so crass as to quote from the Manifesto for Agile Software Development itself:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools…”

Automated build and test tools, continuous deployment and integration tools and story management tools can significantly extend the capability of a development organisation but they are not essential for Agile software development. Those tools would provide value to any organisation using any development or project management process.

Following hot on the heals of the Agile software development movement came automated testing, release management and cloud computing. Meanwhile Facebook gained a billion customers, Microsoft waned, Google waxed and mobile applications took client development in a whole new direction (or should I say directions ;)).

Then came DevOps. DevOps was founded by Patrick Debois and a small group of frustrated developers and system administrators. Their frustration was aimed at how difficult it was for development teams to work with operations teams in their organisations. The pace, culture and methods of both teams seemed to be completely at odds with each other and testing was stuck in the middle. Their idea and hashtag, #devops, captured the imagination of engineers, leaders, luminaries and journalists alike.

The growth of DevOps has had an interesting side effect. There has been an explosion of operations tools and products on the market. Prior to DevOps every time I joined a new organisation I’d have to build another configuration management system and more deployment tools and monitoring solutions. Now the problem I face is which solution to choose. There’s still some significant development work required to make all these tools work together but at least I don’t have to build them all as well.

Just as story tracking tools, burn-down charts and continuous build tools can assist teams doing Agile software development so too do configuration management systems, containers and monitoring tools assist with DevOps.

Successful online services aren’t built overnight. They aren’t the result of one heroic development push. They are built iteratively. They are tested constantly. They aren’t then deployed and forgotten. Their performance in the live environment is studied. Data is collected and analysed. The results of those tests and the data collected is then fed back into the development process and the service is iterated on. Sometimes new features are added. Sometimes performance is improved. Sometimes more data collection is enabled. But always the service lives and grows.

Do you think you can do this at pace if development, testing and operations sit in their own little silos communicating by tickets or email? Do you think bringing operations and testing in on a stand-up or two or inviting them to the odd planning session will make this happen?

The value DevOps brings to an organisation is in fostering collaboration between software development, testing and operations functions. That collaboration comes from cultural changes not just tools adoption. Not just a couple of meetings. Whether you forge that culture by creating multi-skilled teams, as I propose in my book Next Gen DevOps or whether you encourage collaboration with processes, goal-alignment or a matrix management (ugh) it’s the culture of collaboration that’s important.

The reality is that developing modern online services can’t be done by taking development, testing and operations in turns we do them together and succeed or apart and fail.

If you’ve enjoyed this post you might like to know that my new book Next Gen DevOps: Creating the DevOps Organisation, the indispensable guide to building and managing services in the 21st century will be available on Amazon very soon.