Many organizations make the same agile and DevOps scaling mistakes year after year, then attempt to rectify them by putting together a great new strategy—only to miss the reasons causing the failure. If you want to refuse to evolve and, as a result, cause your organization’s agile and DevOps transformation efforts to deliver zero business value, be sure to follow these seven antipatterns.
As someone who helps companies through their software delivery transformations, I’ve seen my share of ineffective behaviors. What I find most mind-boggling is witnessing an organization making the same agile and DevOps scaling mistakes year after year. They attempt to rectify the mistakes by putting together a great new strategy, only to miss the reasons that caused the previous transformation to fail to deliver business results.
Recently I made a third visit to a 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. I got a vivid image of at least a billion dollars wasted already, and the multiple billions more that they were about to set fire to if they didn’t learn from the past.
Thankfully, most large organizations are already seeing the light and steering away from this state. But in case you’re interested in burning your organization’s cash on agile and DevOps transformation efforts that deliver zero business value, here’s my quick collection of antipatterns to follow.
Antipattern 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 tool chain. As agile displaced the Rational Unified Process, ClearQuest, and ClearCase, things became a lot messier.
You should do everything you can to get things back to the very neat way they were before, while paying some lip service to the stated need of bringing 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 Visual Studio Online and Team Foundation Server, then the Java folks better be happy using that instead of JIRA.
As for all the new testing and other special purpose tools, especially open source ones, those are just a fashion industry driven by software geeks who need 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.
Antipattern 2: Worry about integration later; your internal IT team can handle it
You’re living in the past and trying to push everyone back to the equivalent of a single vendor stack, so 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 enterprise service bus, 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 two times easier than it was in the world of API proliferation and microservices. APIs these days must be fully documented and cannot be changing as much as they used to. Also, there are some cheap agile and 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 and DevOps flow goals; their failing to do so would make integration across tools impossible regardless of APIs, so surely they know better. Even if the senior architect 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.
Antipattern 3: Optimize your tool chain one silo at a time
Dealing with all these tools is onerous, so you’re best off focusing on one tool and practitioner silo at a time. Focusing on your DevOps automation and continuous integration 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 can worry about the 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 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. It’s 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.
Antipattern 4: Forget about requirements and quality management
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 and 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 about 3,700 employees—and you have more IT staff than that—but clearly what they’re doing must correspond directly to your IT challenges.
There must be some other way for business partners across your multiple lines of business to communicate with developers, such as being collocated 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.
Antipattern 5: Ignore Ops and ITIL; they ought to be out of scope
There is no way 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 visibility into what’s happening when their software is running in production, resulting in a lot of emails and even more tool integration requests. It’s best to let sleeping dogs lie and worry about integrating the flow of information between development and operations in Phase 4.
Antipattern 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 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, and that, by definition, it means 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 tools 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 so they can get business-critical apps out the door.
Antipattern 7: Don’t bother with metrics
The very last thing that you want to do is to consider how you will measure the success transformation. Any 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 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 because a lot of the newly deployed tools are software as a service, making access to their data require another tool or integration solution, which was not planned for the initial phase of the transformation. Ironically, visibility has actually dropped since you had the single-vendor stack, but nobody can fault you for that: You expressed your preference for the single-vendor stack of yesteryear all along.
Advance beyond the Antipatterns
Every large organization wanting to step up its software delivery practices has hit upon these antipatterns at some point. It has been amazing to see companies purge these ways of thinking and gain huge business benefits by transforming how they build software with an integrated software delivery value stream.
The ability to overcome the mindsets that underpin those antipatterns can now make or break even the largest organization. The success of digital and software delivery transformations will define which of today’s companies thrive—and which decline and are displaced by their more innovative counterparts that have mastered lean software.
