One Simple Metric

At our last Agile Iowa meeting on Thursday, Jared Richardson, he was talking about Agile Testing Strategies. He mentioned a metric he used that I found very interesting. He took three variables and created a report that listed the top 10 method/assemblies that were at risk.
Here is the (simple) equation:

Cyclomatic Complexity (CC):
Usage (U): How many other methods/classes rely on this code.
Test Coverage Percentage (TC): The percentage of the code that is exercised by a unit test
Risk Factor = CC x U x (1 - TC)

Let's look at a couple examples:
This first table shows a method used by 50 other methods (Usage) with a Cyclomatic complexity (CC) of 20. I then vary the code coverage for this method. Without any unit tests, the risk factor is a cool "g" (or Grand). As the test coverage increases the Risk Factor decreases. When the test coverage reaches 100%, the Risk Factor is reduced to zero. The function is linear, so decreasing the usage or the complexity will also reduce the Risk Factor. So it make sense that if a method isn't used, it has a risk factor of zero.

CC	Usage	Code Coverage	Risk Factor
20	50	0	1,000
20	50	0.1	900
20	50	0.5	500
20	50	0.9	100

The following methods all have the same risk factor of 250. Do you think this is reasonable? Should one of these factors be weighted heavier?

CC	Usage	Code Coverage	Risk Factor
10	50	.5	250
50	10	0.5	250
50	50	0.9	250

For now I'm going to see how I can get the usage and the code coverage numbers automated... I can tweak the algorithm more later.

Lean is the new Agile

I'm happy to see more people everyday are interested in Agile methods, however I'm saddened by the misinterpretation and perceptions of Agile by people who have never experienced it.

I've discovered that when I mention Agile to a group of IT Professionals, there is an initial reaction of shock and defensive posturing.

"Agile isn't for us. We don't want the developers coding without any direction."

or

"If we're going to use XP, that's fine. I'll just find another team!"

It's hard enough to have people listen about the spirit of agility when they have already made their minds up...which leads me to the topic of this post.

Lean is the new Agile

Recently I've been hearing more and more about Lean software development. It's not new, but I believe the agile community is looking for another way to market agility outside the software industry. And it makes sense to use Lean Manufacturing as the model. Every business person in the world has heard about lean manufacturing. Not only have they heard the term, there is an engrained positive feeling about it. Lean sounds like it costs less with more quality. They associate lean with Toyota which they associate with quality...Oh what a feeling!

Agile, on the other hand, is associated with XP (Extreme Programming). Nobody in business wants anything to do with anything that is extreme. Extreme equates to Risk and the business world is all about reducing risks (or as we say, "mitigating risks").

So give it a shot. Next time someone is discussing your software development methodology, tell them you use a lean software development methodology based on the principles from the Toyota Production System and see how they react.

Single or Multi Threaded Projects

There are two strategies to complete the things you want to get done:

1. Start them all at the same time
2. Work on one at a time until it is completed, then work on the next highest priority

How do you do it in your daily life? If you have a list of tasks that you need to get done which approach do you use?

Let's think about how your company completes project. Which approach do they use? Are they the same?

Let's weigh the Pros and Cons of each approach. Let's assume your team needs to complete 3 similar sized projects (Project A, Project B, Project C) within 3 months.

Start all the projects at the same time (Multi-threaded)

Pros:

All project stakeholders are told their project has started

Cons:

Tracking each project's status is difficult

People on the project frequently have to switch thinking between each project

Each project will take 3 months duration to finish

Don't start earning returns on the projects

If there are overruns, each project is affected

One project at a time (Single-threaded)

Pros:

Only need to track a single project at a time

People on the project are focused

Each project should finish in one month

Project A will earn returns for 2 months

Project B will earn 1 month of returns

Overruns affect fewer projects

Cons:

Project stakeholders are told their project hasn't started

 

Am I missing any Pro/Cons for either of these scenarios?