Recently in Change Management Category

Evergreen applications are business applications that continue to evolve as the business changes and so provide constant value, year after year. At OutSystems virtually any solution that is deployed using Agile methods is required to stay evergreen and subject to a continuous Agile Evolutionary Maintenance process. Part 1 of this article explored the main phases of the Agile Evolutionary Maintenance process and defined the three key project types that are most common.

In Part 2, I will shift my attention to defining the different types of backlog items that typically make up an evolutionary maintenance sprint. In addition, I will define some key technology challenges you must overcome in order to deliver on the promise of evergreen applications. Finally, I will describe how OutSystems can help in this process.

Backlog Items of Evolutionary Maintenance

The typical backlog items that are part of an evolutionary maintenance release include:

1. Defects - fixes to application defects and business processes that are not correct for real life conditions, and therefore impact daily business operations;
2. Application inefficiencies - over time, applications composed of multiple services will experiences changes in performance profiles due to changing business use and shifting service load. It's key to identify and overcome performance inefficiencies such as:
   
   • Slow Web pages;
   • Slow database access;
   • Integration bottlenecks in distributed services architecture.
3. Usability improvements - overcome annoyances that impact user efficiency or adoption;
4. Change Management - Incrementally deliver new valuable features. Either selected from ones left out of previous releases or newly identified during the use of the live application.

Challenges of Implementing Agile Evolutionary Maintenance

To achieve an effective Evolutionary Maintenance process it is imperative that the maintenance team has the right tools. They need access to development and project management tools which:

• Allow them to assess application performance;
• Assist with capture and prioritization of change requests;
• Streamline the change, test and deployment process.

Without the proper application delivery and management environment your maintenance teams will not be able to deliver the agility needed to keep your applications evergreen. Let's explore these key challenges in a little more detail: 

1. Automated instrumentation of the application that doesn't require expensive operational support, extra coding, etc. This is important in order to understand where to invest in code optimization when dealing with application performance issues. Areas on which to focus attention:
   
   • Identification of the application web pages visited, their rendering time and isolation of slow screens that should be reengineered;
   • Identification of slow queries that may require optimization;
   • Performance assessment of the web services and APIs being used by the application to provide access to external systems;
   • Review of application error logs;
   • Centralized analysis of all application feedback including performance logs, audit logs, etc.


2. Enhanced capabilities for end-user collaboration to gather feedback on application usage. This capability is critical in order to address incorrect application behavior and improve usability and adoption. Areas on which to focus attention:
   • Provide the end-user with the means to give feedback on the application behavior. This process should be intuitive for users and result in unambiguous feedback for the maintenance team;
   • Streamline feedback management to effectively classify, prioritize and transform the user feedback into manageable backlog items.


3. The availability of enabling technology which supports rapid change and boosts delivery efficiency. Areas on which to focus attention:
   • Provide adequate application documentation when planning for evergreen applications. This is because the person performing maintenance tasks is typically not the same as the one who developed the original application; therefore it is critically important that the application's structure and logic is easy to understand;
   • The development tools must make it easy to respond to change by supporting the change process. In our experience this includes tools that automate impact analysis and isolate change , which in turn, minimize testing and improve overall development team productivity;
   • The application configuration and build environment must be automated to remove errors and support a rapid deployment of changes to test/production environments.

How OutSystems Helps with Going Evergreen

OutSystems' Agile Platform and project management tools provide the technology needed to shorten delivery cycles, increase software development agility, project predictability, responsiveness to business change and overall development productivity. For Evolutionary Maintenance teams, OutSystems technology addresses the key challenges faced by maintenance teams when going Evergreen:

• The Agile Platform automates the logic required to collect performance data and audit information. In addition, it supports the automatic logging required to address performance tuning, including monitoring third party integration done via the platforms Integration Studio toolkit;


• The Agile Platform's Service Center tool provides the necessary functionality to analyze performance data and audit logs collected from the application during run-time;


• The Embedded Change Technology (ECT) and the Agile Network's Issue Management tool ensure end-user collaboration :
  • ECT provides an easy way to collect application feedback from testers, end users, etc. ECT provides meaningful information based on feedback directly from the application screen, and all feedback is automatically registered and stored in the Issues Management tool for the project;
  • The Issue Management tool handles end-to-end issue management, from capturing user feedback, to issue classification and prioritization. Issues can then be included in the maintenance release backlog for delivery.


