<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 7:35 PM, Erik Moeller <span dir="ltr"><<a href="mailto:erik@wikimedia.org" target="_blank">erik@wikimedia.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="overflow:hidden">Going back to the original topic of this thread - extending Bugzilla<br>



for PM - the <a href="http://scrumbu.gs" target="_blank">scrumbu.gs</a> developer has helpfully given me some good<br>
feedback from their experience. I've invited him and other folks at<br>
Mozilla to join the conversation here if they're interested, but to<br>
recap:<br>
<br>
1) Instead of Scrum, some teams at Mozilla use Kanban (less focus on<br>
velocity, roles, rituals; more focus on just tracking ongoing work and<br>
limiting work-in-progress). This is more comparable to the lightweight<br>
workflow that e.g. the Mobile App teams and Growth teams at WMF are<br>
currently using, though I'm not sure we've ever formally implemented<br>
some aspects of Kanban on these teams like WIP limits and lead time<br>
estimation - perhaps Steven or Tomasz can speak to that. My take is<br>
that  Kanban is good for small teams and Scrum's benefits kick in on<br>
larger, more complex projects.<br>
<br>
Kanban is the kind of workflow that a tool like Trello is good for;<br>
Mozilla likes Kanbanery (proprietary) and wrote a Firefox extension to<br>
tie it into Bugzilla:<br>
<a href="https://addons.mozilla.org/en-US/firefox/addon/kanbugger/" target="_blank">https://addons.mozilla.org/en-US/firefox/addon/kanbugger/</a><br>
<br>
2) There's an intern project called Kanbanzilla that looks more like a<br>
full-on Kanban board integrated with Bugzilla. I've asked if there's a<br>
live setup somewhere, but here's the code if anyone wants to poke at<br>
it:<br>
<br>
<a href="https://github.com/mozilla/kanbanzilla" target="_blank">https://github.com/mozilla/kanbanzilla</a></div></blockquote></div><br>Yes, Trello is a Kanban board. The default lists are To Do, Doing, and Done for this reason. In Growth, we move cards through a pipeline of design--engineering--testing--deployed--analysis--reporting. These buckets are an artifact of our focus on A/B testing. </div>


<div class="gmail_extra"><br></div><div class="gmail_extra">We don't do WIP limits and lead time estimation. Just like Scrum has odd artifacts and missing elements because it's a reaction to waterfall enterprise development, Kanban has weird artifacts in it because it was invented for manufacturing. Lead time estimation is one of these I think. WIP limits are a great idea, but in general I think Scrum's focus on burndown is more in line with the fact that in software, estimation of time to complete is probably the most difficult task there is. </div>


<div class="gmail_extra"><br></div><div class="gmail_extra">We also have avoided doing most of the Scrum meetings like backlog grooming, sprint review, showcases, and retrospectives. For a team our size, that's just too much. We simply do standups and we just started doing sprint planning meetings (we're in our second sprint now).</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">This is kind of me trolling, but I would guess that once MediaWiki changes to continuous deployment rather than scheduled weekly windows, Scrum's emphasis on time-boxed sprints formed by planning meetings will feel increasingly artificial and "un-agile". <br clear="all">


<div><br></div>-- <br><div dir="ltr"><div><div><div>Steven Walling,</div><div>Product Manager</div><div><a href="https://wikimediafoundation.org/" target="_blank">https://wikimediafoundation.org/</a></div></div></div></div>



</div></div>