Organizations that have built a positive DevOps culture have transformed as part of a continuous and ongoing journey. The members of the organization should have a noticeable difference in how they behave presently versus how they behaved in the past. If the ultimate goal is to change the way the entire organization functions and operates, that means two things: changing the way everyone in the organization thinks about how they work and changing the way people behave.
So you’ve made it out of fall camp, and you’re not named the starter? What do you do? You transfer to somewhere that could use a quarterback like you next year! But make sure to do it fast enough so that you’ll actually be able to take advantage of the arcane collegiate rules system. While coaches may not intentionally be making life difficult for players wanting to see the field at all costs, the window for transferring is only open until the 12 day of an academic calendar. I’m sure there have been reasons for this number, but essentially it’s an arbitrary date.
I have had the opportunity to present this topic any many conferences this year and feel it is a critical topic for teams trying to make progress in their DevOps journey. Please feel free to continue the discussion with me on twitter @tomcudd.
This talk continues to be one of my favorites to give and I just keep getting the chance to present it. I will continue to submit it because it’s just a fun one. The Slides have been uploaded to SlideShare and my notes are mostly included here.
Continue reading “Are You Really Using Kanban or Just Making a List of Issues?”
Thanks for everyone attending the Nebraska.Code() Conference. After the jump, check out a previous version of my slides and some notes on the topic I collected. I’ll likely be updating the slides a bit more soon, and will post when that happens on twitter.
For those hearing my talk on the topic or wanting a single place to get to each item in the Anti-Pattern list, here is a link to the original summary post and the individual posts for each anti-pattern I discussed:
Automation is the force multiplier that makes a DevOps effort so powerful. While it requires the technical skill and know-how to create frameworks for automating processes in an organization, an automation-first mindset is not easy to start out with. The rest of the DevOps anti-patterns are all about different modes of thinking and this one is no different.
All of the previous cultural pitfalls I discussed have been focused on systemic issues with organizations, teams, or groups of people. This is truly the one that requires individual effort to defeat. Even I have to be intentional about sharing what I know that would make others on my team have the same successes. This differs from the Tribal Knowledge Anti-pattern in that organizations create and force single threaded resources. This forces people to “stay in their lane” which creates hard boundaries in what people know how to work on. Information hoarding usually comes from an individual place of fear and insecurity.
In 2017, I took a very hard look at the issue we caused for Quality Assurance teams I worked with. By automating many Operations tasks, we did not speed up the whole development effort of the projects we worked on. The flow of work through an entire system is the only metric that matters to project leaders and clients, not that one particular piece is better. We had unintentionally created a new, bigger bottleneck by not supporting our QA team properly with what they needed to succeed.
“It is better to ask for forgiveness than permission.” A statement like that is pervasive in an organization that follows a decentralized command and control structure. As organizations become more complex, it is nearly impossible for any single person to fully capture detailed information in making decisions. Yet, many companies still try to run significant decision making authority through single threaded resources.