Do you ever feel like things are out of control on your project, that you are adrift in a sea of conflicting priorities and requests? Do you suddenly find out at the last minute that you are the bottleneck and everybody is breathing down your neck asking you what is taking you so long to create the moveStuff() method but you had no idea that anybody even cared about moveStuff() or that you owned it? Do you ever find yourself in the exact opposite position, wondering why Sue and Bob didn’t get their stuff done that you need and then your boss walks by while you are surfing the net waiting for Sue and Bob? And who is Bob anyway?

The solution is simple! All you need to do is get everybody to move to Project. Well, if you have somebody you can spare full-time to keep Project up to date of course. Oh and I almost forgot, you’ll need to start using a requirements tool. But that’s it really, other than integrating them all together over the weekend and of course that’s assuming you’ve already gotten a CRM tool for workflow.

There is a simpler solution. It isn’t perfect, and it doesn’t solve all problems, but it can definitely provide the following benefits:

• reduce the chaos
• increase your vision into where you are and what’s going on
• reduce the number of status and/or project management meetings
• reduce the need to provide the same information over and over again
• simplify collaboration both locally and for distributed teams
• provide a more Agile workflow

The answer is to reduce the amount of rework that you are already doing. Right now you are probably storing defects in a defect tracking system, enhancements (aka RFEs, requirements, etc) in a requirements management tool (usually Excel or Word but sometimes an actual RM tool), and if you are using a project management tool it is probably MS-Project. All three of these product areas evolved to provide different aspects of project management for different groups of people and as a result they have lots of overlap. Considering how hard it is to coordinate three different systems, why not consider standardizing on one system for most of the work? The only question is, which system?

If we are going to try to do most of our project management work in a single tool, we should first decide what the interesting activities are. I believe they are: recording enhancement requests and defects as they are gathered by marketing or reported by users, load balancing, estimated completion calculation, critical path determination, work assignment, workflow, and reporting.

First let’s consider how well suited Project is for doing most or all of these tasks. Project is good at taking a small static collection of large tasks and doing load balancing, estimated completion, and critical path determination. Thus, it is mostly used for the very narrow task of project management of enhancements.

Next let’s consider requirements management. For whatever reason, most people use Excel or Word as their requirements management tool instead of a “real” requirements management tool. Excel and Word are just not appropriate for project management.

Lastly, there is defect tracking. A defect tracking system covers the assignment, tracking, workflow and reporting of defects. There is usually a higher volume of defects than enhancements, and they are usually smaller in scope and have a more complicated and often more time critical workflow. If it works well for defects, it should work equally well for enhancements.

Based on this analysis, it makes sense to extend the project management that you are already doing with a defect tracking system to include enhancements. A generic name for something that is either a requirement, enhancement, or defect is “work item.” By using work items to track all work, it is easy to see where you are and what remains to be done. Now you can use a similar workflow for enhancements as you do for defects, for instance from newly entered, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. You can easily run a query to see which work items have their code written but do not yet have any tests. Similarly, you can see which work items are done from a coding perspective and have tests but have not yet been verified as done by QA. This will give you a much more complete view of your overall project status and progress.

Whatever you are currently using for defect tracking it will be straightforward to start getting the benefits of managing defects and enhancements together. Just add a field that indicates if a work item is a defect or an enhancement. You may need to make a few more changes to accommodate a slightly different workflow for enhancements than you have for defects, but I think you’ll find it is worth the effort. For one example of how this can work, you can take a look at how AccuRev does it using AccuWorkflow.

Managing software development is tough enough as it is. Managers take responsibility for the results their teams deliver. They’re on the hook for hitting schedules, delivering quality, and meeting customer requirements. Worst of all, if they’re saddled with slacker engineers, they still have to get the work done, and done right.

Tools are needed to help managers stay on top of their projects and find problems when there’s still time to fix them, before the schedule pressures explode. Project management tools are valuable, but their schedules only reflect the quality of the information that went into making them. Garbage in, garbage out.

The SCM system is the source of the information that drives smart decisions. Here are four sources of real data that can come out of any quality SCM system. I’ll illustrate with AccuRev because, well, because it’s the best.

1. Bug Arrival Rate
2. Churn rate
3. Task Estimate accuracy
4. Complexity Creep

1. Bug Arrival Rate

A key graph in any project manager’s arsenal compares bugs reported over time against bugs closed over time. Here we use AccuRev’s AccuWork issue tracking tool to store all issues, whether reported by QA, sent in from customer service’s CRM, or entered by the powers that be as customer requirements. Since our iterations are four weeks long, we use the week as a reporting time period. Some AccuRev customers use days.

In AccuWork, queries are easy to create, and we get a report from AccuWork in XML covering all the issues opened or verified [foot note: In our terminology, developers “close” issues, and QA “verifies” them. Other companies have developers “submit” issues and QA “close” them] against a particular iteration.

The XML slides right into Microsoft’s excellent Excel 2003. I use PivotTables and Excel graphs for all my reports. Others might leverage their superior Perl skills.

Here, we add a “week” field based on the AccuRev time field.

2.Churn Rate

