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 400+ projects later. Today, we have successfully adopted an extreme change mantra where we constantly enhance and refactor 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 rollout 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 signoff 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" reengineering 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 rollout 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 workflow 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 post mortem, 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 pre-defined business requirements, adopting an extreme change mantra can help you overcome poor requirements, "wishful thinking" and reengineering 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.

---

About the Author

Paulo Rosado is a founder of OutSystems and has been its CEO since 2001. During his tenure at OutSystems he has played a key role in helping pioneer cutting edge approaches to Agile methods using a combination of near shore and off shore resources focused on the delivery of web business applications. With over 500 Agile projects successfully delivered across an array of industries including Telecommunications, Finance, Insurance, Manufacturing, Retail and Biotech Mr. Rosado has become an expert in Agile processes and the organizational changes required to successfully embrace Agile delivery methods. At OutSystems Paulo plays a key role in the companies Ramp;D efforts around using technology to optimize processes for delivering enterprise applications using Agile methods. Paulo has participated in multiple Executive Education programs, and holds a Master's in Computer Science from Stanford University and a Computer Engineering degree from Universidade Nova, Lisbon.