Building a DevOps and Technical Practices Dojo
--
Tim Walker
The Agile Tester, LLC
--
Tim Walker
The Agile Tester, LLC
To be absolutely clear about something: “DevOps” is not a practice, role or technique. It is a culture and organizational alignment supporting the developers, IT, testing and the business to continuously deliver and sustain value to the customer. By having a team dedicated to outcomes and not activities, working together and agnostic to traditional organization functions, we start to approach DevOps.
Abstract
The Software Industry is changing in remarkable ways and at a pace that is almost impossible to comprehend. With the advent of practices such as cloud computing, on-demand virtualization, automatic scaling, self-healing systems, rich development technologies and and extreme DevOps approaches, development teams that are not mired in outdated approaches are gaining a competitive edge that will be very difficult to catch by legacy development teams.
We know the value of Agile methods. Studies, such as those published by David Rico in “The Business Value of Agile Software Methods”, shows that the ROI of Agile technical practices such as Test-First Development, Pair Programming, et al, deliver remarkable ROI and give organization a beacon to follow for effective change.
So, how do these legacy (“venerable”) teams catch-up with those teams that are delivering business value at rates that can only be described as scary? Enter DevOps and the DevOps Dojo, which might be better called “The Agile Accelerator”. Even as this is written new practices, such as Behavior and Domain Driven, User Story Mapping and more, are further accelerating the advantage forward learning teams are experiencing.
This brief describes, in a step-by-step fashion how to go about building a DevOps Dojo.
The DevOps Dojo
A dojo is a term from martial arts that means “Place of the Way”. It is where martial arts students progress by the use of training fundamental skills (“Kihon”) and practicing them through exercises and repetition (“Katas”).
A Dojo consists of the “place”, which is the dojo itself, the students and the instructors (“Senseis”). A sensei is a person who is extremely skilled in the discipline, usually a multiple degree “black belt”, who also shares a passion for the craft and for teaching others. In the above photograph you see the discipline taught instilled in the heart and mind of even very young students.
If you watch a martial arts dojo, even for the young children, you will immediate notice the culture being taught is as, or more, important than what is taught. Students learn to bow to the sensei and show respect, to work together and positively at all times. In the dojo or otherwise. This is very important in building a DevOps dojo in your environment so keep that at the center of your thinking and planning.
A DevOps Dojo consists of the same components.
Step 1: The Champion
A successful dojo will need a champion for the effort, supported by the people who know how to do it.
Step 2: The Kihons
The next step in building a DevOps dojo is to understand what “Kihons” are desired to develop in your teams. In the case of DevOps (which is more of a culture supported by these practices) the interest might be in Test Driven Infrastructure, Configuration as Code, Continuous Integration and Delivery and the XP inspired technical practices such as Test First, Pair Programming, Design Patterns and Refactoring.
Step 3: The Senseis
When we know, more or less, what the Dojo The next step in our Dojo journey would be to identify and engage those people who are skilled and who have the right attitudes to lead the journey. Unless we have this skill in-house, this usually means bringing in the skill by hiring experts in the industry or bringing in highly-skilled consultants to “seed” the Dojo.
We’d want to have a pair of senseis per Dojo instance, per team. This is to learn from each other, to exploit the skills between them and to accommodate any absences by one sensei that could disrupt the training.
In the case of specific needs we might need to bring in “special senseis” that have specific skills that are not otherwise present. One of the differences between a DevOps dojo and a Martial Arts Dojo is that the Martial Arts dojo usually consists of a “specific discipline” while a DevOps dojo could be any technology skill in the industry. Perhaps more analogous would be a “Mixed Martial Arts (MMA)” dojo.
Step 4: The Dojo
When we have a champion, know what we want to teach and have identified the senseis who will be leading the students we need to know where the Dojo will be located. In some cases it’s possible for the Dojo to “go to the teams” but we prefer to identify a special place showing “the way” and disrupting the cycles that have been engrained, possibly by years of situational katas and exploiting the “old ways”.
The size of this Dojo should accommodate the number of teams we want to train (a team is usually a small, cross-functional “Scrum” team of 5-9 students), and scaled by the pace that we want them to learn. For example, if we have 12 teams and we want to train them in 1 year, we’d need space to accommodate 1 team undergoing a 1 month Dojo which means we could get 12 teams per year through the Dojo.
The dojo will be a pleasant location, well lit and with plenty of whiteboards, space and other supplies that might be required.
The dojo will also need acces to the cloud or systems that can be leveraged to do the training such as AWS EC3 access.
Step 5: The Dojo Flow
When we’ve identified the people and place of the dojo we need to create a plan for the execution of it. Some questions we’ll need to answer:
When will it meet?
How will it work?
Who will be involved?
How long is the dojo?
How will we deal with follow-up and continual growth and technology advances?
Step 6: Build it and Improve
Finally, we need to find a team and get them in to the dojo so we can learn and improve. It is very common to do assessments of one form or another before the dojo and again after the dojo so that we can continually improve.
Summary
Building a DevOps dojo might be the difference between a legacy company staying in business and being overcome by teams who have “technology birthrights” and delivering outcomes to its customers at a rate and quality that has heretofore been impossible to even comprehend. Some customers are release software as often as every minutes, hundreds or times a day.
The Software Industry is changing in remarkable ways and at a pace that is almost impossible to comprehend. With the advent of practices such as cloud computing, on-demand virtualization, automatic scaling, self-healing systems, rich development technologies and and extreme DevOps approaches, development teams that are not mired in outdated approaches are gaining a competitive edge that will be very difficult to catch by legacy development teams.
We know the value of Agile methods. Studies, such as those published by David Rico in “The Business Value of Agile Software Methods”, shows that the ROI of Agile technical practices such as Test-First Development, Pair Programming, et al, deliver remarkable ROI and give organization a beacon to follow for effective change.
So, how do these legacy (“venerable”) teams catch-up with those teams that are delivering business value at rates that can only be described as scary? Enter DevOps and the DevOps Dojo, which might be better called “The Agile Accelerator”. Even as this is written new practices, such as Behavior and Domain Driven, User Story Mapping and more, are further accelerating the advantage forward learning teams are experiencing.
This brief describes, in a step-by-step fashion how to go about building a DevOps Dojo.
The DevOps Dojo
A dojo is a term from martial arts that means “Place of the Way”. It is where martial arts students progress by the use of training fundamental skills (“Kihon”) and practicing them through exercises and repetition (“Katas”).
A Dojo consists of the “place”, which is the dojo itself, the students and the instructors (“Senseis”). A sensei is a person who is extremely skilled in the discipline, usually a multiple degree “black belt”, who also shares a passion for the craft and for teaching others. In the above photograph you see the discipline taught instilled in the heart and mind of even very young students.
If you watch a martial arts dojo, even for the young children, you will immediate notice the culture being taught is as, or more, important than what is taught. Students learn to bow to the sensei and show respect, to work together and positively at all times. In the dojo or otherwise. This is very important in building a DevOps dojo in your environment so keep that at the center of your thinking and planning.
A DevOps Dojo consists of the same components.
Step 1: The Champion
A successful dojo will need a champion for the effort, supported by the people who know how to do it.
Step 2: The Kihons
The next step in building a DevOps dojo is to understand what “Kihons” are desired to develop in your teams. In the case of DevOps (which is more of a culture supported by these practices) the interest might be in Test Driven Infrastructure, Configuration as Code, Continuous Integration and Delivery and the XP inspired technical practices such as Test First, Pair Programming, Design Patterns and Refactoring.
Step 3: The Senseis
When we know, more or less, what the Dojo The next step in our Dojo journey would be to identify and engage those people who are skilled and who have the right attitudes to lead the journey. Unless we have this skill in-house, this usually means bringing in the skill by hiring experts in the industry or bringing in highly-skilled consultants to “seed” the Dojo.
We’d want to have a pair of senseis per Dojo instance, per team. This is to learn from each other, to exploit the skills between them and to accommodate any absences by one sensei that could disrupt the training.
In the case of specific needs we might need to bring in “special senseis” that have specific skills that are not otherwise present. One of the differences between a DevOps dojo and a Martial Arts Dojo is that the Martial Arts dojo usually consists of a “specific discipline” while a DevOps dojo could be any technology skill in the industry. Perhaps more analogous would be a “Mixed Martial Arts (MMA)” dojo.
Step 4: The Dojo
When we have a champion, know what we want to teach and have identified the senseis who will be leading the students we need to know where the Dojo will be located. In some cases it’s possible for the Dojo to “go to the teams” but we prefer to identify a special place showing “the way” and disrupting the cycles that have been engrained, possibly by years of situational katas and exploiting the “old ways”.
The size of this Dojo should accommodate the number of teams we want to train (a team is usually a small, cross-functional “Scrum” team of 5-9 students), and scaled by the pace that we want them to learn. For example, if we have 12 teams and we want to train them in 1 year, we’d need space to accommodate 1 team undergoing a 1 month Dojo which means we could get 12 teams per year through the Dojo.
The dojo will be a pleasant location, well lit and with plenty of whiteboards, space and other supplies that might be required.
The dojo will also need acces to the cloud or systems that can be leveraged to do the training such as AWS EC3 access.
Step 5: The Dojo Flow
When we’ve identified the people and place of the dojo we need to create a plan for the execution of it. Some questions we’ll need to answer:
When will it meet?
How will it work?
Who will be involved?
How long is the dojo?
How will we deal with follow-up and continual growth and technology advances?
Step 6: Build it and Improve
Finally, we need to find a team and get them in to the dojo so we can learn and improve. It is very common to do assessments of one form or another before the dojo and again after the dojo so that we can continually improve.
Summary
Building a DevOps dojo might be the difference between a legacy company staying in business and being overcome by teams who have “technology birthrights” and delivering outcomes to its customers at a rate and quality that has heretofore been impossible to even comprehend. Some customers are release software as often as every minutes, hundreds or times a day.
© The Agile Tester, April 20, 2017
RSS Feed