Ron Jeffries presented at the St. Louis XP User's group meeting back in January. As he put it, the topic of the presentation was anything that came to his mind at the moment. He simply stood at the front of a crowded room and talked while drawing on an overhead projector.
I won't try to transcribe the entire meeting, but there was one statement that has stuck with me that I wanted to share.
"Smaller Releases Help Management"
Ron spent a lot of time on this subject. When he first said it I though "of course that is obvious". As he continued, he brought out finer points that I hadn't considered as much.
At the beginning of a project customers are going to ask for as much as they can get. It is a natural reaction to the belief that software is hard and releases always take longer than they should. It's somewhat circular, but if you believe that you aren't going to get your release for a long time, it better have everything and the kitchen sink in it.
Once a release becomes too big, everything is affected negatively. Product doesn't get into customers hands, so no value is derived. Management gets upset because they don't have anything to manage. Developers stress because there is so much to do and an unlikely deadline to meet. The implementation itself doesn't get appropriate feedback and starts to wither on the vine.
Think of all the things that free up when a release is broken down:
- High value stories can be put into customer's hands earlier. It's not everything you want in your larger release, but you can get value to your company now.
- It gives your customers/product managers something to manage.
- Maybe we learn that the first or second release is sufficient and the remaining stories can be dropped for a new project.
- Maybe we learn that the effort is taking longer than expected. We can use the release we have, but set expectations accordingly.
- Maybe we learn that resources should be reallocated between releases to deal with changing priorities
- Developers get constant feedback that their code is working and a sense of completion much earlier
As I said, at first blush the fact that smaller releases are better is no real surprise. The real take away is the effect of smaller releases on the management team. With more releases come more choices and more feedback. Developers always want to know their choices and feedback, don't be surprised that your managers want them as well.
Your best technique to provide choices and feedback is a smaller release.
