XP's creator, Kent Beck hasn't made any friends in CM. He uses the phrase "embrace change" and then doesn't even discuss how XP affects change management. The role "Configuration manager" does not exist in his book.

It's this stealth approach that makes XP so valuable.  XP introduces solid change management practices in terms that are palatable to the typical developer. By doing so, XP brings logical priority to the user requirements, as well as tangible granularity to management of the assets. 

XP hinges on the premise that if you do the most important requirements first, and then add more features in iterative cycles, you reduce risk by actually producing what the customer wants.

Additionally, there's the concept of "collective ownership". Beck writes, "Everybody takes responsibility for the whole of the system. Not everyone knows every part equally well, although everyone knows something about every part." Impact analysis has a new name.

With a large system, it's difficult to do "collective ownership". There's no way to know something about every part.   But by incorporating the very idea of collective ownership as part of the XP standard, programmers realize the impact of their work on the system as a whole. That's something CM process developers have been wanting for years!

XP's practices include Refactoring.  Refactoring is the act of adding features to a system by making the simplest architectural change possible to the system, and then regression testing. This reuse by design approach reduces duplicated code, and replaces haphazard system architectures with clean-running systems that are much easier to manage.

Finally, the practice of "Continuous Integration" encourages programmers to check their code in often, to merge it to the current baseline and to test at merge to ensure it works without taking anything else out. No more waiting until the last minute to alpha test a feature, only to find out that the design is fundamentally flawed. Your team doesn't have to do the midnight hour quick-fix, with the intentions of coming back to it later.

XP is not for everyone. If your product requires a large, complete specification, or you are integrating the work of several subcontractors, XP's iterative approach won't fly. There are times when tradition must prevail.

XP's greeting card logic (Communication! Simplicity! Feedback! Courage!) is cold comfort if only a few of the practices are implemented. If they are incorporated as a whole, I think you'll find your job easier. Instead of acting as project police, you could focus on your day job, true configuration management.  If these practices were adopted by our industry, we'd see a sea change in our maturity levels, and in the quality of our work.  

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment