Enterprise Agile Transformation Starts with DevOps

Dev Ops

Increasingly, I am becoming convinced that introducing Agile concepts within an existing enterprise IT organizational structure should start with DevOps before moving to the broader IT Projects and functional areas.  There are too many cultural and incentive mechanisms within IT Projects and functions that drive the siloed, specialized roles that inevitably lead to waterfall style handoffs.  However, starting at the back of the IT value stream with Operations and progressing into DevOps and finally IT Projects and functions provides a less treacherous path to implement agility into a large enterprise environment.

Why is "Being Agile" so Hard?

There’s a big difference between Being Agile and Doing Agile.  Agile itself is a mindset and Being Agile means understanding that mindset and applying it across the entire system.  Doing Agile means you are following the ceremonies found in Scrum, XP or SAFe, but without applying them with an Agile mindset.  Being Agile is actually getting the benefits from the Agile mindset of frequent, small releases of business value leveraging self-managed, collaborative teams.  For most organizations, they tend to focus on the start of the IT Value steam which involves the projects intake process where new initiatives and systems are funded, scheduled, developed and deployed before moving into Operations.  However, this is probably the hardest part of the IT organization to start with and better results can occur by working backwards from Operations into the IT Projects and functions that support them.

It Starts with the Organization

Most organizational agile initiative start with applying agile techniques to IT Projects.  There are compelling reasons to start with projects as they bring dedicated funding and are seen as having the flexibility to define their work environment to support Agile practices.  Teams make quick inroads setting up a schedule of daily stand-ups and sprints.  Usually, organizations make a commitment to dedicated resources to the core project team which is an important enabler for Agile practice success.  However, even if you have a dedicated, stable team of 8 people they typically get classified into IT functional roles as Project Manager, BA, Arch, Dev, and Tester.  The minute this happens an implicit series of handoffs and bottlenecks emerge with work flowing sequentially from the BA to the Architect to the Developer to the Tester which inherently limits the ability to deliver a potentially shippable product at the end of a sprint.  Initially, the first sprints are able to deliver their commitments because the core functionality is limited to establishing enabling frameworks, but testers soon start to complain that they have nothing meaningful to test. 

After some more time, the novelty of daily stand-ups, sprint reviews and retrospectives starts to wane and organizational management responds with requests for weekly status updates and a renewed focus on areas that they can control like time reporting, budget variances and document generation.  The project team responds by trying to capture detailed requirements and architecture in advance of each sprint and testers shift to focus testing of sprint deliverables after the completion of a sprint.  Sprints start to staircase with a requirements and design sprint followed by a development sprint followed by a testing sprint.  Organizations then add an integration and user acceptance testing period after all sprints have been completed and before long the “agile” delivery project ends up looking like a traditional waterfall project but with sprints providing milestones on project progress.  This isn’t all bad though as this typically does increase delivery velocity for most organizations but all that is really happening is that organizations are optimizing resource efficiency and ignoring flow efficiency, basically they end up doing Waterfall faster.

But Organizational Incentive Models Make it Harder

To make matters worse organization incentive models are aligned to resource efficiency and not flow efficiency.  Instead of focusing on what business value has been delivered into production and accelerating the delivery of this value, each of the roles within the project team are evaluated on metrics specific to their resource specialization.  PMs are rewarded for conforming to budget/schedule, BAs are measured on the number of fully formed requirements have been created, testers are evaluated on manual test cases executed and the number of defects identified and how long they are open.  Layered on top of this are management measurements that focus on sign-offs and stage gate entrance and exit.  All of these incentive models begin to collide with one another in an Agile delivery environment until the overwhelming organizational gravitation pulls agile practices back into its standard operating practices.

So What’s the Answer?

So how can we move past this massive rock in the steam?  Much like a river must work its way around a large boulder that has fallen into its path, introducing agile techniques can work around this by focusing in a space that has more flexibility and pathways.  From what I have seen the most logical area is in the DevOps space.  Now I recognize that DevOps and Agile are essentially different sides of the same coin, however, the barriers to Agile implementation in the traditional project space are so large that it makes more sense to start in the Operations part of the organization.  There are some clear differences when working with Operations teams, the first is that they are typically funded as a function and not as a project.  This immediately alleviates the challenges projects face of working within the constraints on not just the iron triangle (budget, schedule and scope) but the cross-functional teams that encourage resource efficiency.  Most Operations functions already apply many effective Agile practices.  The majority are already familiar with working with prioritized backlogs in the form of their ticket queues and often ‘swarm’ on issues to push them through their queue and reduce Work in Progress.  As an added bonus, most of the work items in these ticket queues are small enough that they can be delivered quickly, often the same day or within a week because these are similarly sized you can quickly start introducing some Kanban techniques and baseline the Cycle time (the duration from work entering the queue to leaving it).  There’s also less of the role formality that is experienced in project delivery so team members have more willingness to perform different tasks and often are keenly interested in learning new skills and techniques outside of their area of expertise.    I also find these groups tend to inherently focus on how a backlog item adds value as they are so close to seeing the business impact of an issue or emergency request.  So that said, what are the areas that these groups can leverage more Agility to drive business value throughput?

Reducing Cycle Times and Moving Back to Projects

There are a lot of opportunities to drive Agile practices in the Operations space but they should focus on delivering business value faster.  If you’re not familiar with Gene Kim’s excellent Phoenix Project book, it’s a good place to get inspired on some aspirational goals.  Operations teams that emphasize Test Driven Development, OnDemand Deployments, Trunk Based Development, Dark Features, Ten Minute Builds will start making inroads on the “long tail” of deploying value into production where it can be realized.  Getting to Amazon’s production code deployment every second might seem like a distant star to most IT Operations teams, but it starts with driving automation and reducing cycle times for operations activities.  More importantly though it will start driving these principles back into the Projects side of the equation and really marry the DevOps relationship.  The key is to have the Operations team drive the definition of the behavior they want to support.  Waiting for IT projects to act as the catalyst will basically mean you’ll be waiting for a leopard to change its spots. If you’re an Agile coach you’ll make real progress starting in Ops and moving to DevOps before you can achieve meaningful enterprise Agile Transformation.

Related Tags:
Be the first to comment | Write Comment
Sign In to Post a Comment