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.
There's a lot of blogging about agile estimating and planning but most, if not all, that I've come across only pertain to after the project has been started. Further, what is being estimated and planned is for the iterations. So how does one define budget for the agile project itself, specifically a web business application project? I mean, the cost of the hardware, 3rd party software, facilities, etc. everything except the actual software development cost can be fairly straight forward to budget. 
As promised, the customer, partner and OutSystems 