On Wed, Mar 12, 2014 at 4:42 PM, Oliver Keyes <[email protected]> wrote: > > The objection is pretty self-explanatory; agile is a philosophy that > dictates putting things we strongly suspect, or even know, to be actively > buggy, in front of users. When doing so includes replacing or superseding > core functionality and either forcing or strongly suggesting that users > should use the buggy replacement, users get, ah, pissed. Users like things > that work, and when you replace something that works with something that > doesn't while insisting it'll totally be more usable at some undefined > point in the future we can't pin down because we don't actually know in > detail what we'll be doing more than 2 weeks in advance, they start to > wonder very loudly at our competence. > >
I understand your description of the objection and that some users are intolerant of the degree to which we break things. However, I think this is a mischaracterization of agile philosophy, or at least is an interpretation of the agile manifesto [1]/agile principles [2] that I don't agree with. It is still possible to create thoroughly tested/QA'd software with minimal bugs and do it while embracing an agile mindset. I think that we as an engineering organization place a higher priority on getting experiments and features in front of our users than we do on polish, but that is not because to do so is necessarily agile. Still, I would like to know where the conversation is happening more broadly in the community so I can better understand it and engage in it. [1] http://agilemanifesto.org/ [2] http://agilemanifesto.org/principles.html -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
