Predictability is the primary reason companies embrace agile over waterfall. The full slate of reasons vary depending upon the context of the company, and it would certainly not come as a shock that many companies embrace agile because it’s hip. But for the most part, large companies (aside from the ones trying to be hip) tend to embrace agile for predictability with a capital P.
Delivering peace of mind
Executives at large enterprises love predictability and they should. Predictability in the outputs of a software shop allows the executive team to run the business rather than the manufacturing floor. “Once we are using agile, we will make faster decisions, and all will be good,” they say. This is where the house of cards starts to wobble.
Many people talk about the flaws of agile. The co-author of the original agile manifesto, Andy Hunt has called into question the formalist approach that the entire industry has taken as it distorts the original premise of agile: freedom from blind obedience to rules without context. Hunt is attempting to start anew with the GROWS methodology designed to ensure qualitative principles that cannot be overcome by formalism.
I hope Hunt achieves his goal, but I am doubtful given humanity’s love affair with certainty.
A closer look
I’ve recently stumbled on what appears to be a nearly certain, and sometimes fatal, flaw when you apply agile at scale but do not follow through with a DevOps transformation.
The flaw is not inside agile itself, but sits just off to the right of agile. If agile does its job well in conceiving and developing working software rapidly, anything that happens after those tasks must be ready to receive it at, or better than, the same pace that the agile teams are handing it off.
- If there is an impedance mismatch in QA, predictability suffers.
- If there is an impedance mismatch in performance testing and engineering, predictability suffers.
- If there is an impedance mismatch in release management, predictability suffers.
- If all post-development tasks have an impedance mismatch, predictability goes out the window in the form of low quality, poor performing software whose deployment was flubbed at best and misconfigured at worst (misconfigured software appears to work at first, but doesn’t work at scale or at integration points).
The flaw isn’t that surprising. It occurs in any system where humans divide labor amongst groups. Whenever labor is divided serially, complexity of the handoffs becomes the primary factor that limits the predictability of throughput (this is one of the major factors in the trend of deeply annotated wireframes and why waterfall design waned while lean UX and agile waxed).
DevOps has seen the tsunami that results from loosened upstream constraints and provided tactics to not only stay afloat but to ride the inevitable wave:
1. Full stack engineers
Conceptually, the mechanism of m-shaped staff members (sometimes referred to as hybrids), has been around for quite a while. M-shaped staff, as opposed to t-shaped staff, go deep in several areas.
A great way to beat handoffs and the difficulty of integration in multi-disciplinary development is to have people on staff who can span roles. In smaller environments like start-ups, full stack engineers who know everything from firewalls to front-end development can help beat the costs involved from having specialists in back-end development, front-end development, network and infrastructure engineering, and so on, ad infinitum.
Given that hybrids are rare scaling this model can be quite difficult for enterprises with a plethora of web sites, applications and infrastructure.
This brings us to tactic two:
2. Tool builders
Trying to be agile in a large enterprise without a tools team is an exercise in futility. Agile without a continuous integration pipeline is like a good idea without any execution: frustrating at best and a complete cluster at worst.
A CI pipeline that doesn’t account for regression, performance and release management is like watching a rerun of I Love Lucy at the chocolate factory. A true continuous delivery capability requires not only these but also a robust monitoring capability to create the fast feedback loops that minimize unplanned work. A shop that doesn’t control unplanned work will forever be doomed to underdeliver on the key metric that started this whole conversion — predictability.
CI pipelines, CD automation and monitoring are the tasks of tool building teams. While I have claimed that DevOps practitioners can start almost anywhere, it’s important to understand that the journey won’t come to a close without a solid implementation of all the tools necessary to take committed code, get it shipped and then to watch it closely in production.
Is half of a transformation transformative?
You can transform into an agile methodology all you want, but if you want to scale your capability, get ready to complete the transformation with a robust DevOps effort or it will all be for naught.
This article first appeared on CMS Wire.
