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