Comprehensive Software Reviews to make better IT decisions
Continuous Improvement May Not Be Good Enough
Delivering faster change is attractive.
Organizations try to become more agile and responsive to changes in competition and customer preferences. The commonly adopted pattern of periodic (quarterly) releases of new application functionality is seen as too slow to address change in a timely manner. In this approach, the period between conception and deployment of a change can be as long as half a year or more. As an alternative, organizations are adopting a continuous improvement model with changes deployed weekly. A change could, in theory, be deployed in less than a month from conception, a significant improvement.
However, the adoption of frequent change cycles has several drawbacks.
First, the limited and fixed capacity of an application support group limits the amount of work that can be accomplished in a cycle. This can enable many minor changes but generally precludes major changes.
Second, limited attention is paid to the changes by impacted users, as they are typically minor and occur frequently. This can limit the achievement of the intended collective benefits of multiple implemented changes.
Third, some steps in the development process (for example, architectural review and testing) are generally minimized as they slow down the change process. The result can be higher total cost of development, when one considers the longer-term rework required.
You can’t make major changes in a short time frame.
Continuous improvement (frequent releases) enables the rapid implementation of application changes compared to a bigger bang approach. However, the short time frame imposed on a development team to design, develop, test, and deploy changes, limits the scope of change possible. The approach can deliver a series of improvements quickly, but the degree of system change is typically small. Small changes can have big impacts, but organizations that want to achieve significant scope of change (consider an ERP deployment as an extreme example) need more development time and will generally need to revert to a longer release cycle.
If you introduce changes frequently, does anyone notice?
Many IT leaders complain about the limited adoption of the new features deployed in an application. Small frequent changes are even less likely to have an effect on anyone other than the individuals who requested the change. The effective communication of impending changes and their value to the user community is an essential contributor to effective and broad adoption and usage of any new features.
With weekly deployments, messages from IT are likely to be broadly disregarded. The communication of change should come from the user management or supervision and be positioned as a valuable business change and not as an IT change. When changes are deployed frequently, it is useful to communicate monthly an overview of all changes that are planned or have been deployed.
Are you short-changing architecture and testing?
Any rapid deployment approach is likely to short-cut considerations of architecture, infrastructure, and vendor changes and testing. In many cases this works out, but in some situations, these omissions can require later rework to address issues not identified during the development process.
When planning a quick release, confirm that skipping the activities normally included in a comprehensive development process does not create major risks. Do not assume that because the changes are small, the risks are as well.
The adoption of a continuous improvement approach involving frequent changes to applications can significantly reduce delays between opportunity identification and opportunity deployment. This does not make it appropriate as a universal approach.
Consider a more disciplined approach to development and a longer release timetable in any of the following scenarios:
- The degree of development is significant, and breaking up a change into several smaller components will delay the overall completion of a project.
- The benefit of the change requires significant user awareness and process adjustment, unless you have a very effective way of communicating frequent changes.
- The omission of key elements in the development process in the interest of speed will create a risk of deployment problems or the need to rework the solution later.
A continuous improvement approach for the evolution of application systems can accelerate the availability of improved functionality. However, it should not be adopted as the universal approach to application enhancement.
Large development initiatives, initiatives that depend on broad adoption of change and projects that require consideration of architecture, vendor relationships, etc., do not suit the small, frequent approach to application change.
Want to Know More?
Blueprint Software integrates financial services regulatory requirements into its core platform for easier traceability.
ALM Works Structure for Jira enables Atlassian customers to track and manage projects at scale.
Build out your collaboration tool chain to include diagram and design capabilities. An image is worth a thousand words in a requirements document.
Too many teams are “doing Agile” and mistakenly think that interactions over comprehensive documents means no more requirements. That may be true in a world of “Badgile,” but not when Agile is executed properly.
ServiceNow’s New York release extends the visibility, transparency, and collaboration capabilities today’s Agile and DevOps teams need.
Intake and backlog management are two of the top reasons for failed product and feature delivery. Skop.es brings the analytical and management practices to visualize, quantify, and verify and validate the delivery of the right requirements.
Application portfolio management (APM) is typically characterized as a subset of application lifecycle management (ALM). However, we see this capability included more often in enterprise architecture tools than in ALM software.
Atlassian’s Jira remains a popular collaboration tool for teams looking to improve work coordination. However, it requires third-party add-ons and integrations to support end-to-end artifact traceability and product delivery. Zephyr fills Jira’s test management capability gap.
The immense sprawl of products and product versions across the organization complicates manual inventory collection practices. Automated discovery and inventory tools help alleviate this challenge, but they do not negate the importance of end user and stakeholder collaboration and application capability mapping.