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

[Maryana Pinchuk]

I think one thing we should be mindful of in discussions like this is that there's a big difference between task tracking and product/project management broadly writ. I've used a variety of task tracking tools, most recently Mingle, but none of them have actually been all that useful for conceptualizing how a suite of features could work together, planning releases holistically, or mapping out alternate routes/roads not taken/escape plans for when something might not be successful -- that kind of thinking just doesn't lend itself well to tidy columns of atomic tickets :)

I think when we conflate these two things (task tracking and product management) we run the risk of letting the tool set too rigid a boundary around how we think about our work. While I can totally see how tools like Mingle are useful and appealing to an engineer brain for making everything into the aforementioned tidy column of tickets, the reality is always going to be much more dynamic, fluid, and multidimensional, and often better represented more abstractly -- in sketches on a whiteboard, or prose paragraphs, or even slightly douchey VC-esque vision statements ;) If we let Mingle (or any other tool) trick us into thinking of a product backlog as a static, atomic set of elements that we can only perform certain simple operations on (add, remove, reorder) we're needlessly limiting our creativity.

Anyway, tl;dr, we can and should search for better tools to track work on features and bugs, and adapt the ones we have for optimal use in all our different features teams. But let's not forget that sometimes the best tool for the job is good old fashioned human brainstorming -- something that AFAIK has not yet successfully been turned into software!

> On Oct 30, 2013, at 7:22 AM, Chris McMahon <cmcmahon at wikimedia.org> wrote:
> 
> 
> 
> 
>> On Wed, Oct 30, 2013 at 8:02 AM, Toby Negrin <tnegrin at wikimedia.org> wrote:
>> 
>> Yahoo's bugzilla instance was heavily patched so even if the source code was available, it probably wouldn't work with out of the box bugzilla but it definitely proves the concept.
>  
> I've used most of the Agile PM tools out there, (Jira + GreenHopper anyone?), and the more easy it is to tweak the workflow within the tool, the more successful teams tend to be with the tools.  All these similar tools should offer this wide configurability, but as Steven noted, some are more expensive to tweak than others.
> 
> This makes sense given the Agile values of "responding to change" and "regular adaptation" [1], and it is a logical consequence of effective retrospective:  you have to be able to adapt the way you work to the circumstances under which you would like to work.  If your PM tool won't let you do that, then it is the wrong tool.  
> 
> -C 
> [1] https://en.wikipedia.org/wiki/Agile_software_development
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131030/21c4983e/attachment.html>