Most attempts at implementing some methodology like this have been miserable failures, in my experience. This has been because
- a) The team was already well-organized, efficient and shared a common vision of what we were building and how we were going to build it
OR
- b) The team had no shared vision of how to build software to start with, and the methodology was no silver bullet.
In the former case, the methodology is unnecessary, except to document what's already happening, and any team that together will resent the extra work for the rubber stamp. In the latter, pressing a scattered group of individuals through the meat-grinder of a particular methodology will probably just make them work even more poorly together.
Naturally, having an organized, coherent and, most importantly, useful plan for each stage of development and the overall process is a Good Thing(tm). But having it on paper, or have it follow some management wonk's version of Utopia is irrelevant.
By all means, take the time to find some common ground for selecting lifecycle methods, designing, coding, reviewing code, writing documentation, testing, tracking defects and progress, etc., and then follow them religiously. Make sure that new hires are trained on how you do things, and understand and agree with your methods (or are at least willing to follow them for the greater good).
Later, if it turns out that more people will actually buy you're software because you're a CMM level 4 shop (or whatever) - hire some writers to handle the certification process if your engineers don't want to see it (and they almost certainly won't);-)
Slashdot Mirror
Most attempts at implementing some methodology like this have been miserable failures, in my experience. This has been because
;-)
- a) The team was already well-organized, efficient and shared a common vision of what we were building and how we were going to build it
OR
- b) The team had no shared vision of how to build software to start with, and the methodology was no silver bullet.
In the former case, the methodology is unnecessary, except to document what's already happening, and any team that together will resent the extra work for the rubber stamp. In the latter, pressing a scattered group of individuals through the meat-grinder of a particular methodology will probably just make them work even more poorly together.
Naturally, having an organized, coherent and, most importantly, useful plan for each stage of development and the overall process is a Good Thing(tm). But having it on paper, or have it follow some management wonk's version of Utopia is irrelevant.
By all means, take the time to find some common ground for selecting lifecycle methods, designing, coding, reviewing code, writing documentation, testing, tracking defects and progress, etc., and then follow them religiously. Make sure that new hires are trained on how you do things, and understand and agree with your methods (or are at least willing to follow them for the greater good).
Later, if it turns out that more people will actually buy you're software because you're a CMM level 4 shop (or whatever) - hire some writers to handle the certification process if your engineers don't want to see it (and they almost certainly won't)