• The Agile Platform's TrueChange™ engine supports automated impact analysis and self-healing. This streamlines the change process and assures that quality applications are delivered. Self-healing is unique to the Agile Platform and is made possible by the fact that development is done in a model-based environment. This allows the platform to understand and manage all changes across all the development artifacts. For example, a simple change request to "add a new field to a Web page form that is only visible to a Sales Manager" might require changes to the User Interface, Data Model, external Service APIs, Access Control rules and Business Rules. With its full reference checking and self-healing capabilities, TrueChange™ safely rebuilds the sections of the application that can be automatically inferred, and provides the Business Developer with impact analysis on any manual changes he or she may still need to make to fully address the requirement;


• The Agile Platform's 1-Click Publishing streamlines the configuration management, build and deployment process - effectively reducing common build errors and the typical build and deploy time to minutes.

An Evolutionary approach to Maintenance is key to keeping your applications evergreen and delivering the best business ROI. As you expand your teams' Agile processes, you can apply the Evolutionary Maintenance phases defined in Part 1 of this article across a variety of different project types and architectures. To be successful you will need to overcome the technology challenges described in Part 2.

Be sure to review how OutSystems can help for your web business applications!

Evergreen applications are business applications that continue to evolve as the business changes and therefore provide constant value year after year. At OutSystems, virtually any solution that is deployed using Agile methodologies is required to stay evergreen and subject to a continuous Agile Evolutionary Maintenance process. Part 1 of this article explores the main phases of Agile Evolutionary Maintenance while Part 2 identifies some key technology challenges you must overcome to deliver on the promise of Evergreen Applications.

Setting the Stage

Once your application goes live, it immediately enters the Agile Evolutionary Maintenance phase and will stay in this phase in order to keep up with changing business needs and to address application inefficiencies that are only identified with "real life" demand and conditions. To successfully deliver on this concept, the Agile Maintenance team schedules regular sprint releases focused on delivering the "next most valuable features" for the business.

Through this sequence of regular Evolutionary Maintenance releases, the application will keep up with business needs while minimizing the impact of change on the business. The underlying principle is the same as for general Agile development - fast deployment of the most valuable features, delivered on time and aligned with the business.

The Agile Evolutionary Maintenance Cycle

The Agile Evolutionary Maintenance process is a continuous cycle of application releases. Each cycle includes the following steps:

1. Gather defects, user feedback and new business needs for the live application. This step is actually
   a continuous process that normally occurs in parallel with the applications' release process;
2. Classify and prioritize all the feedback collected;
3. Convert the classified feedback into project backlog items, agreeing on the next release content.
   The focus should be on the most critical defects and highest value change requests;
4. Develop and deploy the Backlog agreed for the next release.

Evolutionary Maintenance releases depend on the volume and type of change required. In my experience these releases fall into one of the following three categories:

• Hot Fixes - quick intervention required to fix a critical defect that is dramatically affecting business operation, and deploy it immediately. These interventions are required to be completed in less than 24 hours and in some cases during the next couple of business hours.
• Sprint Releases - made up of one sprint, lasting one or two weeks. In Agile Evolutionary Maintenance it's common to set regular short releases to keep answering accumulated user feedback and correct non critical defects.
• Evolutionary Projects - When there is a more substantial business change, then a specific evolutionary maintenance cycle may be extended to a small/medium project with several 2 week sprints. This is a common approach to deploy a very large application: incrementally release extra functionality that has not made it into the initial agile project. Experience has proven time and time again that waiting for the perfect and complete solution leads to a less than expected return on investment due to constant changes in business scope and delayed benefit from the new application features.

The Agile Evolutionary Maintenance cycle is critical to keeping your applications evergreen. Following this approach will dramatically improve overall return on investment over the life of your application.

In Part 2 of this article I will identify some key technology challenges and how you can overcome them to deliver on the promise of evergreen applications.

With over 500 successful Agile projects under our belt, one of the key learning points we want to share in this edition of About Agility is the concept of the 'Tuning Sprint'.

