Start with a DevOps Transformation - You’ll Find Agile Along the Way

Enterprise Agile Transformations frequently fail to greet applause.

Organizations are spending millions of dollars on Agile Transformation. They’re hiring coaches, consultants, auditors, and evaluators. They’re sending project managers to trainings and getting scrum masters back. Devs are standing up and playing planning poker and sprinting and retrospecting. Two years down the road the C-Suite is looking at smooth burndown charts, 120% predictability rates, and a prioritized backlog long enough to last a whole year!

Success smells so sweet, right!?!? 

Of course, releases are still quarterly. Hotfixes are about as frequent. Feature requests get tacked on to the end of the backlog, and we can’t get to those bug reports because our 10% tech debt time is already dedicated to security findings! 

We get so excited measuring the methods that we forget to measure the outcomes. About 75% of companies say they adopted Agile primarily to accelerate software delivery. The transformation they really want is Continuous Delivery. 

Agile Software Development and Continuous Delivery

The clever reader (or the pedantic Agilist) will note at this point that “Continuous Delivery” comes directly from the first Agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. While true, Continuous Delivery has taken on a life of its own. “A couple of weeks to a couple of months” has turned into “a couple of minutes to a couple of hours.” The key is that releases are constrained by demand rather than capability. Most Agile transformations still aim for the original timeframe of the Manifesto, because that’s the best an Agile transformation on its own can hope for.

The full title of the Agile Manifesto is “Manifesto for Agile Software Development.” Software developers wrote it for other software developers about software development. Applying it as-is to enterprise teams certainly delivers some value, but just a tiny fraction of what most enterprises expect. Team agility doesn’t translate to organizational agility. For that, you’re looking at two options: adjust the principles to fit your enterprise, or adjust your enterprise to fit the principles.

Fit principles to enterprise, or fit enterprise to principles?

Scaling frameworks like SAFe are a popular way to implement the first method. They implement bureaucratic boundaries to give teams limited flexibility within the constraints of the existing org structure. Annual or quarterly planning and budgeting cycles, functional silos outside of dev, sales teams with strict contracts, heavy change management protocol… They’re all non-development challenges that limit developer agility. Scaling frameworks address them with additional roles, ceremonies, and process controls to predict and control that friction rather than changing the processes themselves. They place guardrails on where Agile happens, so they place boundaries on the benefits. That’s why most companies stick with the “few weeks to a few months” delivery timeframe. It’s all they can do.

DevOps is how enterprises apply the second method, and a definition is harder to nail down than Agile. It’s a combination of practices and culture that enable organizational agility across entire value streams. It all starts with systems thinking and mission orientation. You set your goal - “We’re going to release on demand” - and take the necessary steps to reach it. Some of that is Agile, but a lot of it is outside the scope of the Manifesto. 

Working towards the goal

Finding the right thing to change isn’t easy, but the Theory of Constraints helps. Identify the top constraint to your goal. Fix it. Rinse and repeat. Any resources not addressing the constraint are wasted. Spend a lot of time waiting on VP direction? Flatten your organization and empower teams. Waiting on infrastructure and security? Establish self-service capabilities so the teams can get themselves what they need. Long regression and hardening cycles? Automate your regression tests. Projects pending annual budget review? Fund teams, not projects, and trust them to identify the right work based on frequent feedback. Software development taking months for something useful? That’s your chance for an Agile Transformation! Keep finding the barriers to your goal and breaking them down, wherever they are in the business.

Agile is just a part of a means to an end. Don’t make it the focus of your transformation effort.

Logan Miles is a platform engineer with Buildit @ Wipro Digital. He's spent time in development, operations, and even an odd couple of years in sales engineering. A generalist through and through, he uses his knowledge of different areas of the software life cycle to help communicate across team boundaries. He has spoken about DevOps at meetups and in enterprise knowledge sharing environments with a focus on driving transformation. Logan's on LinkedIn, and Twitter.