Why have principles behind practices and techniques?

The answer is very simple. If you can identify the principle behind the practice, you will open the door for creativity to invent other practices which may better realize the principle!

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.

Why collect measurements?

Two main reasons to collect measurements:

1. To track your project. A basic task of any software project manager is to track the project progress. Examples are the defect rate, the size of finished functionality versus not finished. A very good technique which reads this measurement and displays it in a graphical format is the burn-up/burn-down charts which are heavily used in Agile development.
2. To improve the process of producing software. Very similar to six-sigma projects, CMMI level 4 and 5 have techniques which starts with an evidence of a mal-functioning process (most commonly supported by measurements).Then, it digs into the root causes, and suggests corrective actions. Finally, it designs measurements to quantify the impact of corrective actions, and start over again. This ‘Continuous Improvement’ cycle is one of the techniques used in any engineering discipline.

Measurements are an invaluable means for management, especially for software development, which is a deep intellectual engineering discipline. I may safely say that without measurements, you may not reach good management decisions what so ever. One of the sayings that is said again and again in Balanced Score-Cards environments is that “you cannot manage what you cannot measure, and you cannot measure what you cannot define”, is really true.

What to keep in mind while designing your measurements

Out of the many good advice about measurement systems for software processes, I have benefited most from these four pieces of advice:

1. Set the goal before you measure.

It is tempting to set out a range of measurements, each costs some good time in calculation, while you don't need it. It is also very common that a project manager or a process engineer says: "we will need them later on, so why not collect them anyways?", another third idea is that "collecting many measurements may give you insight about the deficiencies in the project or the process, so the more you collect, the more insight you gain"!

I have lived with these philosophies for a while, and spent so much time collecting lots of measurements just for the sake of measuring, and I really think it was pointless.

The strategy I'm following right now is to set up the next objectives (one or two, at maximum), design the measures which I really need, and implement the infrastructure which will help me collect these measures automatically.

2. Distribute measurements results and analysis to the development team

Results of measurements may be very interesting for the team to visualize. Not only interesting, but also motivating. As a practise I continuously follow, I send the results of the measrements and analysis to the team, and discuss with them their implications. This helps me to:

• Motivate the team to work towards achieving better measurements.
• Motivate the team to record measurements more accurately.
• Get the team to the point that they trust the value of the measurements as a means for project management, and as a means for process improvement.

3. Minimize the time of collecting measurements.

This is a point which is very sensitive. If the cost of collecting a measurement is high, it is more likely that the whole measurement system will collapse! Developers like to develop, not to "waste" their time counting number of hours, bugs, lines of code, et cetera. If it constantly takes time to calculate measures, it will distract the team, and demotivates them.

To mitigate this issue, automate your measurement calculation. How? this depends on the measurement and the tools used.

4. Do not use measurements for evaluating individual developers.

Measurements is a means for project tracking and process improvement. It has also a side effect of motivating the team and achieving goals. But, a common mistake is to use these measurements to pinpoint productivity issues to individual developers.

I used to work in a strong measurements environment sometime ago, in which measurements are collected to monitor all software development phases. After the project ends, the same measurements are used to evaluate developers, and calculate their mid-year bonuses accordingly.

One of these measures was the number of review issues opened in peer reviews. In time, we found developers not opening any review issues, and prefer to communicate the review results either orally or by mail, not through the issue tracking system (which automatically calculates the measure). The reason they did that is no to affect the bonuses of themselves! I have to say that I personally found myself inclined not to open any review issues just like the rest of the team. It is a feeling that you cannot resist.

If you are interested to read more about such valuable advice, you will find these advice (and others) in the following references:

• More process Patterns, by Scott Ambler.
• Rapid Software Development: Taming Wild Software Schedules, by Steve McConnell.

Why process is important from day 1?

Sometimes we here some devastating (yes literally devastating) ideas like:

• Process is pure overhead.
  
• Process is discovered while working on the project (after we start the project).
  
• Let’s start coding, we will refactor anyways.
  
• Just jump in the code, things will get crystallized as you go.
  

The problems of such sayings is that it tempts poor developers to start a project with the unhandled risks inherent in the software development endeavor.

Famous processes like RUP markets for itself as “a risk removal process”. Agile methods assume to mitigate many risks of software development, even if not having a list of risks which we keep an eye on, which is true in my humble opinion.

The fact of starting a project without a clear view of how to do configuration management, how to do estimation, how to document requirements, how to involve stakeholders and get feedback on requirements, when and how to test, what are the bugs types, and which of them are to be fixed first, how, when and by whom architecture and design is going to be done, how to do tracking and what measures will indicate progress, how you will handle change, and many others. The fact of starting the project without a clear answer of such questions is pure act of failing the project, causing some persons to suffer sometime of their lives and get disappointed and demotivated at the end of the way (the developers), and causing others to lose some money, lose business opportunities, and lose trust in software development teams (the customers).

I hope this is a clear answer to the question. Please take some time and think of how you will develop software before you take the responsibility of any projects.

The next question is: Does process limit develop creativity? This needs a separate post.