Over the last several years we have used this concept and found that it dramatically drives end-user adoption of the delivered application. However, there are some fundamental challenges that we will discuss in this article so that you too can be successful.

The 'Tuning Sprint' Defined

The concept of the Tuning Sprint is straight forward and is now part of our formal Agile Method. With each project we now incorporate a post-production sprint that is specifically for the purpose of 'Tuning'. During this sprint we are looking for two distinct types of feedback: usability of the application and performance.

To accomplish the tuning we take the production application and share it with an expanded set of users. In most cases the new application is rolled out on a limited basis to a set of users who will ultimately become trainers and take the application to the rest of the user base. With this set of expanded users we collect feedback in as close to real time as possible, prioritize it and make the necessary changes. In many cases we deliver multiple versions to production in a single day.

The result is that many of the small, nagging usability issues are removed from the application. By addressing these issues on a daily basis during the sprint, the expanded set of end-users become owners of the new application and major proponents of the application's adoption among the full user community.

Simple Concept - Challenging Practices

While the concept of the 'Tuning Sprint' is simple there are a few challenges that your team will have to overcome in order to be successful:

Challenge 1: Ability to collect and prioritize feedback in real-time

Challenge 2: Ability to make changes rapidly

Let's look at each of these issues in more detail and make sure we fully understand what must be overcome in order to be successful.

Challenge 1: Collecting & Prioritizing Feedback in Real Time

While this might sound simple, for many projects this will become a big challenge quickly. First, you need to consider the proximity of your expanded user base. In many cases the users of the application will be in remote locations. Therefore you will need to have some mechanism for collecting feedback in as close to real time as possible. In the worst case you need to collect feedback a couple of times a day from these users.

Once you have the mechanism established for collecting feedback, you then need to be able to review, prioritize and easily hand it over to the development team so they can make the necessary changes. Our experience shows that when done correctly, you will receive a large amount of feedback in the first few days of the tuning sprint. We have found that if you have good tools with which to review the feedback, you will find that many of the usability issues are identified by a majority of the users and this in turn makes prioritization easy. In this case, the more users who complain about a specific issue, the more important it is to fix.

In summary the challenge is to come up with a mechanism that allows you to easily capture the end-users feedback with as little ambiguity as possible, and make it easy to review, group and prioritize into change requests.

Challenge 2: Making Rapid Changes

Of course the mantra of Agile is all about embracing change. However, during a Tuning Sprint we push this to the extreme. To be successful you need to address several potential development and delivery hurdles.

First, you need to make sure that your development environment supports making rapid change in a high quality manner. In most cases these changes are not complex but when you are making the number of changes we see on a daily basis, your tools must provide excellent support for ensuring you don't create more work by breaking something that was working well.

Second, you need to make sure that you have the ability to deliver new production builds multiple times in a single day. For most, this is where quality issues really rear their ugly heads, as builds tend to be complex and error prone.

And third, you must have the operational support to deliver these new production versions in a rapid manner. This typically means that traditional processes must be modified to support the Tuning Sprint and Operations must have the confidence in the builds to move them to production. In addition, a fool proof roll-back capability must exist if something moves to production which causes problems.

We have found that for most of our customers, making the application change is the easy part. The challenge is executing the rapid builds while not compromising quality and getting Operations to allow you to make multiple production releases in one day.

OutSystems Agile Products to the Rescue!

As you might know or have surmised, at OutSystems, we have addressed the challenges associated with the Tuning Sprint.

To overcome the challenge of collecting and prioritizing feedback, we've created the Embedded Change Technology (ECT). This allows end-users to record their feedback directly on the running application in real time. By capturing the actual screen and associated feedback, ambiguity is eliminated.
ECT is complemented by the Agile Network Projects. Agile Network Projects allows you to automatically collect the ECT feedback, easily group similar change requests and prioritize them into new work items for the development team. Once handed to the developer, a single click will open the Agile Platform to the spot where the change is needed.

Overcoming the challenges of making rapid change is also supported by the Agile Platform. Key functionality like our True Change™ engine assures that you don't break something that was already working. Once the change is made, we automatically merge the change and create a new deployment package - and thereby overcome the challenges faced with traditional build mechanisms. Once the build is complete, we offer Operations the ability to easily manage production versions and deploy them with a single click. If there is a problem with the new version, Operations has access to the Agile Platform's One Click Roll-back functionality which makes it easy to revert to a prior version.

