Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as primarily opinion-based by gnat, GlenH7, MichaelT, Martijn Pieters, Kilian Foth Feb 18 at 8:56

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
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 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. –  Carson63000 Feb 15 at 7:04

3 Answers 3

"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?".

share|improve this answer
    
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 at 11:53

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.

share|improve this answer

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.

share|improve this answer
    
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 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 at 19:13

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