producteering.org » risk management

Using The “Truck Factor” To Manage Knowledge Risk

siddhi — Thu, 16 Jul 2009 13:40:03 +0000

A big risk in software development is “knowledge risk.” This is the risk that someone is the only person who knows how a particular part of the system works. The project could be in serious trouble should the person leave the company or generally become unavailable.

We have a term for this in agile project management. It’s called “Truck Factor.” The name comes from the fact that when knowledge is localised, then any unexpected event–like a person getting hit by a truck–could jeopardise the project.

A Truck Factor of 1 is the worst. It means that there is some part of the system that is understood by only a single person. A Truck Factor of 2 means that at least two people understand every part of the system, and so on.

Here is how to calculate the Truck Factor for your project:

Go through each class, file or component
Calculate the number of people in the team who understand that part of the system
This gives you the Truck Factor for that class or component
The smallest of all the component truck factors is the Truck Factor for the project

You will be surprised at how many projects end up with a Truck Factor of 1.

Surprisingly, there are even projects with a Truck Factor of zero! How is this possible? Simple. It means that there once used to be someone who knew a component, who has since left the project. Nobody remaining in the team understands that component. The result is a Truck Factor of zero.

Ideally everyone in the team should know every part of the system, but that is not very practical. An achievable goal is that at least 25% of the team knows any one component.

Ironically, smaller teams usually have better truck factors compared to larger teams. In teams of 5-10 members, there is a high chance that most of them know most parts of the system. In teams with above 20 people, chances are that a team members only knows about the couple of modules that he or she worked on.

There is another message here–high turnover in the team leads to smaller truck factors.

The Truck Factor is a simple and easy to measure metric that carries a lot of meaning. What is the Truck Factor for your project?

Siddharta Govindaraj is the founder of Silver Stripe Software Pvt Ltd, whose flagship product Silver Catalyst is a tool for Agile Project Management. Siddharta has been working with agile processes for over five years in Singapore and India. Siddharta also coordinates the Chennai Agile User Group and conducts Agile workshops and training programmes for software professionals.

Risk management in Software Product Development

Producteering Digest — Fri, 11 Jul 2008 09:28:17 +0000

Software product companies who say, “We are an entrepreneurial company. We cannot be afraid of risk” may have to rethink that statement. This is due to the fact that every software development project comes with a sizeable amount of risk and this risk has to be minimized to the level where a project becomes successful and the product can be released without any major disaster.

Risk is the key to many tough decisions, for example: What is the best lifecycle model to use? How much requirements work is enough? How much design work is enough? Can junior staff be used instead of senior staff and where? How much schedule buffer is needed?

A risk management plan can help minimize unforeseen developments. Risk management is a set of practices which aids in analyzing many software development issues viz. assessing overall project risk and identifying, prioritizing, and managing specific risks.

Some examples of in-built risk management are active project tracking, UI prototyping, end-user involvement, incremental delivery and upstream technical reviews. This cyclic order has to be maintained for a software product being developed to be a success.

While every risk cannot be controlled, it can be identified, and solutions for the ones with the maximum impact can thus be developed. Good software development therefore calls for an effective Risk Management Plan.

Read the entire digest contents

A Great Product Vs. Good Enough Software: The Quality Perspective

Producteering Digest — Fri, 04 Jul 2008 09:15:16 +0000

During the Producteering Breakfast series held at the SD Forum in California last month, the majority of participants (from the ISV community) held the view that a flawless and high quality product need not be the goal when attempting to build a successful product. Instead, a product that fulfilled customer expectations and which was better than competing products had more potential to be a ‘great product’.

So, instead of zero-defect software, what most users want is software that is cheap enough, fast enough, feature-rich enough, and available soon enough — that is, “Good enough”. Zero-defect software is often at the expense of time, functionality or cost – or all three. In fact, zero-defect software never guarantees that a product is ready or good enough to ship.

That leaves us with the question that’s been asked many times before: when is non-life critical software ready to ship? Is it when a certain date arrives, certain functionality built or some quality metric achieved? None of these criteria can actually result in software that is good enough to deliver. One aspect of an approach promoted by James Bach is to adopt a utilitarian method to deliver good enough software that is based on risk analysis. That is:

* Software is good enough when the potential positive consequences of creating or applying it outweigh the potential negatives
* Structured risk management needs to be applied to weigh the consequences and identify factors that make the risk more or less likely to occur
* Assessment of short and long-term consequences if the risk occurs
* Knowing the difference between important and unimportant, necessary and unnecessary

Many successful software products ship with dozens, if not hundreds or thousands of bugs, including most Windows and Mac product versions. However, it isn’t the number of bugs that matters; it’s the effect of each bug. In other words, knowing the risks of deploying software with known (and unknown) defects allows one to release software that is good enough, even to be the best!

Read the entire digest contents