Agile Devops

October 5, 2020

If you work in development there is a good chance you have heard about Agile, there is a good chance you do not know what it is. Agile is a framework and methodology that emphasis short iterative planning and development cycles. Agile is the predecessor for DevOps and Scrum is a subset of Agile.

Starting with Agile why do you even want to use it or why is it important. The primary reason is the name itself. Your goal is to be more agile with the development process. The emphasis on short iterative planning and development cycles encourages testing sooner with incremental updates. This allows you to identify issues sooner and get them fixed sooner. The sooner you identify an issue the less likely it becomes more embed and can be fixed, which saves money. The short iterative also encourages evaluating where you are and where you need to go.

This goes well with DevOps and the concept of everything as Code. There is a concept of Agile DevOps. Agile is focused on getting smaller teams to collaborate, and DevOps is about bringing together two large siloed teams. The goal of combining Development (Dev) and IT Operations (Ops) is so they can share knowledge and responsibility, about 30%. That allows each team to do what they do best, but also help the other team with the overlap. The Ops part of DevOps might not be as used to having to script everything out and write code, which having the Dev as part of the team really can help. The Dev part is not going to be as familiar with what and why to be deploying certain infrastructure, that the Dev team should now be responsible for. In a true DevOps focus, the goal is to be releasing new releases potentially several times per day, Agile uses sprints. To learn more about DevOps this is a great reference, DevOps Reference.

One of the popular quotes around this from back in 2013 by Jeff Bezos, Amazon Founder, where he credits the success of his company s innovation to his "two pizza rule". Teams should be small enough that the entire team can fit in one conference room and be fed with two pizzas. You might be asking why? Since this means you will probably have more teams. There is some science going on here, that actually dates back to the mid-1900s. With the smaller team sizes, you can help to ensure that the entire team can contribute to the ideas, which is important to ensuring that everyone can be heard. The science also enforces that the number of performance problems a team encounters increases exponentially as the team size increases. Then general rules I have seen are seven plus/minus 2 or six plus/minus 3. The general rule I have seen on the min side is 5, there are exceptions like the US Navy Seals which found that 4 highly skilled members are the perfect team. Then the max tends to be the nine.

The issue with small teams is now you have to divide the work between multiple teams that now have to work together. In a monolithic system, this can be a problem and people can be overlapping, and strong communication is the key. This could be a reason to consider switching to microservices and "The Twelve-Factor App", The Twelve-Factor App Reference. The main goal of this is the monolithic system is broken into smaller easier to manage subsystems that are independent of the others. This works really well in the cloud in that everyone is using the resources and development that makes sense to the project. The could of things I would say to ensure you are thinking about is security first and zero trust. That should be the start regardless but it still needs to be mentioned.

If you work in development there is a good chance you have heard about Agile, there is a good chance you do not know what it is. Agile is a framework and methodology that emphasis short iterative planning and development cycles. Agile is the predecessor for DevOps and Scrum is a subset of Agile.