DevOps and Scaled Agile Need Each Other

This is the first in a series inspired by a recent conversation with a client at a large enterprise company regarding DevOps and Scaling Agile techniques. The client was remarking that for now, they were not going to pursue scaling their agile practices beyond a smattering of teams as instead they were choosing to pursue DevOps practices instead.

I was pretty stunned by this comment as I have never seen these 2 as a choice point. Instead, I firmly believe it is impossible to succeed at one in any meaningful way without the other.

Disclaimer: For ease of terminology I have chosen to use the vocabulary words of Scaled Agile Framework (www.scaledagileframework.com). Don’t read anything into that.

Develop on a Cadence…Deliver on Demand is !!@#@!# hard

Nearly every model for scaling Agile practices supports the practice that when working in a team of Agile teams, all teams should be on the exact same sprint cadence. And that delivering code to customer’s hands should be orthogonal to your sprint cadence. That is, instead of trying to line up the sprints so that there is one large move to production on the last day(s) of the last sprint, develop the capabilities to deliver smaller batches of verified changes to production in a near-frictionless manner at a market-driven cadence.

Whew. That is easy to say and really #@)(*&* HARD to do. Especially if you have to unravel legacy code and source code management practices that create a stew of tightly integrated deployment objects with every build.

A worthy goal, it will just take time to get there. And DevOps people can’t get there without the Scaled Agile people right by there side.

  1. There must be planning and Feature sizing consideration given to the effort and organizational friction required to release code to production.
  2. DevOps people will require a champion in the Business Owners in order to take on the most sacred cow of IT: Production Change Control processes.
  3. The build and deployment architecture of a solution must have first class status as a “component”. It’s a thing. It needs care, feeding, refactoring, staffing, code reviews, source code management and first class champions just like any other major solution component.
  4. When planning portfolios of work there must be Epics devoted to (and therefore prioritized and funded) for addressing the refactoring/rewrite/retooling of the build and deployment architecture.

Looking for more patterns on how DevOps and Scaled Agile fit together? Keep watching for future posts from me!