According to Maverick Research, by 2021, Bimodal IT Will Be for Digital Losers.
The DevOps forms the foundation of this digital transformation; eventually this will determine the Digital Winners and Losers. In the DevOps adoption survey conducted by Gartner (August 2016), less than 38% are in the DevOps transition with 19% still struggling in pilot phase and remaining 19% using DevOps for production system (in some form). This is clear indication of crack in the adoption curve between "Early Adopters" and "Early Majority" - The chasm (concept inspired by Geoffery A. Moore).
The typical adoption cycle follows the pilot model (the early adopters) and transition the pilot into mainstream - production ready (early majority).
What creates this Chasm, and why it is hard to overcome?
The Early Adopters/ Visionaries, in our case the pilot projects are driven by dream. The Early Adopters is buying a revolutionary change agent (DevOps) and have following expectations viz.
• Expect a clear discontinuity between the old model and the new model - DevOps
• Expect clear strategic advantages of adoption DevOpos
• Tolerate imperfections and glitches
The Early Majority are more pragmatist, very loyal to what works &are proven. They are risk averse, but rather prefer incremental improvements on proven models/solutions.The Early Majority is buying for productivity improvement for existing operations and their expectations are -
• Want to minimize the discontinuity with the old way (seamless transition to DevOps)
• Wants innovations to enhance established business processes
• Expect a more or less disruption free product (consistency in SLAs)
This chasm is already hard to cross dealing with two different mindset of folks and we make it harder by trying to repackage the solution that appealed for Pilot group for Larger Early Majority - One size does not fit all.
How to cross the chasm?
You can cross this chasm by targeting on the niche first.
First:We might need to pick a very targeted and specific niche inside the early majority to focus upon; this is like first securing a beachhead in an invasion.
The typical challenges of the mainstream/ early majority are around“Developer Productivity Killers! “ which eats into Speed, Quality and Costof a project viz.
1. Infrastructure agility ->Solve: Virtualization & Cloud Strategy [Speed]
2. Reducing Multiple Instance paths –>Solve: Trunk-based development [Cost]
3. Code Stability/ Instance stability challenges –>Solve: Continuous Integration [Cost & Quality]
4. Technical-debt of Legacy monolith ->Solve: Loosely coupled architecture [Speed]
5. Security Vulnerability –>Solve: Shift Left on Security (DevSec) [Cost & Quality]
6. Last Mile Problem –>Solve: Continuous Deployment [Speed and Cost]
Please note that a Pragmatist would not buy into 80% solution, it is 100% or none.
Second: Target the point of attack
It is very importantto clearly define the FINAL goal and the incremental KPI targets that would enable the Pragmatist to see value to reinforce the confidence for the early majority. Clearly articulate the goals that is tangible and understood by all for each quarter, build means to measure and course correct.
Example(s)
• Production Ready code any time
• Deploy when Ready (done)
• No touch deployment (address the last mile problem - FIRST )
Third: Assemble the invasion force - Define your framework Definition of Done (DoD)
The Definition of Done (DoD) varies significantly across organizations.
Survey by dZone research 2015 edition - 79% say its when all code compiles and builds for all platforms. Other common answers were: Features reviewed and accepted by Product Owner (65%), Unit tests are implemented for new functionality and are all green with known failures noted (63%), New features are system-tested (59%), and Acceptance/story tests are written and passing (52%).
I suggest keep it flexible as 2 or 3 models (not more) which can be used by each team based on their business needs -
• DoD 1 - When Feature is ready to be deployed (all validations done)
• DoD2 - When Feature is delivered in the product
Bite sized requirement (Features)
The ability to breakdown the requirements into discrete BITE sized features will determine the success of the continuous delivery framework. The key advantages with this is-
• It brings full control for delivery, testing, build, release, fix and roll-back (to meet the MTTR if needed)
• It can be handled by a small team (full stake delivery teams)
• Business validation is short and simple (no need for full integration).
This is more easily said than done and need a thoughtful process even from the stage of requirement analysis and backlog grooming
Built in Quality (part of delivery)
The culture that “DevOps (Developers in the old terminology) owns quality -” is very important. Make this a DevOps accountability rather than silo QA, build quality in your development lifecycle through automation and services testing.
Continuous Integration (CI)
This logically takes us to the Continuous Integration (CI), clearly define the framework-
• Frequency of build (Daily orHourly)
• Scope of automated testing (Regression + Impacted Regression+ Feature driven testing)
Once you define your scope of automated testing, and then work backwards for each sprint in terms of tools and means to shift left to get the Feature and Impacted regression within the sprint. This could be very challenging and this is where the automation and delivery teams give up.
Full Stake Delivery teams
I like the phrase “God cannot be everywhere, so he created mothers”. So that is the message, admins cannot be everywhere, enable all developers to handle admin tasks that is routine. The same applies for all stacks - middle ware, database, UI etc. A team should have a good composition of developers who can handle multiple tech stacks (one above-one below, will do to start with).Bring in the culture of self-reliant full stake delivery teams.
Collaborations
Make “Kanban” or any one single framework as your single pane of glass, internal and external. This bring in transparency and make it available for stakeholders.
Fourth: Define the battle
Positioning is key for success. It is important to position this new model (DevOps) to be compelling and make strong claims in the niche that is selected say last mile problem, infrastructure agility etc (refer first step). Pragmatists want to know where you stand with respect to your competition (current model that they are following. In case some of this niche does not align to traditional IT, define your competition yourself i.e. set goals for the niche.
Fifth: Launch the invasion
The weakest link determines the strength of the chain, focus on Achilles heel of the niche within the Early Majority be it daily deployments, code stability, last mile problem etc. Force old methodology out of that niche area and use it as a base for expanding DevOps offerings to the mainstream.
Finally: Getting Beyond the Chasm
Going back as Geoffrey puts it, we need to recognize that prechasm commitments are simply unmaintainable in the postchasm period. In our world, the DevOps Pilot and Mainstream. DevOps pilots may promise a level of performance or reward that is hard to meet. This leads to a situation that we need to manage our way out of the contradictions imposed by prechasm agreements.The first and best solution [is] to avoid making the wrong kind of commitments during the prechasm period i.e. Pilot Projects and focus on setting realistic targets for early majority from pilot stage.
