I recently took the MIT Media Lab Blogger Survey. I am now a statistic :)
From jdk
Tuesday, June 28, 2005
Friday, June 24, 2005
How frequent should the delivery be?
In a previous post I had written about frequent delivery. Sachin asks in this comment how likely it is that a customer would be willing to check delivery after delivery. This is a good question thats worth going into some more detail.
Customers worry about two things: (1) Is anything progress happening in their project and (2) is it going to turn out the way they want. The worst nightmare for a customer is to not hear anything about the project until the end when they are told its only 50% done, and then they wait more time only to see the final product and find it unusable. In short, they want visibility into the project.
Now, different customers want different amounts of visibility. If a customer doesnt care if they project succeeds or not, they may want only one delivery in the end. At the other extreme, some customers may be willing to dedicate one person for the entire duration of the project to see how it is going. In Agile terminology, this is called having an onsite customer. Ideally, this would be the best situation, but it's not always possible. These are the two extremes. Somewhere in the middle are customers who want to see the project once in a while, if only for their peace of mind.
The ideal delivery cycle depends on two factors: how often the customer wants to see the progress, and how often you can make a delivery.
If it's a web based project, a delivery cycle of 3 weeks is possible. If it's a complex project with lots of deployment for each release, the delivery cycle will be somewhere around once in 3 months, which translates to around 4 deliveries for a year long project. If you are creating a product, the "customer" may be the QA team or the evangelist/stakeholder for your product. They may be willing to spend more time looking over the software.
Its up to the team to negotiate a suitable delivery cycle depending upon the customers willingness, the complexity of project deployment and how fast the team can add and test features.
In they end, the customer is paying for the software, so they would be definately willing to see it before the final delivery, especially if they are told that this increases the chances of a successfull product. Most customers have gone through projects with no visibility with disaster at the end and they would be totally thrilled that someone is actually willing to show them the product as it comes along.
This post is a part of the selected archive.
Customers worry about two things: (1) Is anything progress happening in their project and (2) is it going to turn out the way they want. The worst nightmare for a customer is to not hear anything about the project until the end when they are told its only 50% done, and then they wait more time only to see the final product and find it unusable. In short, they want visibility into the project.
Now, different customers want different amounts of visibility. If a customer doesnt care if they project succeeds or not, they may want only one delivery in the end. At the other extreme, some customers may be willing to dedicate one person for the entire duration of the project to see how it is going. In Agile terminology, this is called having an onsite customer. Ideally, this would be the best situation, but it's not always possible. These are the two extremes. Somewhere in the middle are customers who want to see the project once in a while, if only for their peace of mind.
The ideal delivery cycle depends on two factors: how often the customer wants to see the progress, and how often you can make a delivery.
If it's a web based project, a delivery cycle of 3 weeks is possible. If it's a complex project with lots of deployment for each release, the delivery cycle will be somewhere around once in 3 months, which translates to around 4 deliveries for a year long project. If you are creating a product, the "customer" may be the QA team or the evangelist/stakeholder for your product. They may be willing to spend more time looking over the software.
Its up to the team to negotiate a suitable delivery cycle depending upon the customers willingness, the complexity of project deployment and how fast the team can add and test features.
In they end, the customer is paying for the software, so they would be definately willing to see it before the final delivery, especially if they are told that this increases the chances of a successfull product. Most customers have gone through projects with no visibility with disaster at the end and they would be totally thrilled that someone is actually willing to show them the product as it comes along.
This post is a part of the selected archive.
Thursday, June 23, 2005
Statue at Salisbury Cathedral
This statue is from the cathedral in Salisbury, England. Construction on the cathedral started in 1220 AD. The cathedral has the tallest spire in England at 123 meters. It also has one of the oldest working clocks in Europe. For more information, see this wikipedia article.
Wednesday, June 22, 2005
Truck Factor
One of the more informal metrics (if you can call it that) is the "Truck Factor" of the team. The Truck Factor measures the amount of spread of knowledge within a team.
Formally, the truck factor is the number of people that need to be hit by a truck before the project is in serious trouble. Of course, they don't actually need to be hit by a truck, they could leave the company, fall ill, or take a vacation.
The idea is that if only one or two people know the critical components of a system, then the project is in serious trouble should they leave. A Truck Factor of one is the worst, with most of the critical knowledge with just one person. Ideally everyone in the team should know every part of the system, but thats not very practical. An achievable goal is that at least 25% to 50% of the team knows any one component. Hopefully it won't be the same 50% who know every component :).
Small teams of under 10 people usually target a truck factor of 4-5 for most parts of the system (thats around 50% of the team). Larger teams will probably target a truck factor of around 8 (which would probably be around 25% of the team). This means that should a couple of critical people go on vacation or leave the company, there are enough people in the team who can cover for them.
Ironically, smaller teams usually have larger 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, with only a couple of modules having a low truck factor. In teams with above 20 people, chances are that a few people at the top (designer, architect, lead) know the system thoroughly and the rest only know about the couple of modules that they worked on. Should these people leave at around the same time, the project could be in serious trouble.
One of the things that we have been working on is increasing the truck factor. Every once in a while, we target areas with a truck factor of one and that person then gives a seminar to the rest of the team. Not only does it help with knowledge sharing, but it also means that the person can take a vacation without worry.
This post is a part of the selected archive.
Formally, the truck factor is the number of people that need to be hit by a truck before the project is in serious trouble. Of course, they don't actually need to be hit by a truck, they could leave the company, fall ill, or take a vacation.
The idea is that if only one or two people know the critical components of a system, then the project is in serious trouble should they leave. A Truck Factor of one is the worst, with most of the critical knowledge with just one person. Ideally everyone in the team should know every part of the system, but thats not very practical. An achievable goal is that at least 25% to 50% of the team knows any one component. Hopefully it won't be the same 50% who know every component :).
Small teams of under 10 people usually target a truck factor of 4-5 for most parts of the system (thats around 50% of the team). Larger teams will probably target a truck factor of around 8 (which would probably be around 25% of the team). This means that should a couple of critical people go on vacation or leave the company, there are enough people in the team who can cover for them.
Ironically, smaller teams usually have larger 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, with only a couple of modules having a low truck factor. In teams with above 20 people, chances are that a few people at the top (designer, architect, lead) know the system thoroughly and the rest only know about the couple of modules that they worked on. Should these people leave at around the same time, the project could be in serious trouble.
One of the things that we have been working on is increasing the truck factor. Every once in a while, we target areas with a truck factor of one and that person then gives a seminar to the rest of the team. Not only does it help with knowledge sharing, but it also means that the person can take a vacation without worry.
This post is a part of the selected archive.
Thursday, June 16, 2005
Sunday, June 12, 2005
Trip Photos
I'm back from my vacation. I've uploaded some photos to flickr. You can either click the thumbnail images on the top of this page to see the most recently uploaded photos, or click here to access the entire photostream. Most of the photos are from London and Paris, but a few are from other places.
I should add a small note that the photos that I've uploaded so far are only the photos that I really liked (around 15 I think), so although I did take photos of the popular sights (18+ rolls of film/slides), they have not been uploaded.
I should add a small note that the photos that I've uploaded so far are only the photos that I really liked (around 15 I think), so although I did take photos of the popular sights (18+ rolls of film/slides), they have not been uploaded.
Subscribe to:
Posts (Atom)