DevOps is a mindset

DevOps, one of the current buzzwords in the industry. It is as important as Agility to the delivery of software and because it crosses traditional departmental boundaries, it is harder to achieve.

Similar to the way that Agile / Scrum practices broke down the barriers between Development and QA, DevOps, done properly, removes the barriers between Development and Operations. There is a natural tension between Development and Operations. On the Development side WE want agility and on the Operations side of the wall THEY want stability.
Right there, if you read carefully, is the challenge, we and them. With DevOps we can satisfy both sides because both sides gain an understanding and an appreciation of the other perspective and learn how to move forward in a safe stable manner so we don't negatively impact customers, but also in an agile and quick manner so that we can continuously provide value to our end users. As Donovan Brown, a Principle DevOps Manager with Microsoft, said "DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."

 From an organizational layout standpoint, there are a few ways to do DevOps correctly and many ways to do it incorrectly. DevOps Team Topologies gives a good overview of many of the options that exist, including many anti-patterns, or ways to make sure DevOps fails in your organization. I strongly believe that type 2 (Fully Shared Ops Responsibilty) is where we need to head, often type 1 (Dev and Ops Collaboration) is a step on that path. 

 One reason I believe so strongly that we must have Operations knowledge on Scrum Teams is similar to the reason we need all other capabilities on the team. Scrum teams must be Well Formed Teams, they must have the capabilities needed to develop and deliver the product. Related to this is the fact that DevOps is not a team, it is not a person or group of people any more than Agile is any of those. DevOps is a mindset. For an organization to succeed at DevOps the culture of the organization must embrace and reward DevOps behaviors. I cannot state this strongly enough, DevOps is not a person or group of people; DevOps is a mindset.

 There are many ways for an organization to include the DevOps mindset into their culture. Donovan Brown likes to say "rub a little DevOps on it and make it better" In most cases when we apply DevOps practices it is like a salve and we make things less painful. Examples include introducing an automated build, a CI/CD pipeline, or adding automated testing.

 As part of the DevOps journey we want to shift quality left. In the spectrum of Develop, Build, Test, Deploy and Monitor wherever possible we want to move defect detection to the left. The reason is that by moving to the left we find the defect closer to the source, which makes it less costly to correct the defect. It is better, and cheaper to find a bug in testing than it is in the field, having an end-user find it. It is similarly cheaper to find a bug during development than during testing. The reason for this is the extra costs that exist to the right. If the end user finds a bug, it has to be fixed, retested, redeployed, etc. not to mention the potential cost in public opinion about the product and company. This same logic can be applied similarly to any case of moving quality left. 


 As with anything Agile, we are looking to promote fast feedback loops. In this case, we want feedback about how the product is deployed and operates. Typically this is diagramed something like this.
By empowering the team to own the deployment and running of the product we make sure that they build a product that is deployable and monitorable. If not teams often do not think about those aspects because those concerns are outside of the team and often not a direct concern of the stakeholder.

DevOps is the next transformation that we as an Agile community must embrace. It is a challenging and fun journey and if you are focusing on continuously delivering value to your end-users then as Lou Bega said in Mambo Number 5 "And if it looks like this then you are doing it right"!

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more