Search for a command to run...
Since childhood, Thomas has prioritized and emphasized human service and has always had a genuine passion for technology. Thomas is adept at recognizing and personally investing in open source market-leading platforms. He uses his insight and genuine desire for service to help his customers with their most difficult continuous delivery problems.
No comments yet. Be the first to comment.
A Noir Software Supply Chain Story
My name is Thomas A. McGonagle. The most positive experience of my life was playing football for eight years. I was voted a first-team All-Star in high school and then went on to play in college at Bentley University, which is a Division II program a...
Prompt #1 I need an analogy for offensive and defensive security with respect to devops. I like the title DevSecOps and like Krav Maga analogies Prompt #2 You are a 15-year experienced DevOps professional who is writing a blog on the importance of si...
Colonel John Boyd was one of the best fighter pilots on the planet who risked his life every time he jumped into the cockpit. But thanks to his OODA loop strategy, high-velocity chases, death-defying rolls, and last-gasp pivots were no longer uncomfo...
Ari Libarikian is a senior partner of Leap, McKinsey's business-building capability. He explains that “the companies that have stayed at the top for decades are always regenerating. This is really a requirement to being successful today.” Serial busi...
This blog was originally published on March 14, 2016 on the CloudBees blog. here.
This is the fourth blog in the Field Notes from a DevOps Cultural Anthropologist series. This blog describes DevOps Dojos: what they are, where they come from and why they are important to a DevOps community. I have been in the continuous delivery and DevOps industry for nine years and have made a number of observations during that time. I have seen strategies succeed – and fail. My goal is to try to help you be one of the successes! I’d love to hear your comments and experiences with continuous delivery and DevOps.
I am the organizer of the Boston Jenkins Area Meetup Group . We have monthly meetups where we have speakers speak about various Jenkins topics and network with each other. Our meetups start at 7:00pm. But, before that we have a DevOps Dojo from 12:00pm - 6:45pm. The Dojo is a place for people to drop by and receive help with thorny DevOps and Jenkins issues. My co-organizer Dr. David Yates and I provide this service as a demonstration of the principle of S (Sharing) in CAMS (Culture, Automation, Monitoring and Sharing). We consider it to be our fiduciary responsibility to give back to the DevOps and Jenkins community, which has given us both so much.
A DevOps Dojo provides a place for practice and mentorship. Practice is the “repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it”[1] . A Dojo provides a safe environment to practice ones DevOps skills. Similarly it provides a place for mentorship, which “is a relationship in which a more experienced or more knowledgeable person helps guide a less experienced or less knowledgeable person”[2] . This combination of practice and mentorship is incredibly powerful. The combination of the two act as a learning accelerant. Much like a martial art, DevOps cannot be controllered without significant, dedicated practice and mentorship provides the guidance necessary to navigate the murky waters of DevOps.
After our first Boston Jenkins Area Meetup, I identified five people that would make great mentors. I asked them to act as leaders in the Boston Jenkins Meetup scene. They all agreed. Yet another example of the S (sharing) in CAMS in action. All are Jenkins power users, and their immediate reaction to step up to the plate and act as leaders within our community was very impressive. Who are the DevOps leaders in your organization? How do you identify them? They are the power users, who are kind and generous. How do you identify them? You talk to them. You get them talking and sharing. If they are willing to do so, then they are a good candidate for mentoring and leadership. If they don’t, or don’t demonstrate positive team-oriented qualities, then exclude them from mentoring and coach them to become mentors. I have said it before, but you have to be nice to work in DevOps. DevOps’ singular team focus requires it.
The original idea for holding DevOps Dojos comes from Target, the mega-retailer. Building capacity is one of the most important things Target does. Since they have relatively few DevOps subject matter experts to go around, they are finding that access to these experts is a constraint that makes it difficult for them to scale the learning process for new teams. To address this constraint, they stood up a learning “Dojo ”. Target saw Adam Jacob’s presentation on DevOps Kungfu and then came up with the idea for a place to practice DevOps through repetition and development of skills. Miriam-Webster’s dictionary defines a Dojo as “a school for training in various arts of self-defense (as judo or karate)”[3] . This is in keeping with Adam Jacob’s kung fu metaphor and charge for teams to create their own DevOps kung fu style.
“The Dojo is a dedicated space in which our subject matter experts take up residence for an extended time. This is the home base for automation engineers, advanced Scrum leaders, OpenStack engineers, Chef experts, Kafka engineers, etc. Project teams and product teams looking to leverage these experts to build their own expertise can colocate their teams within the Dojo to have easy access to these resources. This learning time could be for a few days, to a few weeks to a month or more. Providing access to this knowledge within a confined and dedicated area enables our automation engineers, DevOps practice leaders, and lead developers to move from team to team as needed to support their training and learning needs. We can support up to eight or nine teams at a time in the Dojo, which is a significant uplift from our existing reach of learning. Teams that “graduate” from the Dojo are expected to dedicate some resources back to the learning environment in future efforts, thus paying forward the investment to help grow the next group of individuals and teams.”[4]
This concept of paying it forward is an important one. The purpose of the Dojo should be to create new DevOps leaders. The mentors will be sharpening their leadership skills, and the mentees will be further developing themselves into DevOps practitioners who can teach and continue learning on their own. Doce ut discas , means “teach so that you yourself may learn.” This axiom is a truth. If you want to learn something, there is no better technique than teaching someone the subject. Similarly, my grandfather who was a history teacher at East Providence High School always said that the best teaching was the instruction he received in the United States Army Air Corps (he was an elite bombardier captain who flew 317 missions throughout WWII). He said, first you tell them what you are going to teach, then you teach it and then you test them on it. This is a teaching truth and should be leveraged in DevOps Dojos as part of the instructional process.
Teams that spend time in the Target Dojo are working on the full spectrum of skills, which is way more efficient than attending individual training classes. They build the automation of their infrastructure as they design their application using new application technologies. They are learning agile development practices and applying test-driven development methodologies as they strive for a continuous delivery model. The value in applying all of these concepts together is very powerful and we’ve seen great progress with the teams as they’ve gone through the Dojo. In most cases, the initial learning curve has been steep, but we’ve seen teams hit their stride within a couple weeks and start to see huge productivity gains. These teams have emerged from the experience with much stronger skills and with a new working model that allows them to be much more self-sufficient and productive
Thomas McGonagle Senior DevOps Consultant, Global Services CloudBees