Guaranteeing Failure for Your Agile & DevOps Transformation: A Step-by-Step Guide

A version of this article originally appeared in CM Crossroads

Almost weekly, I meet with IT leaders at Fortune 500 companies and discuss where they are in their software delivery transformations.  My first experience doing this was 9 years ago with Nokia, one of the largest Scrum transformations at the time.  A Nokia executive who had successfully scaled lean delivery methods to nearly a thousand engineers communicated to me his concerns to scaling Agile to all of Nokia.  The problems he highlighted foreshadowed key aspects of the company’s downfall.  Since then, on the long flights back to Vancouver I work through the patterns and anti-patterns that I see at the organizations that I visit.  Below is a pretty picture from my last flight, on which I wrote the post, while thinking it was ironic that the delivery date of the Dreamliner slipped by months due to one of these anti-patterns.  I’ll leave it to you to guess which one, and hope that you find the rest of the post either absurdly amusing, or disconcerting enough to kick off some serious discussions with your team.   

What I find most mind-boggling is witnessing the same organization making the same Agile & DevOps scaling mistakes year after year.  They then attempt to rectify them by putting together a great new tool and transformation strategy, only to miss the reasons that caused the previous transformation to fail to deliver business results.  I then find myself visiting the same building, typically one or two years later, usually speaking to a different executive. This past trip, it was the third attempt for this particular Fortune 100 company, and the last two VPs responsible for the transformation had already been let go.

As I was sitting in this meeting, I took some additional notes of what has been going wrong to get this company’s Agile and DevOps initiatives into such a bad state.  Their multi-billion IT budget has the very noble mission of defining the company as a software-centric business.  Yet during the meeting, I got a very vivid image of at least $1B wasted already, and the multiple billions more that they are about to figuratively set fire to if they don’t learn from the past.  For anyone like me, whose ethos revolves around progress and productivity, I found that the investor, consumer and overall economic value being destroyed here nothing short of atrocious. Thankfully most large organizations are already seeing the light and steering away from this state.  But just in case you’re interested in burning piles of your organization’s cash on Agile and DevOps transformation efforts that deliver zero business value, here’s my quick collection of anti-patterns to follow:

Anti-pattern 1: Push all tools top down, limiting choice as much as possible

Things were easier for IT many years ago when Rational provided the end-to-end toolchain.  As Agile displaced RUP, ClearQuest and ClearCase, things became a lot messier. You should do everything that you can to get things back to the very neat way they were before, while paying some lip service to the stated need to bring a specialized tool or two on board.  But be sure to select only one, and avoid feedback from the people using the tools as much as possible.  If the Microsoft/.NET side of the house is not happy using JIRA, that’s their problem.  If you’ve got Microsoft VSO/TFS then the Java folks better be happy using that instead of JIRA.  As for all those new testing tools and other special purpose tools, especially open source ones, those are just a fashion industry driven by software geeks needing to have something to talk about at conferences. Just ignore them and have people use the trusted tools that were proven to work in the past; they worked before, so they must be good enough to get the job done today. 

Anti-pattern 2: Worry about integration later, your internal IT team can handle it

Since you’re living in the past and trying to push everyone back to the equivalent of a single vendor stack, definitely do not worry about integration at the outset.  Integration can’t be that hard, after all the tool vendors say they provide seamless integration with their competitors’ tools.  Why wouldn’t they?  And your IT people say they can integrate any two tools given an API and an ESB, of which you have three, so you’re good. And you’re pretty sure that your experiences with doing integrations in-house causing the last few tool deployments to fail won’t repeat themselves. After all, tools now have REST APIs and WebHooks, so integration must be 2x easier than it was in the world of API proliferation and Microservices. And APIs these days must be fully documented and cannot be changing as much as they used to.  Also, there are some cheap Agile/DevOps integration solutions out there that ought to be enterprise-grade and support your scale and level of business-specific tool customizations.  You can also be certain that each of the teams setting up the field and workflow schemas of the tools will ensure that they align to match your Agile/DevOps flow goals, since their failing to do so would make integration across tools impossible regardless of APIs, so surely they know better.  Even if what the senior architect is telling you is correct, that the integration layer is more complex than the Agile tool itself and requires either investment or your most senior developers, you’re pretty sure that your IT team could implement an Agile tool in short order, so things should get back on track once you get that Agile tool deployed.  

Anti-pattern 3: Optimize your tool chain one silo at a time, the end-to-end flow will follow

