I love agile. I cannot imagine getting software done in a traditional waterfront/BUFD way ever again.
Each sprint or iteration is kind of like making camp at the end of the day as you climb a mountain. However, the mountain does not go on forever (although it probably feels that way). You have to reach the summit one day and declare victory (then move on to another mountain - once you descend, recover and replenish supplies of course).
With agile you end up with a ton of releases accumulating - 1 for the end of each sprint. During the sprints, we pile features and fixes and we pray the documentation and QA can keep up with the pace. These releases are not really intended for external consumption. However, sometimes they may find their way into customers hands. This could happen from time to time.
However, let's consider the scenario where you had reached 8 sprints after a period of ~8 months (assuming 4 week sprints). You now have accumulated 8 releases in your wake. If each of those 8 releases have found their way into different customers hands, you are obliged to support that release. This means you have to consider 8 different upgrade scenarios. You also have to consider 8 x n different compatibility tests where n is the number of components in the product. This becomes un-manageable.
What is the solution? The answer is you have to bake into your release cycle a GA release. How many sprints maketh a GA release? It depends. How often should you do a GA release? It depends. The GA release is where you finally say - yes, we've reached the summit. It's time to put this effort to rest. Time to move on to the next mountain.
Are there any special considerations for the GA release? Yes. The emphasis for the GA release should be all about quality. Often, during the sprint the QA effort is most likely going to be focussed on functional testing. For a GA release, there is so much more testing that needs to be performed.
The GA release is about slowing down the pace of change and allowing the product to bake.
2 comments:
"With agile you end up with a ton of releases accumulating - 1 for the end of each sprint. During the sprints, we pile features and fixes and we pray the documentation and QA can keep up with the pace."
This means that you're not "done done" with a feature at the end of a sprint. "QA sprints" suggest your back in the design/implement/test world and most people's interpretation of waterfall. You should try to alter the amount of development work in each sprint and possiblky the sprint length so that at the end of each sprint you have working, fully tested and documented features for users.
http://www.ademiller.com/tech/
Ade
We do things a little differently on our projects. We don't combine development and QA into the same sprint release. At the end of the sprint, we pass the release over to QA. So, if development are actively focussing on N, then QA are actively testing N-1 (whic leaves the architect to focus on N+1/2/3.
Post a Comment