Continuous delivery: When business is IT
Businesses and IT are bound to become more interwoven as software plays an increasingly important role in differentiating products and services. Companies that successfully integrate business and IT will be rewarded with a competitive advantage.
Yet “Business is IT” is easier said than done. What does it really mean? Continuous delivery (CD) is an approach that aims to answer that question by defining principles to guide how business and IT should work together.
When analyzing how business and IT typically operate, some pain points frequently come to mind:
- Business and IT operate at different frequencies.
- Once the business has pushed requirements to IT, it feels it is up to IT to execute on them.
- Once IT has received requirements from business, IT doesn’t second guess them, positively or negatively.
- Business sees IT mostly as a black box and is most of the time unclear on the sorts of requests that it makes of IT that are likely to increase costs, risk, and time-to-market.
If IT and business were in a marriage, I suspect we wouldn’t consider it a very successful one, despite each side trying to do its best.
What if, instead of focusing on departments, we focused on specific projects and products, where project-specific metrics and objectives could be measured? What if, instead of separate business and IT teams, we assembled teams mixing business, development, QA, and operations talents? What if we made the entire team responsible for the business success of the project, based on the success metrics of that project? This is essentially what CD is about. With such a team in place, there is no “us vs. them” culture, but simply a single team, working at the same rhythm and focusing on the same business metrics. What’s still left undefined is what that “same rhythm” should be.
Bite-sizing your projects
, aside from a lack of shared objectives, most projects also suffer from long release cycles, which tend to increase market and technical risk: The problems you identify today might not be the problems you need to solve tomorrow. The obvious solution is to have the virtual team work on much smaller iterations (possibly time-constrained). The unit for those iterations may be in weeks, days, or even hours, but certainly not months or years.
The idea is to have the virtual team work on specific deliverables, with expected outcome predefined, and to get the unit of work pushed to production and the result metered to see if it matches the predefined expectations. Full iteration, from requirement to production, with a feedback loop to the business and a keep or kill decision at the end. Then it starts over again. In companies with multiple teams and projects active in parallel, the pace at which code gets pushed to production can be impressive. For example, Amazon releases code to production every 12 seconds on average.
Recognizing IT is business
Because CD can yield dramatic competitive gains, the question is why it isn't already adopted everywhere. First, many companies haven’t yet identified how critical to their business software is. They understand that a well-functioning IT department is important, but that is still far from understanding that business is IT. Second, morphing a traditional silo-based company into mixed-virtual teams isn’t an easy process. It requires a radical change so that people with very different backgrounds can collaborate on a daily basis. It will challenge established reporting structure and, therefore, egos.
This will force the definition of measurable objectives up front — and no hiding when things go wrong. It will require teams to recognize failure when it occurs and accept it; failure is part of the discovery process toward success. It essentially requires the people in an organization to rewire their brains. With so much change involved, it can only work if top management fully endorses it and explains it to their teams.
If that all sounds daunting, keep this quote from Gen. Eric Shinseki in mind: “If you don't like change, you're going to like irrelevance even less.”