By incorporating a Tuning Sprint into your Agile projects we are confident that your end-user adoption will sky rocket and help drive Agile practices across your organization.

What happens when your application software change cycle time shrinks from months to hours or days? Over the past four years, we have overseen the deployment of hundreds of Web business applications all following agile methods. During the course of these projects, we have faced many challenges and found some surprising benefits.

This article describes some of the lessons we have learned and provides advice on how you might overcome some key challenges in your own agile projects.

Introduction

In 2001 when I assembled a team of seasoned Web professionals, we looked back at our frustrated past of trying to release complex Web applications in Extranet and Intranet environments. While we were always able to deliver these projects, the process was painful.

The review of our past performance showed that it was impossible to accurately analyze and document the real business requirements. Following a traditional waterfall method meant that projects were doomed to be late and over budget. We were plagued by changing requirements, unanticipated integration challenges, usability annoyances and ultimately the formidable task of training thousands of users in a short amount of time.

So we decided to look at the problem from a radically different point of view where we embrace and nourish change. Fundamental to this shift were two key project assumptions:

1) Assume that the application scope can never be accurately defined.

2) Let the application scope evolve during the project based on user feedback.

Agile methods align nicely with this approach. When complemented with tools that allowed us to time-compress the change and upgrade processes, we were on our way to dramatically improving our ability to deliver complex Web business applications.

Fast forward to 2008 and 500+ projects later. Today, we have successfully adopted an extreme change mantra where we constantly enhance and re-factor applications as we drive toward meeting the real business requirements.

Agile - A Mantra for Extreme Change

Our mantra of extreme change is well served by agile methods. Over the years we have found that embracing extreme change has helped us meet our project milestones and deliver applications that are aligned with business needs and easily rolled out to large user bases. We have also found that business users actually make pretty good testers and that incorporating them into the process early and often results in a better end product.

On the flip side we have faced several unforeseen challenges. Collecting feedback from end users early and often resulted in a need to find a better way to manage and prioritize the feedback. In particular, help desks and documentation present a big challenge with embracing extreme change and must be addressed up front or you will suffer when you roll-out your application.

Over time, we've developed a tried-and-true Agile approach to help overcome these challenges and continue to work on improving our agile skills and ability to deliver dynamic applications that support extreme change.

Let's look at some of the lessons we have learned.

Listen to Users at Large

Over time, we formalized our mantra of extreme change around an agile method and delivery platform based on Scrum. In the process, we learned how difficult it is to capture timely feedback from a large user base through the help desk and one-to-one conversations.

About two years ago, we started experimenting with embedding feedback functionality in the applications themselves. We added a non-intrusive hovering button to the bottom of every application page that can be clicked to expand into a feedback form. The user points to the relevant area of the page, types the feedback and submits it. The page contents, user name and session information are collected automatically, packaged into a Change Request and, sent to the agile delivery team. The results have been staggering. In one case where an application was launched to 25 users, we collected more than 200 suggestions, bugs and comments in two days. Out of this 200+, 10 were identified as critical by the agile team (IT and the business) and they were implemented in three days. This tuning process skyrocketed adoption of the application and allowed a smooth roll-out for the remaining 1,100 users.

Transform Business Users into Testers

One of the great side benefits of having your users so heavily involved is that they make excellent testers. That is why we make efforts to get more business users participating in the early betas delivered at the end of each sprint. Taking this approach we can spot usability inefficiencies, functional errors and optimize the experience for first time users early in the process. The end result is that final acceptance testing and QA sign-off is simplified because we eliminate the delivery bottle neck.

Prepare for Life after the "Go Live"

Rapidly responding to change is especially valuable in those days after launch where the business users get to use the application and experience the harsh reality of a new way of working. It is important that the project team stay around so they can quickly tune any remaining usability and performance issues. That is why we have restructured our typical project schedule to include a Tuning sprint after the application has been rolled out into production.

The impact on the team is substantial. First, you need to prepare the Product Owners and Business Stakeholders for the influx of post-launch work resulting from business user's first impressions and feedback. This feedback is valuable because it helps increase the usability of the application and decrease the need for a help desk or user manuals. But it requires an extra effort managing a growing backlog, prioritizing features and approving changes.

