Robert Scoble, Microsoft Blogger extraordinaire, has just helped to build a Longhorn project. But the more interesting aspect of the venture is that M. Scoble took part in an Extreme Programming exercise. Extreme Programming is a bottoms up approach to development that emphasizes producing working code as soon as possible as part of the development process. In fact, Extreme Programming has 12 key practices, 4 each for Coding, Developers, and Business.
Robert got to see the effectiveness of XP – eXtreme Programmings use of pair programming in a mentoring situation. All developers working on an XP project are paired. This is one of the practices of XP that gets the most refactoring/modification/requirements change( one of the other tenets of XP is that it must be responsive to changes in requirements – danger, danger Will Robinson).
As anyone who has worked on an XP-based project will know – XP is sort of like one of those Greek heros, say Achilles. Full of good ideas and intentions but also tragically flawed( what a heel). For example, emphasis on test first development – i.e. users design with tests or measures of fulfiillment on every step of the IT project way can sometimes lead to rote, repetitious testing. Or the emphasis on active participation by users/customers is very good idea in theory. But XP does not spell out how to use most effectively those end-users and how to negotiate efficiently when the customer/project sponsor inevitably short changes on the time and/or quality of the customer agents (you will definitely need more than one for any project beyond small).
XP-ers are sometimes seen as Coding Cowboys turned into PacMen – charging down the path eating up programming problems right, left and center, spewing out working code and sometimes munching themselves to success and othertimes buiilding a programming edifice of no duration. Fortunately, Barry Boehm and Richard Turner have written a book , “Balancing Agility and Discipline: A Guide for the Perplexed” which tries to sort out and expose the trade-offs with using XP versus say the RUP or other IT project management frameworks. They manage to :
a)highlight some of the key advantages of XP and broader agile methods;
b)underline some of the key trade-offs between XP/Agile and RUP/Disciplined;
c)provide some guidelines and trade-offs for when to use XP/Agile versus RUP/Disciplined.
The book is far from perfect; but like XP itself, it has many virtues and points to better ways to do IT development. This reviewer is now looking for an IT Process/Project management book that successfully and succinctly incorporates the world of politics, negotiation and management of change into the IT Project Management space .