Agile Project Management Tools Evaluation

Project management, configuration management, release management, change management, et cetera, are all areas of interest which need tool support. Without such a tool, the area of management would be simply non-existing. I have seem many instances of organizations which assume to have good management practices, all document, email, ms-project based. When I challenged them to do one simple traceability from one requirement to its changes, they either take some good amount of time, or they fail to answer.

Sometime ago, I did an extensive research on the net to look for good open source tools which does the job. Every tool I gone through, I did installed it, experimented with it, and looked deep in its features. I had limited my research to tools which fulfills these criteria (so you may find many other tools not included in this comparison, so most probably they do not fulfill one or more criteria below):

• The tool is open-source (not even share-ware)
• The tool has an active development team, which is committed to continue support the tool.

Here is a word document which lists the results of the research. Please note that information is this report is not updated, and will not be updated. So, I recommend that you continue your own research because you may come across a new tool which I might not come across.

Hope this effort helps you in your new projects.

Subversion folder structure

One problem I faced is how to organize the svn folder structure, so that it accounts for documentation which is not part of any baseline.

I have solved it as follows:

> Project 1
  > Trunk
  > Branches
  > Tags
  > Archive

If you expand this structure, you will find something like this:

> Project 1
  > Trunc
    > Management & Analysis
    > Design
    > Testing
    > Code
  > Branches
    > 4.2
    > 4.3
    > 5.0
      > Management & Analysis
      > Design
      > Testing
      > Code
  > Tags
    > 4.2.0
    > 4.2.1
    > 4.2.2
    > 4.3.0
    > 5.0.0
    > 5.0.1
      > Management & Analysis
      > Design
      > Testing
      > Code
  > Archive
    > Meetings
    > Reports 

As you can see, what goes in the Trunc folder is only fully configured items (which are part of the baseline). Whatever else is stored in the Archive folder, which is one folder for the whole project, no need to put it under the trunk.

As I did above, I have added two folders under the Archive folder: Meetings & Reports. These are the two broad categories which should not be part of any baseline.

Risk Management Primer For Small Teams

In software engineering, every single activity is an act of mitigating or removing one or more risks. For example, upfront architecture of the product mitigates the risk of poor performance; testing mitigates the risk of failure at production; analysis mitigates the risk of unhappy customer and project failure. Let us give this risk mitigation technique a name: In-process Risk Mitigation And Prevention.

However, there are some risks that must be pinpointed and observed closely. The In-process technique is not enough in these cases. Here are some examples:

Requirements Risks:

• Requirements are vague
• Lack of experience in the problem space
• Communication problem between the team and the customers/users.

Technical Risks:

• New technology, new tools.
• Performance and Scalability risks
• Integration of work products of dispersed teams.

Scheduling Risks:

• tight schedule imposed by the customer/market/management

There are so many risks that may be identified. However, many of them are not of such importance to be kept spotted. In my experience, the following risks are typically not that important to be tracked:

People:

• People get sick
• Team member leaves the company, or re-assigned to another project

Scheduling risks

• Team receives L2 support requests
• Requirements risks
• Many change requests from customer

Very important note: these risks may well be risks, and may impact the project negatively. However, the reason they are not spotted is that they are very well handled in the In-process risk mitigation technique.

Take your time to pay for this technical debt, but let me know how you would prevent it in the future!

In a previous blog, I explained why 'Technical debt is not bad!', and explained that this idea pays for itself on the long run. However, the title of this post indicates the right question asked by senior management while negotiating time to pay for technical debts.

The idea is that: Part of fixing a problem is preventing it from re-occurring.

This does not mean that technical debt will not re-occur; it means that the specific issue that caused this type of technical debt should be resolved from the roots and hopefully not re-occur.

This way of thinking is a characteristic of high mature organizations.

Technical debt is not bad!

Technical debt is usually thought of as a notorious thing indicating bad (or no) design, and leads to projects failure after several iterations.

Actually, this is not true. Refactoring is a constant effort done by the development team even with the most intelligent designs. Developers (and their designs) matures "while" working on the project. This maturity emerges from that following facts:

• The level of understanding of the business domain gets clearer.
• Seeing the design at work develops more brighter design ideas.
• Development work is the most effective learning experience for developers. So, the more you develop, the more you learn about design concepts, and the more you see opportunities for improving the existing design.

This is why teams should find a way to incorporate paying technical debt every now and then. By incorporate, I mean to reflect on it as part of every iteration, or may be dedicate an entire iteration for it if needed.

Software Development does not follow any predictable manufacturing process rules

In this excellent presentation about Agile Estimation, by Christoph Steindl. The author lists the difference between what is called "Predictable Manufacturing" vs. "New Product Development". These differences are following Lean principles, and applies to any endeavor.

Reflecting on these differences, it is so clear that Software Development does not following the rules of Predictable Manufacturing defined processes. This is because Software Development is an innovative, intellectual, and usually creative effort that cannot be govered or managed by any strictly defined process. True!

Something came to my mind while reading this, which is how to improve both types of processes.

For any defined process (predictable manufacturing), it is improved by getting it more and more defined to account for new special cases, or new causes for variation.

For any empirical process (new product development), it is improved by enhancing the feedback control system, which steers the development effort, and upon which everyone in the development team should depend.

Imagine what would happen if software is developed without such feedback control system?

In a next blog, I will give examples of famous mechanisms which implements these feedback control systems in software development.