CoursePages. DpS2007. DcS801821. DiscussionForums. AgileSoftwareDevelopment.
ExtremeConsulting

In Jim Highsmith's interview with Kent Beck, Kent introduced the idea of 'Extreme Consulting'(XC). With Extreme Programming(XP), we have the notions/practices of refactoring,test-first development,coding standards, person to person communication / collaboration and the right environment to support of of these. Do you think there would be parallels with between the practices XP and that of XC ? What could these potential practices for XC be ?


In the consulting world, consulting engagements are based on contracts (fixed price with a fixed delivery date or time and materials type of contracts) which makes the environment different than being in a product development or an infrastructure support type situation. However, one could have a contract based on specific delivery of features - let the customer determine what has the features are and the features with the most value that they want delivered sooner as opposed to later. Then, just like XP, have short delivery time frames in which the team demonstrates the work done on the features specified for that delivery cycle to the customer. The customer evaluates the work done and the team either proceeds to the next delivery cycle or works with the customer to replan for the next cycle based on information they now have. In this delivery feature type contract one would need to specify that a knowledgeable customer needs to be a part of the team in the same manner in which the customer is part of the team in XP. By knowledgeable customer I mean someone in the customer’ s company who has worked in the domain a and understands very well all of the processes that will be supported by the application being developed. As far as some of the other practices in XP such as coding standards, test-first development, refactoring, etc. these are primarily concerns for the development team that will individuals in the consulting company. These individuals can chose to work in this manner to develop the software. (Anne M-W 11/14/04)

Anne - I respectfully disagree re: consulting and XP. We had MANY fixed-price contracts with various customers that were very successfull technically, yet customer management was not happy. The reason - if in consulting world you have a contract, it's in your best interest to get work done as soon as possible and leave. The companies usually send their best employees to such contracts, so they can do work faster. Since those individuals have performance 6-8 times faster than the average person (see Mythical Man-Month), the client gets a feeling they have been cheated, because if they divide total amount to number of hours, they get "outrageous" hourly rate. So, most prefer T&M basis, hence get "average" or "below average" consultants - paying even more as a result (as the work is done slow).

Here are some numbers for comparison (not rates charged or used by my current or previous employer; just an example) -

Suppose there is a specialized database install and config project. Let's say the fixed cost is $10000. The average person may make this work in about week-and-a-half - including any issue that would appear. That translates to about $150/hour which may be considered "average" for such work.
Suppose that the BEST consultant can do this work in 3 days working 8-hour days. Now we have a rate of more than $400 per hour.

The question may be - why do you not always employ such consultant and offer them let's say $250 per hour? First, such people are rare. The industry may have a dozen of them. They may be busy etc.
Second, accounting department would ask why the hourly rate here is high.
Third - there is a chance they get such person for $150 per hour anyway (if such person works for a company and not for themselves)
Also - such person may simply not be known to a customer. They go to application vendor for help, and a vendor suggests them a company they have a relation with, not the best and fastest person to do a job.
In addition there is an issue of future support. Most companies will never do a one-off project. They want developers or implementors to be available later - since original people are already familiar with business, hardware and software of the customer, so there will be no learning curve.

Most consulting companies prefer their best employees to "take their time" on projects thus making them work with a speed of an "average" employee. That translates into some sort of "hidden overcharging". I call this a "consulting paradox" - the better you work, the less you get paid. Fixed cost bids help with that, but customers do not like those for the reasons I stated above.

(Alex T. 11/14/04)

Alex, I wasn't trying to comment on the merits of fixed-price versus time and materials type contracts in my posting. On the contrary, I was trying to answer the question that was posed regarding the parallels between XP and XC and what potetential practices could be for XC. In his book entitled Agile Software Development Ecosystems Jim Highsmith discussed how Agile approaches could be used in contract type situations. (Anne M-W 11/15/04)

There seems to be a conflict, at least to me, with a point Anne expressed about short delivery cycles in XC vs what a consultant needs to do. How does one come up with advise, which is what a consultant does, to a client piece by piece for the client's organization if the consultant is tasked with finding out what are the problems in the organization and should recommend solutions to these problems? Shouldn't the whole picture be considered first?
To me, if the whole picture is considered, then 'short delivery timeframes' seems impossible. The implementation of the advice, however could lend itself to short deleivery timeframes. (Kay 2004-11-15,11:31AM)

Conflict between Anne & Alex;
Bottom line is each case is different, Anne and Alex provided examples where XC and XP practices run parallel along with it’s potential effective uses.

Depending on organizational size, problem size, openness to XP practices and resources available to the consultant will dictate the success or failure of XC and XP practices.

(C. Pankey - 11/28/04)




Old capture below : PLS DO NOT ADD NEW COMMENTS BELOW


In the consulting world, consulting engagements are based on contracts (fixed price with a fixed delivery date or time and materials type of contracts) which makes the environment different than being in a product development or an infrastructure support type situation. However, one could have a contract based on specific delivery of features - let the customer determine what has the features are and the features with the most value that they want delivered sooner as opposed to later. Then, just like XP, have short delivery time frames in which the team demonstrates the work done on the features specified for that delivery cycle to the customer. The customer evaluates the work done and the team either proceeds to the next delivery cycle or works with the customer to replan for the next cycle based on information they now have. In this delivery feature type contract one would need to specify that a knowledgeable customer needs to be a part of the team in the same manner in which the customer is part of the team in XP. By knowledgeable customer I mean someone in the customer’ s company who has worked in the domain a and understands very well all of the processes that will be supported by the application being developed. As far as some of the other practices in XP such as coding standards, test-first development, refactoring, etc. these are primarily concerns for the development team that will individuals in the consulting company. These individuals can chose to work in this manner to develop the software. (Anne M-W 11/14/04)

Anne - I disagree (as stated here - http://dps.csis.pace.edu:8077/CoursePages.DpS2007.DcS801821.DiscussionForums.AgileSoftwareDevelopment ). In my career the original QUOTE was kind of a fixed-price, with a full uunderstanding that this is just an estimate. As I said, customers are almost always unhappy at the end of fixed-price engagements.
(Alex T. 11/14/04)

[ User Guide] [.FrontPage] [.RecentChanges]