According to many reports: Business interests are not confident in IT to deliver on the requirements in the new era of the digital business. In a recent interview with InformationWeek, EMC president, Jeremy Burton explains that in their survey of 3,600 global business leaders: “Seventy-five percent of business leaders who come through our doors do not believe IT can deliver the innovation needed to transform the organization.”
The annual State of Business Transformation research confirms attitudinal issues in that there is an apparent disconnect between business leaders and IT contributors in terms of expectations, concerns, and priorities.
Confirming the disconnect, Forrester Research writes: 41% of business decision-makers believe that IT is an impediment to accelerating business success.
Forrester Research suggests a solution.
According to Kurt Bittner, Principal Analyst at Forrester Research, the latest incarnation of Continuous Delivery (he calls it 3.0) is serving a new, valuable purpose.
He contends that “version 2.0” iterative development has been helping companies streamline and automate the pipeline. However, as the organization is demanding more IT input, application delivery organizations are facing unprecedented pressure to produce rapidly, frequently, securely, and interactively from schematics and expectations based outside of IT. This means that IT now manages processes and tools *and* the expectations of all of the people involved: developers, operations, QA, business stakeholders, and sometimes customers.
This is likely where some of the disconnect is coming from. For a long time IT has been ill equipped to do the people management required to assure business leaders they are on top of the situation.
His solution: Utilize the cadence of Continuous Delivery to manage expectations outside of IT in a way that doesn’t disrupt how the application development team functions.
I’ve seen this firsthand.
In my 20 years, I’ve watched “Continuous Delivery” grow out of “Continuous Integration” — which was a beachhead capability that forced development teams to more closely monitor their own progress and respond to issues and defects in their code. As processes and teams have matured over the years, Continuous Delivery now includes the ability to take code, configuration changes and regularly deploy and migrate them into production.
Like Kurt Bittner’s analysis, I see the opportunity in the next stage of evolution. The digital business requires recognizing that any significant business application change carries with it the “deployment” of changes that propagate all the way out to end users and business stakeholders.
“True” Continuous Delivery — or as Kurt would say, 3.0 or Next Gen Continuous Delivery — is going to require the coordination of not just IT staff and assets, but training, documentation, changes in workflow, policies, reporting, business process governance, etc. To continuously deliver beyond bug fixes and incremental, low-impact changes; IT leaders have to coordinate across the entire value chain — starting and finishing with stakeholders.
This is especially important as project deployment becomes more business critical.
At Headspring we’ve seen rate of deployment as one of the best indicators of overall project success. The more often a viable product or feature is introduced at strategic milestones to key stakeholders, the more feedback they are able to provide, the more ownership they have, and the more impetus they have to train their staff or develop their internal deployment plans. In other words: The more often this happens, the less we see fully-functional products sit on shelves.
A good example of this is our work for this State-government trial case management system. In this case study, the multitude of stakeholders — from internal owners to State administrators and individual prosecutors — realized true value from viable products iteratively deployed by department.
In the end, over 30 unique department workflows were ultimately launched and the primary client conceded: if Headspring had waited to launch until the whole project spec was complete, as opposed to iteratively, it would not have been a success. There would have been too much input for the internal project leads to handle and prioritize. Stakeholders would have earned an apathy in the project because there would have been instant dissatisfaction or a long wait for input to be received and implemented.
Without “Next Gen Continuous Delivery”, the considerable effort would have been shelved or the stakeholders would have been underwhelmed with their IT organization — which is exactly what IT organizations are facing around the world. Because this project launched in this way, the opposite has happened: everyone is pleased with their contribution and the application delivery team has newfound credibility.
Are you ready to dig deeper?
This topic is so close to our heart, here at Headspring, we’ve invited Kurt Bittner to work with us on a presentation. [UPDATE] On August 26, 2015, Headspring and the Forrester analyst conducted a Lunch & Learn with a live audience in Chicago and online via webcast. A recording of the presentation is now available to watch on-demand and the slides can be downloaded. Take a look:
Next Gen Continuous Delivery: Connecting Business Initiatives to the IT Roadmap
It’s important to Headspring for application development organizations to wrangle the needs of their customers and execute with excellence. Our most successful case studies have been kindred spirits who seek to keep the respect they’ve earned deploying successful enterprise applications on time, on budget, and on scope with reliability. If you want to learn more, be sure to watch the presentation and join us for future presentations.