So. Full disclosure: I’m a speaker in the DevOps track giving a talk for DevOps n00bs and curious but shy people who want to learn more. You can imagine how, coming from this starting point, my reaching out to Jez Humble about his continuous delivery (CD) keynote was a bit of a daunting experience. Not one to let fear stop me from going after real value, I sent Jez some questions that probably everyone new to DevOps wants to ask, and no doubt he’s answered them many times. LOL
What advice do you have for people looking to make the switch? How do you help a team to start?
I think that devops and continuous delivery are all about continuous improvement. The key piece is cultural: how do we help teams work together effectively to problem-solve in pursuit of common organizational goals? That requires teams knowing what the organizational goals are in measurable terms, and being given the support and resources to problem solve in pursuit of those goals. In contrast, most organizations treat teams as order-taking functions whose effectiveness is measured in terms of how fast they can get their assigned work completed. So that’s a big change that requires significant changes in the way everyone works, but particularly how leadership and management operate.
I’ve made the whole thing sounds practically impossible, sorry about that. There are things that you can do to get started, particularly if your team has a manager that is philosophically aligned with this vision. Identify the biggest constraint in the organization that you have the authority to do something about. Set yourself a measurable goal 1-3 months out (something like, “zero-downtime deployments,” or “get regression testing down to 1h,” or “enable developers to run the application in a sandbox on their laptop with a single command.”) Then go get it done! If you actually made an impact, the people you helped out should be telling everyone else how awesome you are. Choose a new goal. Repeat. The next challenge is helping other teams adopt this approach, which it turns out is the next question! Go Claire!
How do you help the shift to DevOps to be durable and self-sustaining?
This is where effective leadership and management are essential. You can guerrilla devops as much as you like, and learn and have fun doing so. But if the stuff you can actually address is not in fact the most important constraint or challenge the organization faces, your impact is going to be limited. Teams have to be collaborating to address these challenges, not competing to achieve the highest velocity so they can get their story points.
In my experience there are three common obstacles, which are really all byproducts of the order-taking mentality I mentioned. First is not having the resources to work on improvement: “We’d love to be able to spend some time on automation / refactoring / improving our toolchain but we need to get these stories done.” Well, the reason you’re so resource constrained is that your processes are so inefficient. If you never create capacity to address these issues, you’re going to be in a vicious cycle.
Second, leadership communicates what has to be done in the form of a backlog of tasks rather than measurable, prioritized organizational goals. In any situation where innovation is required to succeed, you’re not going to discover the best solution up front. Teams are going to be discovering as they implement. That’s in many ways the essence of agile. I really like impact mapping combined with hypothesis-driven development as a way of thinking about this, but it’s not much use if your management doesn’t operate in this way.
Third is that often the people doing the work are resistant to new ways of working. Lots of developers would rather work on long-lived feature branches than off a shared trunk / master. Lots of testers see test automation as an existential threat. The common thread here is that people have their success measured by how fast they can complete their assigned work with their existing skills rather than how effectively they can learn and collaborate in pursuit of organizational goals – and again, that’s fundamentally a management and leadership challenge.
These are all deep problems and I don’t pretend I have a silver bullet to address them. Nor does anyone else: Most of the “big agile” implementations I’ve seen on the ground fail to tackle these issues because they’re hard – I gave a talk where I discuss this problem, and my book Lean Enterprise is all about these issues. In most big organizations you’ll find pockets that are very forward thinking and pockets that are very backwards, and it mainly depends on who’s in charge at any given point.
How do you keep driving continual improvement when you think you’re done?
I’ve been studying high performing organizations for some time now. The one common factor is that they are always trying to get better at what they do. They make continuous improvement habitual: part of everyone’s daily work. Again, this requires that the organizational goals are clearly stated in measurable terms and prioritized (OKRs are good for this if done in a collaborative rather than a command-and-control way). This is what ensures people are collaborating on what’s important rather than their pet projects. My favourite framework for thinking about this is Mike Rother’s Improvement Kata which includes lots of free materials to get started. His book, Toyota Kata, is excellent too. I also think that everybody should listen to This American Life’s episode on NUMMI and then read John Shook’s article on changing culture based on his work at NUMMI.
Digging into Jez’s written work, I was a bit nervous. Would there be room for me, a person with deep experience in manual testing, in this shiny new world of DevOps and continuous delivery? I was happy to find the answer is a resounding yes! Exploratory testing is an activity and a skill that continues to be valuable, even in the face of so much automation. Indeed, as the continuous delivery site states, “People are freed up from mindless drudge-work to focus on higher value activities. This also has the benefit of improving quality, since humans are at their most error-prone when performing mindless tasks.”
Transitioning focus to higher value activities isn’t easy. One of the barriers I’m most familiar with from my years in the software field is, “X won’t/can’t work in this context.” In fact, there’s a name for this phenomenon: not invented here. Jez’s abstract explains claiming to be doing CD is commonplace, which I’ve heard called “aspirational language.” So how do we go from merely wishing it were so to actually having this as our reality? What struggles do people face when seeking to fully embracing the necessary behavior to make CD work for them?
I can’t wait to hear more from Jez at Agile2017, and (even better!) my talk will be over by then so I can give his keynote my full attention!
