Forrester Research recently found that 81% of business leaders surveyed believe that technology is a fundamental element of their business model. Software is increasingly center stage in business’ ability to deliver new products or services and to exploit new channels. This relationship has blurred the lines between business and technology innovation; where technology was once a servant, it is now engaged in a more symbiotic partnership with the business. But this increases complexity, uncertainty and urgency—technology must work in business time, requiring increased delivery velocity.
Being center stage is exciting, but also carries high risk. Business expectations are much higher, and your software delivery operation will experience the most powerful forces at work in the business technology world today, including customers that have more choice and voice, empowered (and demanding) users, and real-time business analytics that put data at the fingertips of people all over your organization, people who will demand smarter apps.
Minor tweaks to traditional approaches won’t cut it. These traditional approaches sought to optimize technologies, assets and specialized functions in pursuit of efficiency and value. Their supposed efficiency, modeled on mass production, doesn’t work when the definition of the problem keeps changing, because app delivery leaders find it difficult to change their processes, technology and team composition in response.
The intersection of new business models with new technology is the most fertile ground for new business opportunities, but succeeding at business technology innovation is not about automating known processes. Innovative teams must explore and observe more than they analyze or design. By delivering working examples early and often, teams enable business and technology sponsors to validate their understanding of the requirements and the solution, an approach that provides insight and enables course corrections.
Modern approaches to software delivery must reduce risk by delivering working software frequently, keeping it small to avoid costly mistakes, involving the right people in the delivery process, and empowering a decision-maker. One of the biggest sources of waste in traditional software delivery projects is waiting for the right set of decision-makers to meet to provide direction and review requirements or architectures.
Unfortunately, the reality for many businesses is that change is happening much faster than ever before. To keep up, software delivery organizations must adopt a continuous delivery approach, and increase the use of automation and tools. In the context of rapid change, quickly ensuring that everyone on the team knows what other members of the team are doing reduces miscommunication and increases synergies. It also enables teams to see problems as they happen so they can adjust in flight.
Few elements of software delivery are more crucial to succeeding at a product approach than quality. Expectations of internal apps’ quality are also rising as users become more sophisticated. They want their internal apps to work more like consumer apps. Add to this the increased integration and complexity of modern software, and you have the perfect quality storm. Increasing quality requires an end-to-end focus on and a broader view of quality. It also requires that everyone be responsible for quality.
#!
Keeping up with complexity
As software becomes more complex, the velocity of development increases, the importance of quality rises, and separate QA groups become a bottleneck. By encouraging and supporting everyone in understanding their role in quality and promoting shared ownership, application delivery organizations can drive better-quality outcomes.
No successful firm starts with a clean sheet of paper: Applications and the processes they support are in place delivering value today, so it’s crucial that you take a holistic approach to change that is inclusive of process, organization and architecture. Architecture takes time to change and often inhibits efforts to increase quality and velocity. Therefore, you must begin building a strategy for your program by assessing your existing architecture, organization and processes.
In doing this assessment, you will likely build or enhance a high-level view of your application portfolio. Geoffrey Moore argues that you should segment applications into systems of record and systems of engagement. You can use this segmentation to evaluate where each application should fit into your overall strategy for change. It’s likely that the processes, organization and even technology architecture for systems of record will be different from those for systems of engagement.
This means that introducing agility requires you to make architecture part of the change and to support more than one delivery approach. It also means accepting “water-Scrum-fall” as the reality. Planning and release processes take more time to change, and, because of constraints in your existing practices, may require a more gradual and incremental transition.
Development teams have adopted agile in many organizations, enabling a different way of delivering software to creep into the software value stream. At the same time, business is increasingly looking to software as a key means of innovation. These two trends are converging, creating an environment that encourages the adoption of a completely new way of looking at the whole flow of software delivery that realigns it to business value, and encourages adopting processes and tools that speed its execution.
But pursuing this opportunity requires application delivery organizations to transform the entire value chain: people, process and technology. Lean thinking provides the basis for this transformation, with techniques and a mental model that focus on increasing value and reducing waste.
Mike Gilpin is a vice president and research director at Forrester Research, where he serves Application Development & Delivery Professionals.
