[teampractices] Scrum-y tools based on BZ (was Re: Scrumbu.gs)

[Steven Walling]

On Tue, Nov 5, 2013 at 7:35 PM, Erik Moeller <erik at wikimedia.org> wrote:

> Going back to the original topic of this thread - extending Bugzilla
> for PM - the scrumbu.gs developer has helpfully given me some good
> feedback from their experience. I've invited him and other folks at
> Mozilla to join the conversation here if they're interested, but to
> recap:
>
> 1) Instead of Scrum, some teams at Mozilla use Kanban (less focus on
> velocity, roles, rituals; more focus on just tracking ongoing work and
> limiting work-in-progress). This is more comparable to the lightweight
> workflow that e.g. the Mobile App teams and Growth teams at WMF are
> currently using, though I'm not sure we've ever formally implemented
> some aspects of Kanban on these teams like WIP limits and lead time
> estimation - perhaps Steven or Tomasz can speak to that. My take is
> that  Kanban is good for small teams and Scrum's benefits kick in on
> larger, more complex projects.
>
> Kanban is the kind of workflow that a tool like Trello is good for;
> Mozilla likes Kanbanery (proprietary) and wrote a Firefox extension to
> tie it into Bugzilla:
> https://addons.mozilla.org/en-US/firefox/addon/kanbugger/
>
> 2) There's an intern project called Kanbanzilla that looks more like a
> full-on Kanban board integrated with Bugzilla. I've asked if there's a
> live setup somewhere, but here's the code if anyone wants to poke at
> it:
>
> https://github.com/mozilla/kanbanzilla
>

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.

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.

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).

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

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131105/24a48b46/attachment-0001.html>