0

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
  • recommended reading: Gorilla vs Shark -- "if you... don’t want your question to get instantly closed... — try to keep Gorilla vs. Shark in mind."
    – gnat
    Feb 14 '14 at 11:28
  • Developing software for the general public doesn't necessarily call for the same approach as developing software for a specific client or set of users. Feb 15 '14 at 7:04
5

"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
  • 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. 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.
    – Eugene
    Feb 14 '14 at 11:53
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.

1

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
  • Yes, but the question is should the stories be half-baked or not. Clearly both options have their own advantages and drawbacks.
    – Eugene
    Feb 14 '14 at 16:03
  • @Eugene I think you need to describe better what you mean by half-baked. Just because you go back to a story later does not mean it was half-baked - it means you have a new story involving changing/fixing the feature.
    – Izkata
    Feb 14 '14 at 19:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.