It's great that Agile delivers some "done" - potentially shippable - functionality at the end of each Sprint, but it's important to remember that the true impact and best feedback will come when end users actually start interacting with the application you've developed.
For this reason, it's essential to keep your release cycles short and feedback loops tight.
Consider two scenarios:
Scenario 1: A product owner has worked extremely hard writing many detailed use cases. These use cases capture how she believes people will use the system. She hands off her requirements to a team who delivers on this vision through six months worth of Sprints. It's not until the big bang production roll out at the end of the six months, that the team has the opportunity to get feedback from real end users and discover that they've built many features people do not want and are missing several critical ones that people need! At this point, however, the project budget has been used up and estimates to go back and make changes are quite large.
Scenario 2: Now imagine that same product owner begins with similar assumptions about user needs, but works with the team to determine the small portion of functionality that will be most valuable to users immediately. The product owner still plans to implement more features after the initial set, but the team develops for just 8 weeks before releasing to production. Within days they receive feedback from real users which reveals that many of the assumptions they made about how users would interact with the system are not valid. However, since they only developed for 8 weeks, it's relatively easy and affordable for them to make changes and incorporate the new knowledge gained into their plans for the next release.
In scenario 2, the release cycle was kept short (at only 8 weeks), speeding up feedback. Whereas, in scenario 1 it was quite long (6 months), significantly slowing down the capture of end user feedback.
While it's common to bundle several Sprints together to form a release that will provide users with enough functionality, the key is to keep the release cycle as short as possible.
3 Tips to Keep Release Cycles Short
1. Identify your MVP (Minimum Viable Product)
- What's just enough functionality to provide some initial value to a user?
- Remember, this doesn't have to be thefinal solution! You can keep layering on additional features in subsequent releases, but now you'll be able to incorporate direct end user feedback from the first release!
2. Automation (Test & Deployment)
- Reduce the overhead required for manual testing each Sprint and Release by automating testing using FitNesse for Appian
- Reduce deployment time and costs by utilizing the Deployment Automation Manager
3. Consider a Pilot
- When an early full production deployment isn't possible, consider releasing to a pilot group to get additional feedback
Remember, the true impact and best feedback will come after your app is deployed to production, so keep release cycles short to ensure speedy delivery of value with Appian!
-Julie Wyman
Agile Coach, Appian
