Agile: A Mantra for Extreme Change Fuels Successful User Driven Applications
|
 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:
-
Assume
that the application scope can never be accurately defined.
-
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 R&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.
|
