<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 March 2014 06:56, Dan Andreescu <span dir="ltr"><<a href="mailto:dandreescu@wikimedia.org" target="_blank">dandreescu@wikimedia.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, Mar 12, 2014 at 4:42 PM, Oliver Keyes <span dir="ltr"><<a href="mailto:okeyes@wikimedia.org" target="_blank">okeyes@wikimedia.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br>




</div><div> </div></div></div></div></blockquote><div><br></div></div><div>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.</div>

</div></div></div></blockquote></div></div></div></div></blockquote><div><br></div></div><div>I think, Arthur, you take too soft of a line here.  When Oliver describes agile as  "a philosophy that dictates putting things we strongly suspect, or even know, to be actively buggy, in front of users", he's just plain wrong.  It's not a potential interpretation of any agile principles that I'm aware of.  I mean, sure, people could interpret capitalism as "kill everyone until you are the lone survivor - Highlander, there can be only one!".  But people ... don't.  And I think it's equally ridiculous to say that agile dictates putting bugs in front of users.  I think, Oliver, it's likely you had some bad experiences with agile *attempts*, including at WMF.  I think this just underscores the importance of training.  So I think it would be constructive if, from this point, we left prejudice about agile at the door and focused on evaluating the merits of this proposal on the values that the agile process tries to foster.  Arthur, perhaps we could start a concise list of this - testing, breaking up large projects into small chunks, iterative improvement not just of the product but of the process and team dynamics, etc.</div>
<div class="">
<div><br></div></div></div></div></div></blockquote><div>Evidently I have. Don't get me wrong, I don't think Agile is necessarily the problem here - I think that the problem is, frankly, overenthusiastic managers and a weirdly concentrated hierarchical process that leads to a situation where, combined with human nature, it's really really easy to ignore the people going 'uh, this is totally an issue, can we please not deploy this?' But, yes, I have had some bad agile experiences, and more importantly, the initial question was "Why do the community not like agile?" This is why the community doesn't like agile - because all of the failures in our development process are all too often externally justified with 'it's Agile!' or 'more eyes make shallow bugs!' or similar meaningless pontificating. And sometimes that is because of agile, and sometimes that's because we don't take the time to go "okay, is this agile itself, or our agile-justified process?", but either way it's externally justified the same way.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><div></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><div>Sure. But if you're an average user, you don't see the development philosophy behind what's changing in the site you rely on 9 times out of 10. When you do, it's because you're on a site that prioritises transparency, like ours. IOW, I wouldn't be shocked to find that most users involved even tangentially in our development processes, as consumers rather than devs, assume that this is just How Agile Works, because most dev teams don't expose their processes.<br>

</div></div></div></div></div></blockquote><div><br></div></div><div>This I agree with.  But I think if we emphasize agile done properly, we can positively impact user perception.  Both by showing progress more frequently and by increasing the quality of the progress.  That's the point of this proposal I think, and if we execute it properly "How Agile Works" will change, because perception follows results not prejudice.</div>

</div></div></div>
</blockquote></div><br>Sure; I'm not saying agile can't be done well, or that this wouldn't help with it. I'm answering the original question, which was about the <i>perception</i> of the agile coaching office. The <i>perception</i> of agile in the community, and their likely reaction to the creation of the agile coaching office or whatever we're calling it in this 
particular 30 second chunk of time, is "badly".<br><br clear="all"><br>-- <br><div dir="ltr">Oliver Keyes<br>Product Analyst<br>Wikimedia Foundation<br></div>
</div></div>