Secondly, the handover from development teams to maintenance teams needs to happen later on in the application life cycle. Therefore, it is always a good idea to keep the development team in place after the production release to take care of the Tuning sprint.

Manage the Help Desk Challenge

Our extreme change mantra usually extends throughout the life of the application. After the Tuning sprint, the application typically decreases its level of critical change and is then passed over to maintenance teams. Agile maintenance teams keep a steady, continuous release cycle, launching new features every two to four weeks. This short release cycle requires constant retraining of the help desk which is simply not cost effective.

One solution is to release less frequently. In fact, some of our customers have artificially slowed the release cycle for application updates to accommodate the learning curve of the help desk. However, this becomes problematic as the business quickly learns you can now make changes very rapidly as experienced during the Tuning phase of the project. Thus slowing down the release process in maintenance mode requires resetting expectations with the business.

We have found that a better solution--especially effective for Intranet applications--is to spread the help desk function among the business user community. In a specific situation, one of our customers launched a Requisitions Management application to 1,400 employees, most of whom were first time browser users. To distribute the help desk load, they used 45 departmental administrative assistants as first points of contact. The agile delivery and maintenance teams then focused on keeping this smaller number of power users in sync with the new releases.

You might wonder why we did not simply incorporate the help desk team into the delivery process in order to train them all at once. Our experience has taught us to look at the problem in a different way. Because of the large amount of applications supported by this staff, they had no specific domain expertise, and that prohibited them from efficiently participating in the delivery phase.

Dispense with Useless User Manuals

If you think maintaining a help desk is difficult, keeping a standard user manual in sync with a continuously changing application is tougher. Here the best solution has been to embed contextual "Help" into the application itself. This way, changes in the application and in the Help or instructional content are always incremental, keeping everything in sync. We have found that a content management framework embedded within the application simplifies this process of delivering user documentation in sync with each new code base.

In traditional development projects the user documentation task can, and often is, performed fairly independently of the development work. Since in agile projects the scope evolves at each sprint, documentation and development teams must work side by side and contribute to each new release. Expect a substantial impact in your delivery, maintenance and documentation teams as you shift into an agile way of working.

React Fast to Increase User Adoption

Assuming change as part of the software delivery process is crucial to Agile delivery. In addition, we have found that this approach also dramatically increases the adoption of our applications.

Let me give you an example. In a recent project, we had to implement a Web-based invoice approval system that would replace a complex set of manual processes. A particular sub-process involved the final invoice approval by cost center directors. In the manual process, the director's personal assistants (PAs) brought them an explanation of the invoice with an approval form ready for signature.

The new Web invoice approval system involved a "small" re-engineering of the process that assumed a pure self-service model without PA intervention. (Note: all of the cost center directors were part of the steering committee that helped define and approved this innocuous process change.) However, during roll-out we realized that half the directors had shared their passwords with their PAs, so they could do the pre-validation. Suddenly we had administrative assistants with $100,000 approval power.

As you might guess, the capacity to change fast was crucial here. A new PA profile was added to the application, the work flow was changed to include the pre-validation process, and most importantly the PAs provided input on requirements. During the original analysis, the PAs were not even considered as stakeholders.

This change was implemented over a couple of days driving end user adoption and making IT a hero!

During the project postmortem, we met with the consultants responsible for the initial requirements analysis to figure out why they did not foresee this problem. In addition, we wanted to understand why the cost center directors signed off on the process design. We discovered that the directors were embarrassed to state they relied so heavily on their assistants so they approved the process change hoping it would work.

When it comes to predefined business requirements, adopting an extreme change mantra can help you overcome poor requirements, "wishful thinking" and re-engineering challenges. We have dozens of these stories that reinforce the need for continuous change, even after the application has gone into production.

Conclusion

By far, the greatest benefit of pursuing our mantra of extreme change is delivering what the business needs, on time and on budget, both predictably and well. When a company is able to react quickly to unforeseen situations, and overcome them successfully in a rapid manner, there is a direct correlation with user satisfaction--adoption simply increases and IT regains its rightful place, aligned with the business.