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 another board very easily. All of this while having a full visceral interaction with the rest of the team.
The electronic card boards fail to allow uninhibited control of the cards. You have to click then drag a card somewhere AND unless you have a huge (45+ inches) touch screen monitor many of your cards end up falling off the screen or are unreadable. We always do our planning using physical cards. Even though the tool we use (FogBugz) has a so-called Agile Planner built in. It's just to unwieldy to use BUT we keep telling these companies that this board is what we want.

Suggestion #1: Stop trying to create online card boards and focus on managing the backlog (see below) or workflows (see below). When we ask for the card boards we really don't know what we're asking for.

Agile Projects all follow different workflows

Agile teams rarely have the same exact workflow. The workflows differ from team to team for good reasons. Differing product schedules, team size, organizational demands, etc. The tools that try to prescribe a single workflow, do so at the loss of potential market share. The tools that have a super flexible workflow editor don't always go far enough or it becomes difficult to see what the workflow really looks like. The tools that try to have a one size fits all approach tend to be berated for not really meeting anyone's needs.

Suggestion #2: Workflow is one place I think these tools can make big differences. If you are going to have a workflow editor then it needs to be robust enough to allow good workflows to be described. Managing the workflows is the absolute best use of these tools. It allows developers and users to easily move cases along the pipeline that your team has described. It does suggest "kanban" but as mentioned above it doesn't need to be visually like kanban, just conceptually. It's really just a pipeline approach.

The BACKLOG is what really needs to be managed

Some backlogs have tens of thousands of user stories in them. Managing that backlog effectively and allowing product owners to more easily garden is a missed opportunity in most of these tools. Once again no visual representation of cards is going to help here. It's too cumbersome and time consuming. The ability search and order stories in a backlog based on factors such as priority, area and cost are very important BUT also being able to tie these stories to epics on a road-map is even more important.

Suggestion #3: My backlog order rarely drives the priority of work. We follow a constantly changing road-map of EPICs based on current business needs. Being able to associate stories with Epics and then to a product road-map AND have that automatically fix the backlog order would be THE KILLER FEATURE! Being able to bring up a road-map of EPICS that I can modify then have the backlog automatically changed would be amazing.

Story Points versus Man Hours

Fogbugz just recently added story points as a second class citizen but still has no good burn down chart capability that uses story points. Most tools do have a burn down but the problem we always face is that some teams use hours while others prefer story points. To further compound this is how and when do you receive story points (or hours) for a story or task? Some teams allocate points once the developer has completed the work, other teams only allocate once a QA review has been done and still other teams use completely different methods. 

Suggestion #4: This is a point I am less confident about. My gut says this capability can be fleshed out if attention is given to it (see suggestion 1). This may be a matter of allowing point allocation to be defined as part of the workflow. I believe that would work but once again the workflow editor must give a solid representation of how that workflow will be enforced.

Final Thoughts

At the end of the day my preference is for a basic issue tracker that allows me to stay in continuity with our end users and allocate engineers/QA to stories. We've used the FogBugz API extensively to build our own burn downs and other information radiators. For us having the programmatic access to our stories is of greatest importance, along with the added workflow capabilities. Enhancements in the areas mentioned above would be of most value to us.

Ridding Your Garden of Bugs: Gardening the Backlog

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 stable system. I believe that, by better "gardening" a product's backlog, most products can avoid these pitfalls. So, here are a few points to consider when gardening your backlogs:

• Are stakeholders keeping and gardening personal backlogs? When I say, "personal backlog" I am referring to the features, enhancement and bugs that each stakeholder or program manager would like to see implemented. At every release planning meeting these "personal backlogs" should be gardened and brought to the table for consideration in the "product backlog".
  
• What have users been promised (explicitly or implicitly) and what is the impact of leaving those promises unfulfilled?
• Do you know how "real" users feel about your software? How do you collect this information? Sometimes, we get ONE very vocal user (see above). Sometimes we have a quiet majority. When should a user's/client's opinions impact the requirements for a release?
• When is a "bug hunting" expedition called for? Is there some threshold or event horizon? Do we have a good litmus test?
• Finally, is there a single decision maker (the one ringable neck) for the product backlog? Someone to take all of the personal backlogs and prioritize them. In XP this would be the On Site Customer and in SCRUM this would be the Product Owner. I suggest that it NEVER be your development team. This person maintains the backlog, the vision and the roadmap.
  

 It's not likely that you will squash all the bugs in any non-trivial system without writing some questionable code. So, you should take the time to test drive your software. Also, watch others "test drive" your software. This advice is not just for developers. In fact it's doubly important for non-developer stake holders and Decision Makers to "test-drive" the software. Kick the tires, check all the instruments. How's the suspension? Is it idling rough? Take it to a mechanic (engineer) and see if any maintenance is due (technology debt). Next time you prioritize your backlog you may have a different perspective.

Taking the time to garden your backlog will leave you smelling like roses. While just letting things grow out of control could have you digging in the weeds!

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 all this infatuation, with turds? In my experience it can be broken down into several very bad reasons:

• Turd Love Affairs: This turd was once your next big thing. It would solve all the world's problems and make the company tons of cash. Somewhere along the line it got off track for various reasons (see the above article) and no one wants to admit it. These love affairs can be identified by an organization's death march development of a product that almost no one likes.
  
• WSIA (We Sold It Already): WSIA is a surprisingly common problem. It's in the field and someone has paid for it. Because it's a turd it takes all your manpower to constantly tweak and thus no developers are available to work on a new version or refactor the old turd. Companies with this problem are usually immature and don't adequately plan for the software's lifecycle. (BTW: XP solves this problem since it assumes the software is never done)
• Management Mistrusts the Engineers: I imagine them sitting around in a smoky room saying, "well those stupid nerds are whining about the XYZ again. Tell them we'll start on the new version in a month...that'll shut them up." Of course that month becomes 3 then 6 then the project is scrapped or the company goes out of business. "What!? no one wanted to buy a shiny new turd?!"

So, what can we do when we find ourselves in this situation? The first thing I always advise when someone feels workplace dissonance is to step back and remember, "everyone in the organization is probably doing what they think is the best thing for the product." This is important because we have to know that our peers and those above us are trying to make the project successful. People aren't always going to agree on the best plan of action.

The first thing you should do is try to understand why the organization is doing what it does....polishing turds. In most cases you just need to look at the project from another person's perspective. How long have they been working on this project? How emotionally attached are they? What fears do they have of losing customers? Once you understand the reasons for polishing turds you can begin to form arguments that support your course of action.

Finally, most turds started out as great ideas. Many of them can be fixed or re-written. Look for that original, good idea. In this way the true brilliance of the original great idea can shine through!

You can probably think of more reasons companies shine there crap...feel free to post a comment.