For the uninitiated Release Early, Release Often (RERO anyone?) is the technique of getting what you are building into your clients hands as early as possible. If this means that all you have is a screen that allows the user to login then give it to them and listen to their feedback. The advantages to this technique are just amazing and the results for me have been, what I would consider a 100% success rate.
The tightening of the feedback loop is the real advantage here. For starters the user can give you feedback on something quickly. If you need to make a change to something the user does not like then the problem and knowledge is still in your head so it is easier and faster to work on that portion of the code. You will also quickly know if you misinterpreted something and are going down the wrong path which allows you to fix these issues with minimal time loss.
Failure is no longer a possibility. By having everyone involved (especially the user), you prevent misinterpretation and keep a good focus on the goals. There is only ever a finite amount of time to complete a project and by releasing features clients want and need first and foremost the only things left when you run out of time are just “nice to have” features. The only way that I can see a project failing with this is if the user(s) do not want to be involved or else someone is trying to sabotage the project.
Granted, if you don’t have enough resources/time to complete the “need to have” features is possible but by releasing early and often you will be able to spot that this will be an issue in advance and be able to work on a mitigation strategy before you run out of time/money. These strategies will vary from project to project but will be either extend timeline, add more resources, or drop features (of a combination of any one of these elements).
An unexpected side-effect I found was the increase in quality. By having to release a feature that works 100% all the time for the user to see makes the team really focus on having something done right instead of done mostly right and fixed later. Also if the user spots bugs they are usually easier to fix and implemented in the next release (if not sooner). This results in a small bug count when you issue your final release which has usually ends up with only a small amount of time dedicated to fixes once the application is put into full use (and usually those fixes are for the last set of features you implemented before the final release). Another nice effect is that by deploying the application repeatedly allows you to spot and overcome deployment issues in small steps which makes the final release something that should be a nice and refined process.
An expected side effect was that scope would change. This happens on every project I have ever done. It is a fact of development. What I did not expect was how RERO has made scope change better. I have had users totally drop features as they did not realize that they could do a task in a simpler way by modifying an existing task/screen. This can work the other way in that the user sees more possibilities and wants more items added. Scope is something that should be embraced and not limited I feel. If a user wants more features added then we re-prioritize the features and deliver what the user NEEDS and not what some document written 2 years ago says we need. Depending on your project though, everyone will need to be aware of the consequences of adding/changing/removing features are.
A couple of other nice side effects were the training/learning curve of the application was reduced and there was less debating. Users require less training of a system that they have learned to use 1-2 new features at a time instead of having to learn a whole new system suddenly. We also have fewer fights about “I said I wanted X a year ago and you delivered Y”. If the item is discussed and then released more people are aware of conversations, decisions, and optional items. This reduces the infighting and debating on projects immensely.
Now that I have touted all the good things about Release Early, Release Often there are some things to watch out for.
If you don’t have a good user who wants to be involved then this does not work as well. Many users I have worked with feel that they should throw something over the wall to the developers and everything will come out sunshine and rainbows. We all know this does not work. Keeping the user involved helps to an amazing degree. Also I always prefer to have the real user involved instead of a proxy as this leaves no room for misinterpretation.
Be careful with releasing a mockup of how something will work to the users. Most of the time they will think that it is complete and it is hard to explain to the user that it looks like a duck but is really just implements IDuck and the concretion underneath it is not implemented.
Developers want to make the best software they can that keeps the user happy. Sometimes this works in that the user says “this would be nice to have here” and the developer runs off and does it. This can lead to something that is not essential being done that is outside of the scope instead of something critical being done inside of scope. For this I find meeting about what will/will not be done for the next release to be a good way to manage this.