Waterfall, Agile and DevOps - The misconception

I have recently read an article from Jasmine Scot, titled The Transition to DevOps. Although the article do make a few solid points, there are also a few shortcomings with it. This article highlights the misconceptions and misunderstandings there exist when it comes to agile development practices, or methodologies and DevOps.

There are many mistakes in the both the article and also the graphic. For the graphic, everything is waterfall as you only have one 'design' phase. Then the understanding of DevOps is also a bit warped. DevOps is not a methodology, or even a branch of one specific methodology, as is illustrated in the graphic or alluded to in text - it's a culture.

The more successful DevOps organizations are better at implementing 'Agile' methodologies. Where I use the word agile very loosely here! You can implement Scrum, Agile or Lean - it doesn't matter, but that doesn't mean you are a DevOps organization. However, to be successful with DevOps, you would need to be agile in the way you develop software and deliver that into your production environments. Being successful at DevOps means that you are feeding back analytical information about your product back into your development and infrastructure teams and being able react to that fast and effectively. Being successful at DevOps means that you are agile in provisioning of infrastructure required in various environments and provide these in a very agile manner without delaying the flow between environments. There are many other aspects that can lead to you being more successful in establishing that DevOps culture.

In my opinion a company should not strive to be the perfect model when it comes to DevOps. There shouldn't be goals to achieve a certain benchmark with regards to DevOps. Any company should always focus on their agility and leanness in process, in their ability to learn and adapt as they progress. In doing that they will automatically improve and enhance the way DevOps is being done within the organization. Being an agile, lean and learning organization should be goal.

Any organization should be agile in the way they approach a project. Be lean about it. Cut out the fat and build the muscle - be lean. As you iterate along, learn from what you have already did. Constantly review what you are doing and adapt what you are doing to allow for improvements. If the change you made is not working, don't be afraid to acknowledge it and move on from it. That is what will make you agile and lean. If it works, keep doing it but still reflect on ways to make it even better - be agile and lean about it.

Technology companies are drivers of change in the everyday society. Yet they are scared to change themselves. If you don't change something, you won't learn something. A learning organization is the organization that change, learn from the change and change again.

Collaboration between squads and departments is a huge driving force in being agile and lean. Team organization should ideally be cross functional. The business analyst needs to be very closely involved with what the developers are doing to allow them to react quickly on issues identified during development and or testing/validation of a specific piece of work. Having the BA part of the squad and not in a separate squad allows easy collaboration and increases trust. Other functions like quality assurance/testing, build and delivery should also be included in a specific cross functional squad. This will cut down on waiting times once a product has been developed and improve the leniency and agility of the squad to react and deliver. 

The first step any organization should take in becoming better agile and working towards DevOps cultures needs to be to implement a form of analytics framework that would give them insight in what actually happens to a product once the product has been deployed into a production environment. When something goes wrong, you need to be able to react quickly and accurately to minimize the impact on your customer. It is not always feasible to break this function down and integrate this into the smaller cross functional squads, but having good collaboration within you organization would allow you to feed this information reliably and accurately to a cross functional squad. In some cases, it is possible to make this cross functional squad the owner and driver of some of this analytical information. This information should however also be a driving factor in decision making for the product design. How is the product being used? Do people use what we do, if they don't why do we support it - be lean and agile.

The same counts for infrastructure and operational resources. It doesn't always make sense to tightly integrate the resources into cross functional feature squads, but make them easily assessable. Establish good collaborative channels and be open about planning and timelines for infrastructure projects. Try and allow operational resources to sit alongside the cross functional feature squads a few days in a week and rotate them. This will allow the developer or the build engineer to always be a few yards away from the infrastructure engineer, but can also allow that same infrastructure engineer to still be part of his infrastructure squad and keep the clock ticking in their own squad.

In closing, I do however feel that this article is a great starting point for discussion on transitioning to a DevOps culture and what you would need to transform you organization from a normal dev-shop into a DevOps focused environment.