Let’s be honest when you think operations you probably do not think “Agile.” In fact, about five years ago, I would have agreed with you. Back then, I believed that working in operations meant “keeping the lights on” and solving urgent issues and escalations. Whereas Agile meant burndown charts, sprints, and retrospectives. They were completely incompatible. Apples and oranges. Until I realized that the two are not just compatible, but that agility is, in fact, the best way to solve urgent issues and escalations and to “keep the lights on.”
CollabNet VersionOne (Gartner’s recognized leader in Agile Management) said in their State of Agile report they document a 55% increase in productivity, 49% better business and IT alignment, and a 64% improvement on managing changing priorities (a constant bane of operations). The reality is Agile is no longer the exclusive turf of software development but in fact many different disciplines. Operations, marketing, even HR are recognizing that agility can help them achieve their goals faster and with higher quality.
Agile is a mindset, not a methodology
One of the biggest misnomers out there is that Agile is a methodology. It’s not. Agile is a mindset, which often manifests itself in a methodology (most typically Scrum or Kanban). Resist dogma. Look to the very name of the mindset and be able to move quickly to what works. You must BE Agile, not DO Agile.
Ok, so yes. You will need some kind of methodology. Scrum? Kanban? Scrumban?
It’s been my experience that Kanban tends to fit Operations groups better than Scrum, but that may not be the case for your organization/situation. The reality is whatever you choose to label your new process, it will be its own animal. Do NOT be dogmatic. For example, check out the Agile Manifesto. There’s no dogma there. It’s about values and principles. So don’t spend too much time worrying about the footwork of what you roll out especially when you first launch.
How to approach a transformation
The only absolute requirement for attempting an Agile transformation of an operations team is buy-in from your executives. A change of this magnitude will likely bring bumps in the road and changes in the way you want to measure success. To make this work, you need to ensure that the C-suite understands, is invested, and is engaged in this transformation.
Understand that this is a long play. This isn’t some panacea you can roll out, and it will solve all your problems. The reality is you will need to make small adjustments to your overall process continually. To enable this, you will need to instill a culture of continuous improvement.
Early on in my transformation days, I fell into the assumption trap that everyone else believed in continuous improvement. I realized not all do and I needed to set a paradigm that - while the team IS good- there is always room to improve. For that reason, we will relentlessly look for ways to improve how we operate. Also recognize you will have resistors, some relentless in their own right. Be a curious listener to their concerns, and bend - contort even - to make your transformation successful. This means all of your stakeholders need to feel like they own a little piece of this change.
When you first launch
Regardless of what your chosen methodology is, focus on visualizing your work and establishing cadence. Two weeks to a month is typical. To visualize your work, find a shared online system. It could be JIRA, Sharepoint, Smartsheet, or Rally, for example. Which tool you choose isn’t terribly important, but it needs to be shared. You can even start with just a whiteboard/Post-it notes that you photograph daily. Whatever you choose, use it as a way to get things started.
It’s been my experience that putting too much time into estimation early on is a mistake. It can lead to analysis-paralysis and it will be difficult to begin. Start by defining your smallest unit of work then comparing other work to the smallest unit. You can use hours of effort or T-shirt sizes.
How to manage interruptions
Let’s acknowledge the elephant in the room. If you’re on an operational team, you likely deal with interruptions, maybe near constant ones. Two ways you can mitigate these are to include them in your capacity planning, assume there will be interruptions, take an educated guess as to how much time you spend on planned work vs. unplanned work (30% planned work? 50%?), and accept planned work accordingly. Also, as the unplanned work comes in, make sure to track that work on your chosen online system. This is still work, so you’ll want to track and take credit for it.
An out of the box game plan
At this point, you may be excited about putting this into motion but are wondering how. Here’s a game plan distilled from the points above into actionable steps. This plan has worked for me, but I want to emphasize that not all of this may work for you. With that said, here we go:
-
Think of how you want the team to operate and document it.
Things like: we want to try a Kanban methodology; we will use JIRA as our chosen tool; etc. Document how you will use analytics to find issues and define your cadence (the team will have monthly iteration planning in which we will, as a team, size work, decide how will we pull work in, etc.) Put all of this into a slide deck. The start of the slide deck should be about why to change and include research (there is a lot on the internet) to document the productivity increase with Agile.
-
Work with your manager to refine the slide deck for executive approval (C-level if possible).
(This assumes your immediate manager is on board with an Agile transformation). Then present slides to executives with a proposal to transform. Ask for some Agile training, even as simple as online courses, for the whole team.
-
Plan your implementation with the team.
For your team, no matter how you do this, it will feel like a dramatic change. Right out of the gate implement just the bare minimums – your chosen methodology and cadence, planning and retrospectives, and stand-ups. Plan to make changes to the team requests, as you need their buy-in.
-
After you launch, wait, measure, and refine.
Give your team a few iterations to work under the initial rollout, then begin to look at the output and find where problems lie. Are there constraints to the process? Are there players who presented challenges? Once you have your target areas for improvements, plan an “experiment” to address what you see as the problems.
Think about how you’ll measure the outcome of this experiment. What would define success or failure? Initially, I recommend no more than two experiments per year (I like to do them in spring and fall, as many take time off during the summer and over the holidays). As you progress, you can make smaller experiments more often and speed up your learning cycles.
-
Include the team in experimentation planning.
I see this as the final step. By now, most of your team believes in the process. They now can be your best source of ideas to improve, which will empower the team and further cement buy-in. A hallmark of successful healthy Agile teams is self-direction. To enable them, you need to guide them. Don’t prescribe to them; collaborate with them.
Throughout the process, be positive and celebrate wins AND losses. Teams need to understand that failed experiments with learning and adaptation is still a winning outcome. This is crucial to growing and maintaining the culture which supports Agile teams.
Agile transformations are a journey. I’m still in Step Five and am learning that you’ll keep refining and improve. As you progress through the steps above, the team will be more open to changes, especially when you can demonstrate your successes. Have an open mind and enjoy the ride!
Christian Ollenborger is a Sr. Project Manager for the Information Technology organization at Carbon Black.