OutSystems BlogDev Zone

The Tuning Sprint – Driving Application Adoption Using Agile Methods

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.

About the author

Paulo Rosado

Paulo has led OutSystems from initial startup to international leader in cutting-edge approaches to delivering enterprise web and mobile applications. Besides his day job as CEO, he occasionally helps entrepreneurs grow their businesses and avoid obvious mistakes.

Comments

Salim

This sounds interesting – how easy/hard was it to implement the tuning sprint idea with the companies you’ve worked with? Any tips on rollout & adoption? Thanks!

Michel

Salim, you should include the tuning sprint in your methodology, in a way that you present it to the customer as part of the agile process. In many situations, customers are not 100% familiar with the agile methodology, so you will need to educate them on how it works. In this case it’s relatively easy to explain that they need a tuning sprint and the benefits they’ll get from it.
For applications that are used by a large number of users, the tuning sprint makes even more sense: as you roll-out the app to a larger group of people, you’ll receive a lot of feedback on how they actually want to use it, and the tuning spring ensures you have the time to implement the necessary changes to ensure adoption.
If the group of users is really large, then you might consider some sort of phased roll-out, and eventually plan for some additional tuning sprints. You can look at these sprints as smaller version releases of the final application. At the end of each sprint you’ll have an app that includes the feedback gathered from the new user group.
Hope this helps!

Paulo Rosado

Hi Salim,
a couple of caveats:
1. The tuning sprint done right generates a tremendous amount of feedback. You should select the 20 top changes that increase user adoption (usually usability or performance enhancements) and focus on those.
2. You need to make sure that your development, staging and deployment infrastructures allows for you to make changes fast and robustly. We rely a lot on the Agile Platform to be able to support many production upgrades in the 2 weeks that take the tuning sprint.
Hope this helps,
Paulo Rosado

Leave Your Comment