Implementing Software Lifecycle Integration (Part Two)
A step-by-step guide to implementing an integration ALM process
In part one of this article we discussed the value and importance of Software Lifecycle Integration (SLI), and the benefits of integrating your software delivery value chain; connecting the disciplines of planning, analysis, design, development, test and operations. We noted that as organizations try to take advantage of the software economy, they look to software delivery as a key enabler for business innovation. In today’s article we focus on the practical steps a software delivery professional should take in connecting the end-to-end software delivery business process.
When driving change within your software delivery stack, it is important you not only focus on the disciplines individually, but also connect them. However, that requires holistic change, and holistic change can not only be worrying to individual discipline owners, but also requires management outside of the disciplines to take responsibility for driving the change. Finding a sponsor, building the business case, and then delivering value from the change in a controlled and measured way are just a few of the steps required. Without holistic change, software delivery will continue to be a problem, and will not deliver the business value required as we navigate in the “age of software.”
A three-step guide to implementing SLI in your organization
If software is a key business process, it needs to be treated that way – with a clear focus, ownership and design. The practice of creating this process is emerging as a new discipline in ALM, one not focused on delivering the software, but instead on the process for manufacturing and maintenance of that software. This is in part similar to the evolution from craft approaches to more systematic engineering practices of the industrial revolution, but with one notable exception: the resulting process is not like a traditional factory, but instead more like a film set where clear information is shared across the different disciplines of the project. Because software is increasingly required to be delivered faster, automation has to play a role: connecting the different disciplines and the tools they use. This supports collaboration, as well as enables clear reporting for management.
Step 1: Build the case for automated integration
Like any change, it is important to get support and buy in from management for adopting SLI. “Automation” is perhaps the easiest cornerstone to build a case around; by automating the connection between the tools, organizations reduce waste and increase value. A good example of proving the value of integration is between development and test. Those teams often use different tools and follow different processes, resulting in a disconnected, slow, error prone and often confrontational overall process. By automating the connection between defects and supporting collaboration on those tasks, organizations eliminate the need for manual processes, spreadsheets and email. The business case is simple, since manual processes have a clear cost to operate, and by replacing those manual processes with automation, the case for SLI is made. Building this business case requires:
- An overall understanding of the current disconnects and waste between disciplines. For the last 50 years of software development, organizations optimized the disciplines in the form of improved process and tools. These changes did improve software delivery, however, it takes a village (and sometimes a town) to build software, and often those optimizations at the discipline level meant vast disconnects between disciplines. Therefore to improve the process, software delivery professionals must focus on disconnects between disciplines.
- A measurement of waste. Once disconnects are identified, the next step is to quantify them in terms of dollars or time savings. For example, if this manual step is removed, how much time would it save? How much effort? By building out detailed savings, any investment in integration can be justified.
- An understanding of the soft benefits achieved by automation. Not all the benefits can be translated into dollars and time, but can be just as valuable. Benefits such as governance and compliance; or the invisible time savings of allowing people to collaborate better, reduce mistakes and improve the ability to find information quickly all have an impact on the overall process capability.
Click here for a more detailed description of building the business case for integration.
Step 2: Build the SLI team
The business process of software delivery needs ownership, strategy and administration in the same way every other key business process does. Building a cross-discipline team including technical leaders and domain experts enables organizations to take control of the software delivery value chain. But this team also needs the support of executive management to effectively drive change into the business process of software delivery with a clear mission and set of objectives. The SLI team needs to include people from a variety of disciplines and functional areas, and should include:
- ALM Architect. ALM, like any other process, needs a clear and defined architecture and roadmap. This activity requires an ALM architect who will drive not only the integration strategy, but also the overall information, process and tool strategy. Often this role is fulfilled from the Enterprise Architecture team which allocates resources that focus on the tool chain. The benefit of having a person from the EA group is they are connected to General IT strategy and have an understanding of platform and technology roadmaps. Tools often have an affinity to platforms, thus the connection between SLI and platform technology ensures any ALM roadmap considers long-term platform decisions.
- The PMO/Resource Management. In the same way enterprise architecture provides a link between SLI and the general technology strategy, the PMO provides a connection to process, resource and governance models. Not only does the PMO need to integrate with ALM, but the nature of the software delivery organization is often defined by the PMO.
- Executive leadership. At the heart of SLI is the need for an organization to improve their software delivery capacity. That charter needs to be led by the executive, and as such they need to provide direct leadership to the team delivering that value within their organization.
- Discipline leaders. Whether it is testing, requirements, development or operations, all groups should have some representation within the SLI team. Each discipline will bring their own point of view, knowledge of the tools and understanding of their own discipline’s practices. Though SLI is often driven by one group, the reality is the value of an integrated, flowing software delivery value chain is far greater than any one discipline. Thus, by involving all the disciplines, it is possible to drive fundamental positive change to the whole value chain.
Step 3: Deliver value quickly and measure it
As it’s often said “the proof of the pudding is in the eating” and SLI, like any endeavor, only provides value after parts of the lifecycle are integrated, and information is flowing between groups in an automated, real-time fashion. Therefore, it’s critical any SLI initiative delivers value quickly. The best SLI initiatives tend to apply an Agile process to the integration work: defining a backlog of work; clear, measurable success; and structuring software delivery into sprints of value. Each sprint delivers some observable value that can be measured. This approach also allows the team to incrementally understand the problem they are solving. For example, a key integration may be between testing and development in the form of defects. By delivering that integration, it is possible to measure its success and understand more about the way the two disciplines integrate. Often this work uncovers fundamental process challenges or misunderstandings that require a change to how one process maps to another. Another key benefit of an incremental approach is it allows the team to demonstrate value and justify its work to executive management. Success often breeds success with successive integrations, adding more and more value; ultimately resulting in major improvements to the practice of software delivery. Each sprint or iteration should include:
- A backlog – The integrations, reporting and analytics should be broken up into a series of “user stories.” These stories will drive the work and allow the team to focus on delivering value in manageable, consumable chunks.
- A measurable definition of value – It is important the team deliver value to the organization in a systematic, structured way. That means there must be a clear measurement system in place for each user story to deliver into.
- A sandbox – Not all sprints should deliver into production systems, but instead to a sandbox that provides an environment to demonstrate what the new integrated processes would look like and how they would work. Integration by its very nature leads to process change within individual disciplines. By having a sandbox environment, the SLI team can provide demonstrations to disciplines affected by these changes.
The time is right for implementing Software Lifecycle Integration
The three-step program for implementing SLI is not surprising: building the business case, getting the right team, and delivering value while measuring it. What is often a surprise is the value obtained from integrating the disciplines, replacing manual processes and removing the need for complex spreadsheets and review processes. Because there is increased business value attributed to software in general, there is increased attention and focus on the process used to create and deliver it. Add to that contemporary issues such as Agile delivery techniques, and the opportunity of mobile and the cloud, and many organizations have the perfect storm for change within its software delivery capability. For organizations where an SLI initiative by itself may be difficult to justify, look to programs such as Agile or DevOps to encourage organizations to remove the barriers between teams, departments and disciplines.
About the Author
Dave West is Chief Product Officer for Tasktop Technologies. He is instrumental in building Tasktop into a transformative business that is driving major improvements in the software industry. He leads the strategic direction of the company’s product line and helps to define Tasktop’s market position. He is a former industry analyst at Forrester Research. You can reach Dave here.
Todd Montgomery Dec 19, 2014