In the time I have spent lecturing, teaching and working with Team System I have heard the following statement more times than I care to count, “Yeah, we know we have a problem, but we can’t get anyone to do anything about it.” This is a problem that isn’t so readily solved. A lot of people would just say, “Well, why don’t YOU do something about it? Start writing unit tests. Start doing nightly builds. Start using tools x, y and z.” The problem is that this doesn’t really solve the problem 90% of the time.
Why not? Well, most developers (especially those using TFS) work for organizations. The only way some things get done in large organizations is for executives to champion a cause and actively implement a plan for improvement. But this takes some type of ROI calculation – most executives will not plow money into an initiative with no benefit. Okay, seems reasonable you say but how do you actually convince them? This is where the catch-22 comes in. In order to prove the benefit of changing a methodology or using a new tool or even changing a single process you need to have gathered some kind of metrics. How many of you do that today?
The reality is that most organizations today do not effectively gather or evaluate metrics. I’ll give you my favorite example – do you track bugs and change requests? Mostly people track them in some way, but don’t consolidate them and don’t try to understand the root cause because that takes time. For example, a user comes to you and says I found a bug with feature X, it doesn’t do this (whatever this is) and it should. Is it a bug? Is it an enhancement? Maybe it’s a requirement that was missed? Try telling an executive that you need to institute a method for gathering requirements consistently or that the analysts need training without knowing anything about the changes that are being requested of you…
This is a personal crusade of mine so I’ll follow up with other thoughts and some easy (read inexpensive) methods for starting to gather this information.