Speed or Stability?
We're familiar with illustrations and diagrams showing trade-offs and compromises. Can you deliver with speed and quality? This way of thinking has impacting software development process and has created new silos under this assumption. Conventional wisdom would say that faster delivery comprises the system's stability.
Traditional ways of software delivery result in battle between speed and stability.
The response to this question reveals the fragmented organization structure and silos. Developers are motivated to push new code as often as possible, while testers are incentivized to find and report bugs. Meanwhile, operations and security teams are evaluated by stability and often resist introducing changes to the system. As each of these groups seek their own goals at the expense of the larger organizational goal, the constant battle of speed or stability war on. Ultimately, the result is a stalemate with a downward spiral of unproductivity and lost business value and revenue.
Speed enables stability¶
"High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in they get both." - Dr. Nicole Forsgren
Although at first it may sound counter-intuitive, faster delivery results in greater stability. Continuous delivery results in amplified feedback loops, which will in turn result in more robust systems. It will force organizations to evaluate their cumbersome process and manual tasks. It will result in automation and innovative solutions to complex bottlenecks friction points. The new feedback loops will provide additional learning opportunities.
Build quality into the product¶
"Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place." - Edward Deming
Instead of the traditional approach to software development with multiple hand-offs from development to testing, cross-functional teams should work together in-sprint to build automation frameworks and account for testing as part of their definition of done. A team's working agreement and automated build pipeline can serve as a guideline to reinforce quality now in favor or added technical debt later.
Created automated, repeatable processes¶
"Our goal is to make deployments routine affairs that can be performed on demand." - Jez Humble
We advocate for boring, non-eventful deployments. Building artifacts, running tests, configurations, deployments - these should mundane tasks that are better suited for machines than humans. Humans excel and solving complex problems and machines are good at executing repetitive tasks.
"To have humans executing tests that should be automated is a waste of human potential." - John Willis, DevOps Handbook