Friday, November 20, 2009

Why open-source project management tools do not flourish?

Unlike other open source tools, the open-source project management (PM) tools are miles behind from their commercial counter parts. I have always wondered why? Most of the projects have very low development activity, if at all. Did you wonder why too? Recently, I attended a DC Scrum user group meeting where we were discussing why we chose the tools that we are using to manage our Agile projects. Suddenly, I had this "aha" moment.

If we think about it for a moment, we will realize that we all have different ideas as to what to expect from a PM tool. We all know what some of the core features should be, but we most likely would disagree on how to go about implementing them. These differences are not technical in nature. We can be very opinionated about the details of these requirements. It is like choosing what to ware. As a result, most project management tools embody the view of the development team, the product owner to be specific. As a user, we choose the one that most closely matches our view of the world. Even if we somewhat like one, we would move on to something else and would not have the patience to wait for the tool to catch up to our taste. We act like we have ADD when it is about choosing a PM tool.

Since these open-source projects do not have a passionate product owner, there is no single ownership of a cohesive view to pursue. As a result, a developer will start working on implementing one because he has this unique idea about what this PM tool should look like, but will find it difficult to have other developers to agree with that view. Worse, he will find it even more difficult to find users who will like his view and support his effort by actively using the tool. Heck, even the developers would not use their own tool to manage their project. We know an open-source project would need an active user base to sustain and flourish.

The only way to have a project management tool to survive is a team's persistence with the tool in the early stage of the development. This is only possible in the commercial world. Each of these companies are pursuing their unique vison of what a PM tool should be in the hope that there is a large enough user base (who subscribes to this vision) to sustain their development. Thanks to all these companies sticking to their guns irrespective of the diverse nature of a very discerning users group (that is us).

Wednesday, November 11, 2009

Should fixing bugs contribute to a team's velocity?

I get this questions often. I am sure you probably also got this question at one time or the other. There are two ways to look at this- value vs. cost. These perspectives are linked to how you define velocity. Let's look at both in more details.

Value perspective. If you define velocity as the net value (in story points) delivered to your customer, then you should not include bugs in your calculation of velocity. Think about it for a moment. Bugs are something that are not working as expected, but the customer has already paid for them. So, by fixing bugs you are not really delivering any "incremental value" to the customer. If you increase your velocity by including bugs, you are inflating your velocity. Now, granted that sometimes we report something as a bug when it is an incremental feature. You need to work with your product owner to negotiate to change those bugs into stories and account your effort for them in your velocity.

Cost perspective.
If you define your velocity as the amount of work done by a team in a sprint, then you should include bugs in calculating velocity. Yes, bugs take effort and time to fix. Hence there is a cost associated with fixing bugs. But this makes the release planning a little bit complicated. Because you cannot know ahead of time how many bugs you may have until the release. Directly using velocity to calculate the effort or to determine the time-line for the release will most likely be off (undershoot). One way to address this is to break the velocity into two components- feature-delivery velocity, and bug-fix velocity. This is in a way going back to the first option.

I personally am in favor of using "value" perspective and exclude bugs from calculating velocity. This helps keep our eyes on the ball- delivering "customer value." As a result, we are encouraged to reduce bugs in the first place so that we can free up our capacity to deliver more value. That is why we currently do not allow users to point estimate bugs in ScrumPad.

Are you including your effort spent on bug fixing in your velocity?