Dealing with all these tools is onerous, so you’re best off focusing one tool and practitioner silo at a time. Focusing on your DevOps automation and CI layer will ensure that it gets it done, and there can’t be that much interaction between Agile Planning and DevOps anyway.  Or maybe just focus on the Agile parts, so that you succeed at leadership’s request for an Agile tool deployment, and worry about line of business partners’ requirements, quality, and operations later, once you’re done creating a nicely insulated Agile tool silo.  This divide-and-conquer approach worked well for some problems that you’ve solved in the past, and dealing with the end-to-end tool chain to figure out where the delivery bottlenecks actually exist, seems like it would be a lot of effort.  Best to wait until the investment in Agile or DevOps is done, even if you discover that the bottleneck may be with requirements or elsewhere.  At least the one tool deployment will be deemed a success, and it will take ages for anyone to notice that no more business value is getting delivered into operations than prior to the transformation. 

Anti-pattern 4: Forget about requirements and quality management, they’re old school

It’s been great having everyone at the organization line up around the new transformation initiative, so you really should let go of the old concepts of requirements and quality management as you focus on your local Agile/DevOps optimization.  The scaled Agile approaches like SAFe do seem to talk a lot about requirements, and the QA people are screaming more and more that the transformation is missing the controls that allowed your organization to deliver reliable software at scale in the first place.  But it’s not how they do it at Netflix, so let’s not worry about that.  Yes Netflix has under 4,000 employees total and you have more IT staff than that, but they clearly what they’re doing must correspond directly to your IT challenges.  And there must be some other way for business partners across your multiple lines of business to communicate with developers, such as being co-located in their cubicles.  So forget about those old school currencies of requirements and defects that connect software delivery to the business, instead you can worry about integrating those in Phase 3 of your transformation.

Anti-pattern 5: Ignore Ops and ITIL, they ought to be out of scope

There is no way that you can take on a tool chain modernization and care about the needs of everyone involved in the software value stream.  The Ops folks have always been difficult and resistant to change, and giving them access to all known issues with any release, rather than having them do their job in discovering those themselves, is sure to be disruptive.  And automating the connection between defects found by the support team and the Agile backlogs that developers are working on is sure to give the developers too much visiblity into what’s happening when their software is running in production, resulting in a lot of emails and even more tool integration requests.  So best let sleeping dogs lie and worry about integrating the flow of information between Development and Operations in Phase 4. 

Anti-pattern 6: Put someone junior in charge of integrating the value stream

You’ve got enough on your hands with managing tools and vendors for each discipline. The last thing that you need is someone to cause more problems by pointing out that your end-to-end software delivery value stream has no hope of being integrated by taking an in-house approach.  It’s a little concerning that she pointed out that by definition this means that this big transformation will fail to deliver business value. But you’re already quite far down the road of having your first success in deploying the new Agile tool, so do not put someone in charge who will realize that you have a flawed integration strategy before this first phase is done.  Surely the business will see that the deployment of tool itself is a success, and that will be merit alone for the business to invest further in the IT team’s ability to transform software delivery practice. You will finally stop the lines of business taking on rogue software delivery projects just so they can get business critical apps out the door as surely it was just that one tool they complained about the most that they need to be effective, not an integrated flow from design to deployment. 

Anti-pattern 7: Don’t bother with metrics, they will shine light on the wrong things

The very last thing that you want to do is to consider how you will measure the success transformation.  Any kind of metrics are a slippery slope.  Your boss has asked for some very simple measures, such as adoption and satisfaction with the new tool. But it would be a very bad idea to get any kind of end user satisfaction measures given that you just forced every developer and tester to double or triple enter data into disparate tools, at least until you hit Phase 6, and they’re already grumbling before Phase 1 is done.  In terms of actual business value delivery metrics, the new fragmented stack makes it impossible to get any metrics beyond those of a single tool silo, so you should be sufficiently shielded from being asked to get business-oriented metrics.  After all, your local Agile and DevOps optimizations should look like successes based on the fact that the tools are deployed, and the increased heterogeneity in the stack will make it very hard for the business to notice that fewer requirements are being delivered and that the defect rate has not improved. There will no longer be a single view on defects, as those are now spread across the different tool silos, so it’s not reasonable to ask you to collect those measures, especially since a lot of the newly deployed tools are SaaS, making access to their data require another tool or integration solution, which was not planned for the initial phase of the transformation.  Ironically, visiblity has actually dropped since you had the single vendor stack, and nobody can fault you for that as you expressed your preference for the single vendor stack of yesteryear all along.

Conclusion 

Every large organization wanting to step up its software delivery practices has hit upon these anti-patterns at some point.  We created Tasktop to provide a new kind of integration platform to make it easy to succeed with multi-tool and vendor Agile and DevOps transformations.  It has been amazing to see our forward-thinking customers purge these ways of thinking and gain the huge business benefits by transforming how they build software with integrated software delivery value stream.  What the Nokia experience taught me is that the ability to break through the mind-sets that underpin those anti-patterns can now make or break even the largest organization.  The success of digital and software delivery transformations will define which of the today’s companies thrive, and which decline and are displaced by their more innovative counterparts who have mastered lean software delivery. <=>