A key metric for quality is how often different parts of the code base have to be modified to address issues. Here, the AccuRev code repository has all the information we need. I use the AccuRev Hist command

accurev hist –a –s “release candidate stream” –fx –t “2006/1/8 – 2006/1/1”

to get an XML file of all the “Promotes” (sort of like “check-ins”) to a release candidate stream within a time range. Some use a separate “hist” command for each release period. Personally, I take a big time range and then use Microsoft’s Excel 2003’s XML file support to slice and dice into tasty chucks. I tried it once with Excel 2007. Once.

Since we component-ize our code base based on directories, the “path” field is particularly interesting, as directories can be as significant as individual files.

Loading the XML file into Excel, my macro deletes some unneeded columns and creates a Pivot Table like the following:

Here I’ve filtered the data to not include the binary files, and used the Excel Pivot table’s advanced feature to show the top ten in descending order. AccuRev.c takes a beating every release but it isn’t significant. Server/diff.c and Client/stat.c seem to be at the center of a lot of changes that release, and are probably candidates for some code reviews.

3. Task Estimate Accuracy

Along with dates of issue opens and issue closes, we have chosen to include a user field for the original estimate of the length of time it will take to complete the issue. That gives us something to compare to when we “close” an issue and send it to QA, and an opportunity to correlate against the length of time before an issue gets verified.

As a best-practice, we try to normalize issues to a couple of days in length. Longer and you haven’t really figured out what needs to be done. Shorter and you’re liable to strangle in your own spit, a management practice I can’t recommend having seen the results.

We get this data out of AccuWork again, and can slice it by group, release, or even individual developer. This is a quick way to quantify the subjective feel we all have for who is slow, who’s fast, and who’s clueless. Here’s a scatter plot for a group. Note that they are generally on the high side of their estimates, and that they haven’t done a very good job normalizing tasks to 2-3 days:

4. Complexity Creep

As software gets modified, and especially when managers become conscious of the amount of time taken to fix a bug or implement a feature, there is a tendency for developers to make the code base less maintainable. There are some metrics for code complexity that can benefit the manager when trying to assess when it is time to refactor. A frequently used metric is cyclomatic code complexity.

While we don’t do any code complexity measurements here, some of our larger customers do. This is easy to collect using a trigger on changes being sent to a release candidate (or QA candidate) stream, where the trigger calls the analysis tool and puts the results into a tab-separated file for later plotting from Excel.

A simple (Perl) implementation of the server side “server_post_promote” trigger creating a file “complexity.txt” looks like:

open COMPOUT, “>>complexity.txt” or die “Can’t open complexity.txt”;
if ($stream eq “acmeProj_QA”) {
$complexity = complexity($stream, $version, $workspaceDir, $filePath);
print COMPOUT “$user\t $date\t $transaction\t $stream\t $version\t $filePath\t $complexity\t $issueNum\n”;
}
close COMPOUT;

Together, these reports provide a good mix of data around schedule, estimation and code quality, giving our beleaguered project manager a pretty nice set of armor.

Please post your favorite management reports, even if you don’t (yet!) use AccuRev.

Requirement #3: Match the Project to the Team

You can put lipstick on a pig but it doesn’t do much good. It’s not much to look at, and it annoys the pig. You can assign any old set of tasks to the offshore team, but if they CAN’T succeed at the project, or DON’T CARE about succeeding at the project, you won’t get much value and you’ll have ended up annoying the team.

Agile methodologies have taught us all the benefits of keeping the customer tied into the development process. We know the offshore team will have less of a context for managing changes and usually will average less years of experience than the corporate team.

That doesn’t mean you can try to do the “thinking” for them. There are as many smart people in Moscow and Bangalore as there are in Silicon Valley, just fewer Starbucks.

There are two common failure modes in defining projects for the offshore team:

1. Asking a remote team to solve a complex problem the customer might not understand; or
2. Asking the remote team to grind through endless bug fixes to a stable product line.

In the first, it’s easy to see that the customer isn’t getting any happier with each release. In the second, the failure will be the Dutch Elm Disease of application development: developer turnover.

Developer turnover comes from multiple sources, many of which you don’t control. Given the heavy cost of recruiting and training new hires, it pays to stay on top of the factors you do influence. Everybody wants to be successful, and will stay on a successful project longer than on an unsuccessful one. So pick the project wisely.

Great projects for remote teams are ones that have very well defined deliverables but ambitious long-term goals. Projects like cloning capabilities of one system to another, changing platforms or improving performance of an app, all benefit from clarity of definition and sufficient technical challenge to keep the remote team productive and engaged.

Epilog

In my humble experience, meeting these three requirements eliminates the additional risk created by an offshore development group, and reduces the problem to the same set of risks as an onshore development group. Not that onshore development is easy.

Are three requirements really all it takes? Yes, because all three are meta-requirements that cover the most important challenges of offshoring. In fact, a superstar remote team lead (Requirement #1) can be enough in itself to deliver success. Superstars are so hard to find we can’t count on finding them. That’s why you need to maximize your success rate by meeting requirements 2 and 3 as well.

Bonne Chance, Bueno Suerte, Удачи, and Good luck!