Posts

Showing posts with the label Project Management

Agile Project Management Tools are doing it wrong

Introduction I have noticed many bug tracking products attempting to add "Agile" project management to their offerings. I use the word "attempting" because I have yet to use one that really works. I also find it frustrating that many of these same products are setting aside useful features (like case commenting permissions in  FogBugz ) and enhancements in favor of failed attempts at making an agile PM tool. Here I'll try to outline, as I see them, the problems faced in trying to make an AGILE PM TOOL. Users Believe that they want an online Card Board (or kanban) Unfortunately, most of us have believed for a long time that a nice  Trello  style online board would be perfect for managing an Agile Project. So far, IMHO, none of the tools have gotten this right AND I doubt they ever will. The great thing about a card board or board full of sticky notes is that you can grab the card, pass it around, set them out on a table, return them to board or put them on ...

Ridding Your Garden of Bugs: Gardening the Backlog

Image
I'm not sure if I agree with this " article " but, it is somewhat related to a discussion my boss (Dr. Rob Miller) and I were having earlier today. Ideally, we would like to focus every third (I just picked a number) release on "bug hunting" or finding and fixing bugs. Unfortunately, bugs are often a debt we live with for a long time, in the face of progress and new features. I have known few products that didn't have some glitch and the promise of new features often takes some of the edge off of these glitches. Conversely, some bugs can leave users with such a bad taste that they never quite trust your software again. In the article above the author describes a bug that was reported fixed but still remains broken....after 2 years. Furthermore, as more bugs slip through the cracks a system can slowly become more and more unstable. This suggests that, when planning product releases, stakeholders should balance the need for new features with the need for a sta...

New Pattern: CPT (Can't Polish a Turd)

I recently read a hilarious article, " Asshole Driven Development ." The author, Scott Berkun, takes a cynical look at the abundance of acronyms in the software engineering field. Along the way he uncovers a few insights that, while very cynical, ring true. In addition to Scott's funny acronyms many users have added additional goodness. One anonymous post read: How about CPT (Can’t Polish a Turd) development, This is where management cannot understand the need to stop and fix/clean up/refactor or start again. I saw this post and wondered if we hadn't worked together! I've polished many turds in my time, a few were my own, and let me tell you...it's not easy. The fact is, these turds never really shine. Sure, sure...wet em down a bit...put em in the right light and they seem to shine. Heck...we have well paid people (some brilliant) that spend most of their time putting turds, in the right light. But, in the end a turd by any other name is still crap. So why ...