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?
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.
Aha! introduces scenario planning to give product owners the ability to create and compare multiple release approaches based on team capacity and backlog priority.