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 <[email protected]> wrote: > > > > >> On Wed, Oct 30, 2013 at 8:02 AM, Toby Negrin <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/teampractices
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
