I worked in a group in Microsoft that developed the upgrade to the Microsoft Security Essentials antivirus. For a year we worked on the next version of the product. We had 6 milestones (milestone each two months). Most of the features were developed in the first few milestones, and for the second part of the year these features were refined and bugs were fixed. Each milestone a larger portion of users (subscribed to the various alpha/beta programs) would get the product and provide feedback.
I was told by the program managers in the project that the advantage of this approach is that there is more time for potential users to give feedback on the features, so it is preferable to ship all the features as soon as possible.
However Scrum doesn’t advocate this approach. In Scrum are you advised to deliver completely tested and functional piece of software and not half baked and brittle features. This approach has various benefits, but it also has some drawbacks. One of them is that feedback is delayed.
So which approach do you prefer and why?
2
“In Scrum are you advised to deliver completely tested and functional piece of software and not half baked and brittle features”
You seem to be conflating user feedback – do they like the features that have been delivered, do they find it useful, does it meet a need, does it have arcane bugs when (mis)used in ways the developers didn’t anticipate – with basic performance, stability and functional correctness. Scrum is echoing the agile manifesto claim to value working software, with the emphasis on WORKING in the sense that it does what the product owner asked of you. User feedback is only then valuable in that it aligns the product owner’s vision with the market. If you ship non-working software the user feedback will rather predictably be “WTF?”.
1
It sounds like they main driver for this is requirements.
The user are providing “real life” feature and usability information.
So they get the basic feature out there and make it better by getting input on it, as opposed the get it right first approach which maybe assumes more requirement analysis has been put in up front.
You may be making an argument to over-engineer this project based on your comments to Julia Hayward’s answer. (I think a lot of this should be in the question.).
Well, when I said “ship” I meant ship to alpha/beta users or not even
ship at all but simply deliver the software for usability tests.
In this case, it seems like your program manager is more the product owner and he is allowed to accept half-baked features.
So yes, it will be only partially functional, not pretty, with some
bugs, but at least an important feedback can be generated so the team
will know if its in the right direction.
So now you can take that half-baked “Feature A” and turn it into another request that requires: input checking, error testing, use the new GUI design, etc.
When you go through this alpha/beta route, it’s not your code that is half-baked, it’s the user stories. Only fulfill the user story so it passes the project owner’s approval.
2