How effective is your “Agile” if your Operations/IT team isn’t participating?
Working with a new team, I asked their Product Owner to share how work flowed from the customer, through to the team, and back to the customer for rapid feedback. There was a whiteboard session we had where she referenced lots of teams (and when I misunderstood probably for the third time) she looked at me and said “I’m the Product Owner on the Scrum team. After we finish, our work goes to the DevOps team to prioritize for release.”In short, they had rolled out “Agile” by a 2-day training, and subsequently renamed Managers to Product Owners and Project Managers to Scrum Masters. And forgot about IT Operations - the team needed to help them release the software to the end users. Then they wondered why they could not get a potentially shippable nugget in front of a customer for feedback. The reality was that one team’s “definition of done” was the IT Operation team’s definition of “start”.More about them later, what they seemed to grasp was that they wanted to make changes faster, with more safety, and so in the conversations that followed we talked about this word “DevOps.”
Where I learned about DevOps
When I first heard the term “DevOps” it was the result of a session at a conference called “Velocityconf” in San Jose, California in 2009.1 At this conference, John Allspaw and Paul Hammond wowed the crowd talking about how they were able to do 10+ software deploys per day, which was unheard of at the time. Their session was all about creating a culture so that instead of prohibiting change, development and operations can work together “without being assholes to each other.” They begin their presentation with a fork in the road: “you can discourage change in the interest of stability, or you can be smart and build tools and culture to allow change to happen as often as it needs to.” 2
What is DevOps?
Unlike “Agile” which has a heritage of software development, with values, principles and now several practices and frameworks, DevOps comes from a nexus of software development and IT operations, and does not have a well documented set of values, and principles.
However it really is a movement. DevOps success is truly full organizational alignment around goals, values, and cadence of releasing quality software to users."3
How effective is your “Agile” if your Operations/IT team isn’t participating?
Back in conversation with the Product Owner, her goal was indeed delighting her customer, so we talked over a diagram looking something like this.
I asked her “How might things be different if you were the Product Owner for the full lifecycle of the product, rather than the Product Owner for just a hand-off for development and testing?” At the end of our discussion, she said “So what this really means is that to remotely have an inkling of a chance to be able to delight my customers, to be able to adopt, maintain, support, automate and scale the software released, the verification and validation (V&V) folks on my team, the folks doing the IT/Operations, the developers on my team, and the business all need to be in sync on what the goals are, what the release schedule is, and have a desire to work together.”Yes, I think that’s a great start.
But how do we begin to work together?
This is going to sound trite, but I suggested she begin with forming a relationship where there was none before. I suggested that she take the extended team out to lunch, explain the predicament, share what she now could share about the DevOps movement (perhaps even the John Allspaw and Paul Hammond presentation itself), and get their take on what they think their business goals are (today), and where they want to be in two months time. After they have met, including a good synch on what their individual and collective business goals are, I suggested a second step of trying to understand the flow of their work. If they want to improve their performance as a collective team, we suggested they do some mapping highlighting where their work items are coming from, who should be involved for sequencing, and what “done” might look like. Even if we begin in silos where the Scrum team’s “definition of done” is the IT Operation team’s definition of “start”, we can at least, minimally, begin to understand queue management and improve flow over time.
Does Agile conflict with DevOps?
Here’s a mantra for you to try out: Every git merge event represents a potentially shippable product increment. Why should we not be able to do this well if one of our Agile principles is “Our highest priority is to satisfy the customer with early and continuous delivery of valuable software?”
Where did you start?
If you were in a similar predicament where development, IT operations, and the business were not working together, how did you begin to bring the hearts, minds of these teams together for a full organizational alignment around goals, values, and cadence of releasing quality software to users?
Footnotes
1Velocityconf 2009, youtube Video. Presentation by John Allspaw and Paul Hammond.
2Re: DevOps History: While the Velocity conference might be where I first heard the term DevOps, Andrew Clay Shafer and Patrick Debois discussed "Agile Infrastructure" at an Agile2008 conference – and in Ghent, Belgium Patrick Debois continued on organizing DevOpsDays conferences which are alive, well, and now global today. For a giggle, check the original link for how they advertised the first session.
