When a team decides to try reducing the time it takes for their ideas to get to their customers (cycle time), there are a few new technical investments that must be made. However, without business stakeholders supporting the changes in a SCRUM approach that delivers frequent releases, decisions and planning are driven by gut feel and not quantifiable outcomes. The following is a list of the top 5 myths I encounter (and often address when I provide coaching) to help staff that are not solely technically-focused when they begin adopting Continuous Delivery.
#5: By automating deployment, we will release more profitable ideas.
Automating deployment of IT assets to reduce low value activities like manual configuration and deployment (with risky error-prone manual human intervention) certainly can eliminate wasted capital as part of the process of releasing IT offerings, and is a key practice of Continuous Delivery. However, if the frequency of releases is long, the cost of delaying the availability of those releases to customers adds risk in that their viability in the market may no longer be what was theorized when it was planned.
Once release frequencies are improved, measurement of customer impact and proper work management (specifically appropriate capacity planning and calculating the cost of delay for potential features) must be done to ensure that ideas that turn out to be misses in the market stop stop being worked on as soon as they are identified as bad investments. It is this harmony of smart economic decisions with respect to investing in the idea combined with the technical benefits of building an automated deployment pipeline that transforms the profitability of an IT value chain.
#4: We must automate 100% of our testing to have confidence in automating releases to production
Utilizing automated quality checks to ensure that changes to IT assets do not break existing functionality or dependent systems is certainly a good practice. A long manual test cycle is doubly problematic: it delays releases and adds risk since many teams try to get started on new work while testing is underway. When issues are found with a release candidate build or package being tested, engineers must stop what they are doing to troubleshoot and attempt to fix the problems.
On the flip side, automating the entire testing effort has its own risks as the team can cost the business large sums by having to change and maintain tests when they make changes to the design which happens frequently in Continuous Delivery. Deciding on an appropriate test coverage metric and philosophy should be treated with importance and not included in work estimates as separate line items to discourage removal in an attempt to cut costs. Cutting quality is often the final dagger in the throat of a struggling IT offering.
#3: The CFO requires us to release everything in the backlog to report costs
Many businesses treat IT investments as capital expenditures since they can take advantage of amortization and depreciation to spread the cost of that investment over a longer time period. However, this assumes that the value in the investment provides a consistent return over the lifetime of it being used to generate revenue. A SCRUM process for delivering IT assets aligns better with being recorded as operating expenditures since a minimum viable offering is typically released with a low initial investment in the first few sprints, and the business makes ongoing "maintenance" changes to the offering as the priorities of the market and customer needs change. This is especially true today with everything moving increasingly to cloud based models for value consumption.
#2: We need a "rockstar" in each role to deliver profitable offerings
Many IT offerings that start with an idea are initially implemented with an expert in a particular technology or aspect of delivery, and the team leans on them early on for implementation and expertise. As the complexity of a solution expands, the biggest drain on the profitability of a team is no longer the availability of experts and the high utilization of people’s time – it is the time work to be completed spends waiting in queues. There are several ways to reduce wait time when work with a high cost of delay is held up in a queue. The two methods I see with the most value are to reduce the capacity utilization of team members, and to enable staff to work on more than one discipline.
When team members are highly utilized (their planned capacity is over 60%) this leaves no room for the highly-variable process of delivering IT offerings to account for unknowns that were not identified during planning or design of a cycle of implementation. If the cost of delaying the availability of an idea is high, the cost increases when the date planned for release is missed. Rather than loading resources up to a high capacity, leave them with reasonable overhead to collaborate, tackle unforeseen challenges, and help each other if they finish early.
When team members are specialized, the probability of one member being blocked from continuing by another goes up dramatically. Work to be completed spends more time in a queue wasting money and not moving closer to being made available to customers so it can realize a return. Though you will always have team members that have expertise in specific areas, resources that are willing to test, make informed product priority decisions, and help with deployment and automation are more valuable as part of an IT value stream than specialists. Use specialists when the work requires it, but scale more of your resources out across multiple disciplines for sustainability.
#1: Until we release everything in the backlog, we won’t succeed with our customers
This myth is driven by the manufacturing mindset of looking at IT offering delivery as though all features must be identified up front and misses the point of agile methods entirely. The backlog is a set of theories on what customers will find to be valuable at any given point in time. Any offering that takes more than one release to complete will have a working minimum viable product available to some audience where feedback can be gathered before it’s done.
Since the point of frequent releases is to get that feedback and let it impact the direction of the IT offering, planning to release everything in the backlog leaves no capacity for taking action on that feedback. If you only plan to release everything the business thinks is a good idea at the beginning of a project before letting customer feedback influence priorities, you are simply releasing milestones of planned up-front work – which is a classic waterfall delivery process.