jQuery in Action, 2nd edition*
The moose likes Agile and Other Processes and the fly likes Stealth XP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Stealth XP" Watch "Stealth XP" New topic
Author

Stealth XP

Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
I was wondering if anybody out reading this is using XP under another name - I've spoken with several managers and it seems the word "Extreme" has a dampening effect on their enthusiasm for the process.
The other issue that regularly bring up objections is, of course, Pair Programming - I won't go into it here bacause I see there's already a thread on that topic, but it sure seems to draw heavy fire from the bean counters.
Anybody care to share a story on how to introduce XP to an organization without scaring management too badly?


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Burk Hufnagel:
Anybody care to share a story on how to introduce XP to an organization without scaring management too badly?

Don't introduce it, do it
No, really. If there's a project of which staff agrees that XP would be beneficial for them, I can't see a reason why they couldn't use XP. Unless the project manager isn't one of the agreeing ones, of course.
Just to make sure that you don't get fired when the project ends up being late for some reason not even closely related to you using XP or not, I'd suggest having the project manager negotiate with higher levels without stressing "extreme programming" but simply talking about a "new, agile process which we'd like to prototype in our organization." I don't think the upper management will be interested in arguing whether XP is good or not -- they need to hear that it has worked for someone else, preferably someone they know. A big name.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Eduardo Resende
Greenhorn

Joined: Feb 02, 2002
Posts: 10
I agree with Lasse, I think the programmers should have the decision on using XP or not, and show the main benefits to the project manager, which main interests are: quality and schedule.
Att.
Eduardo Resende
Sun Certified Programmer for the Java 2 Platform
Sun Certified Developer for the Java 2 Platform
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Burk Hufnagel:
I was wondering if anybody out reading this is using XP under another name

Well, XP is in the agile process family, right? Call it an agile process? It makes them think of lean and nimble.
Originally posted by Burk Hufnagel:
The other issue that regularly bring up objections is, of course, Pair Programming...but it sure seems to draw heavy fire from the bean counters.

Yeah, many people have a hard time understanding the concept of clear upfront costs coupled with hard to measure ROIs. The ROI actually isn't that hard to measure, its just that most managers haven't a clue how to do it.
Personally, I recommend coding games. Have a few teams a programmers tackle the same project. Some do pair programming, others do not. See who does better. Show the results to management.
The hard part is finding soemthing the right scope. I recommend looking at the work of Tom DeMarco and Timothy Lister, who have run such games for years. In short, you want something that takes about 2 full days, and produces easily measurable output. (Some textbooks or Java books might have good sized projects towards the end of their books.)
--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
Personally, I recommend coding games.

I'd like to point out that this approach subject to strong influence by the developers you put into the game. If none of them have XPerience (sorry, had to do it), the XP team will suffer from the learning curve.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
I want to add one more general comment. If there is a group of developers who see something of value, they should be able to talk to management about it. Management should listen to their reasons and make a rational decision. I think there's sufficent evidence to suggest that XP and pair programming are not hair-brained schemes, such that if enough programmers are serious about it, and can articulate their arguments (many can't), management should listen to them and let them try it, or offer compelling reasons why they can't (e.g. critical market window, we can't afford the risks inherent in changing methodologies right now).
So what happens if the developers do want this and management refuses to listen? You should quit, plain and simple. (Obviously there are levels in between you should explore first.) Basically, if you feel that you need to deceive management in order to do what's effective, your team/division/company has serious problems. Run! Run away quickly. If you cannot have open and honest communications with your managers, if you must hide techniques which you believe are effective, the company culture is one which will doom its projects.
(For the record, I practice what I preach. I quit my job in Nov 2001 because the group was mismanaged and my suggestions for well-established process improvements went unheeded.)
--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
On the other hand, why so you need to ask management to do your job the best way you can? Do you also ask them wether to use for- or while-loops?
Seriously, just do it - in a way management can tolerate it, of course. That is, do it a little first, perhaps on hard tasks. Let management acclimate - and let them feel the results.
It might take years to get even near to "full XP" this way - but depending on circumstances, it might be better than quitting...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:
On the other hand, why so you need to ask management to do your job the best way you can? Do you also ask them wether to use for- or while-loops? ;)

You know, the more I learn about management, the more I respect the job (although not necessarily those who practice it). Engineers don't know everything going on in the company; the don't always have the larger picture available to them. It is the job of the manager ot protect and filter them from the noises from outside the group, and likewise communicate for the group to the outside.
Obviously you don't tell you manager everything you do, but the process you're using is important enough that the manager should be aware of it (which is different then dictating it). What if the group decides a new OS is important to increase productivity, should they all just swap the OS on their machines without telling management?
--Mark
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
If "extreme" is the problem, just go "agile." Or some people are borrowing from manufacturing and going "lean".
I'm a stuck record here - I always recommend Alistair Cockburn's book on agile development. He compares and contrasts a number of agile methods in a nicely balanced way. You can pick and choose, get all the goodness of XP without sounding like a sk8trboy.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
Obviously you don't tell you manager everything you do, but the process you're using is important enough that the manager should be aware of it (which is different then dictating it).

I'd say the need for management to be aware of, or the level of awareness about the process is also dependent on the way XP is used. If the team is using "XP as a process", management should take part in the discussion. On the other hand, if the team is using "XP as a set of best practices", a small subset of relatively unintrusive key practices, it starts to be rather insignificant from management point of view.
Has anyone been under a micro manager who monitored his team members in order to make sure that they don't write the test before the feature...? My point is that management will not care. They only need to feel assured that XP won't do harm to performance and that they are able to produce reports/estimates/whatever to their superiors as they did before. Am I completely off track?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Don't get me wrong - I certainly respect management, too.
I just think there are some
Obviously you don't tell you manager everything you do, but the process you're using is important enough that the manager should be aware of it (which is different then dictating it). What if the group decides a new OS is important to increase productivity, should they all just swap the OS on their machines without telling management?

I don't know - depends on the circumstances, I think.
I am also all for open and honest communication with management. There are just some things I wouldn't ever *ask for permission* for - things like writing unit tests, refactoring my code and close collaboration with my coworkers.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:
I am also all for open and honest communication with management. There are just some things I wouldn't ever *ask for permission* for - things like writing unit tests, refactoring my code and close collaboration with my coworkers.

Imagine that you're in charge of a construction project to build a new office complex. Are you going to tell the workers how to pour the concrete? Of course not. But you should be aware of the techniques they use. Perhaps some types of concrete (or pouring techniques) can't be poured in the rain, while others can be. Its important for the manager to know which is being used so he can schedule tasks to optimize under certain weather contingencies.
--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
Its important for the manager to know which is being used so he can schedule tasks to optimize under certain weather contingencies.

Let's think objects for a while.
Say, the manager is an object. Now, according to good design principles, should the manager do anything related to concrete pouring techniques? No. Why not? Because he is not the one who knows most about the subject.
What I'm trying to get at is that the manager doesn't need to know the technique -- it's more than enough that a technical staff member consults the manager so that he gets the estimate on paper.
[ May 15, 2003: Message edited by: Lasse Koskela ]
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Lasse Koskela:

Let's think objects for a while.

Oh god no! Let's not.
This model works when we assume a stable system. It makes sense on an assembly line, when you don't care how the upstream part of process did something. If the manager could hand you a set of specs and computers and know that in X months the software would work, then this model is appropriate.
By definition, business undertakings are risky! They are unpredictable. The job of a manager is to gracefully handle change. The manager would need to "refactor" those "objects," and to do that, he would need to see how the objects work.
Don't even try to argue that the manager should then only look when refactoring is needed. In most cases the management action needs to be premptive, or requires speed achievable only with prior knowledge.
--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I agree that if the manager knew what he was doing, he could say which concrete to use or how to pour it. However, that kind of managers don't grow on trees and when you have one, he's got a price tag which you can't justify if he's actually spending his time doing "lower-level" tasks for his team.
Could you still clarify your view on this 'cause I'm getting the awkward feeling that I'm missing some fundamental point here?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mark, can you please give an actual software development example? I don't grok this house building or manager-as-an-object analogy stuff...
Thanks!
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Lasse Koskela:
I agree that if the manager knew what he was doing, he could say which concrete to use or how to pour it. However, that kind of managers don't grow on trees and when you have one, he's got a price tag which you can't justify if he's actually spending his time doing "lower-level" tasks for his team.

Likewise if the team had very good programmers, I think XP could still work in this case. Imagine the following situation. You have a team of 10 people, all of whom just graduated from college last week and are doing an XP project. The know Java well and were all A students. Think it will succeed?
Personally, I doubt it. I think they will miss things in overall design and as they each go about their parituclar task they'll tend to have significantly different ideas for the overall architecture of project (even without any radical shift in requirements halfway into the project). Is it just due ot inexperience? Probably.
On the other end of the specturm, you have a team of the best 10 engineers in the world. I think they could handle the project under XP, even with a sudden shift in architetcure.
As we move between the two, I think a sufficently complex architure, or equivalently (or maybe even more so), a radical necessary change in the architure during the project, cannot be sufficently handled by the XP team. For example, a particularly complex problem might not be handled well given one moderately experienced senior programmer and a bunch of entry level programmers.
You's probably agree with me so far, but claim its correlated solely to the experience of the team. However, I would further claim that an alternative process would better handle the architectural shift then would the XP process, for a certain class of problems and certain overall competency of the group.
I unfortunately can't provide a concrete example of a project that would not work under XP but would under an alternative (the worldhasn't provided me with data that clean).
My motivation for this position comes from my views that XP cannot dynamically and efficently communicate a "big picture" view of the system across team members for sufficently junior members (who seem to be quite prevalent in the industry).
--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
There is no software development process that does the work of developers for them. Of course the success is dependent on the skills of the team. I think we can safely give up on the mission of defining the golden rule of what-kind-of-team-can-make-XP-work...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
Imagine the following situation. You have a team of 10 people, all of whom just graduated from college last week and are doing an XP project. The know Java well and were all A students. Think it will succeed?

Quite likely, I think.
I have seen students doing a design using the Fusion method. It is quite formal, requiring many UML diagrams and giving advices such at "if you have a line in diagram A here, you also need to have a box in diagram B there." In my opinion, it was a desaster, even on the group I was on . Basically, the design was "full of fantasy" - we were lucky that we didn't have to code it...
Then I was on a small XP introductory project, developing an internal tool (semi-automatically parsing replies to mass E-Mails) with five entrants. We delivered the first working version after the first week, extended it as planned in the second. The most impressing was the third week, where we implemented totally unreckoned new features (having to suddenly parse emails of a totally different format) by reusing more than 50% of the code.
I have also heard of a bunch of universitary projects using XP quite successfully.
I think they will miss things in overall design

Why wouldn't they miss it if they'd do more upfront design?
and as they each go about their parituclar task they'll tend to have significantly different ideas for the overall architecture of project.

How would they if they agreed on a system methaphor?
And even if they did, wouldn't they find out very fast because of all of them being in one room, working on the same code and switching pairs often. Wouldn't the wise ones insist on settling the issue by gathering on the white board or the like?
For example, a particularly complex problem might not be handled well given one moderately experienced senior programmer and a bunch of entry level programmers.

And you think it would be better if the senior programmer just handed the entry level programmers a bunch of "complete design diagrams"???
You's probably agree with me so far

Sorry, no.
My motivation for this position comes from my views that XP cannot dynamically and efficently communicate a "big picture" view of the system across team members for sufficently junior members (who seem to be quite prevalent in the industry).

And my view is that it can, quite better than any other technique I know. (Which might simply not be enough.)
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Lasse Koskela:
There is no software development process that does the work of developers for them. Of course the success is dependent on the skills of the team. I think we can safely give up on the mission of defining the golden rule of what-kind-of-team-can-make-XP-work...

Um, why give up? If you don't know the cirumstances under which to use a tool, how can you apply it effectively?
--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:
I have also heard of a bunch of universitary projects using XP quite successfully.
...
Why wouldn't they miss it if they'd do more upfront design? <http://www.javaranch.com>

I don't think I'm getting my point across. A team a junior developers will likely fail under any method (e.g. 5 kids just out of school are unlikely to create a global accounting system to be used by a Fortune 100 company). My point is that for the marginal team will do better under the upfront design, beacuse the complex architure is communicated around the team faster upfront.
Originally posted by Ilja Preuss:
How would they if they agreed on a system methaphor?

Good point, similarly, they couldn't have different ideas if they all agreed on the architecure document at the start. if they did that, a projetc would never fail! Wait a sec...
There is no silver bullet. Up-front design will not insure proper communication and neither will a metaphor. I just think upfront design is less likely to cause confusion with a team of junior developers.
Originally posted by Ilja Preuss:

And my view is that it can, quite better than any other technique I know. (Which might simply not be enough.)

Right. This is where we disagree. Maybe someday I'll get the chance to see XP do this. For now, I'll remain skeptical.
Originally posted by Ilja Preuss:
And even if they did, wouldn't they find out very fast because of all of them being in one room, working on the same code and switching pairs often. Wouldn't the wise ones insist on settling the issue by gathering on the white board or the like?

I've seen teams where the senior engineers didn't fully appreciate the scope of the misundertsandings. He talks to Joe who misunderstands A, and explains it to him. He doesn't also epxlain it to Alice and Mike who also misunderstand it. He explains B to Mike, but not to Alice. he doesn't realize how widespread the confusion is (or takes him a while to figure it out). Will upfront design fix this? Of course not, it's not a silver bullet either, but I think if done right, it's more likely to work in this case.

Originally posted by Ilja Preuss:
And you think it would be better if the senior programmer just handed the entry level programmers a bunch of "complete design diagrams"???

Of course not. I think you're confusing my use of extreme examples (extreme as in unbalanced all the way off to the side of the process spectrum) with their promotion. I am not advocating it. I am using an argument similar to that used for the Laffer Curve.

*Laffer Curve (for taxation rates)
How can lowering taxe sincrease revenue? 0% tax produces $0 revenue. %1 tax produces $X and 2% produces $2X and so forth. But we also know that 100% tax produces $0 because then there is no incentive to work. Hence, we know that there is some inflection point at which incremental taxation reduces overall revenue.

Similarly, I show an extreme case and note an inflection point between this case an XP.
--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
This might be a better (even more extreme example)...
You have a team with 1 senior engineer and 100 entry level engineers. The senior engineer is the only one with engouh experience to make major design decisions (the others tend to be wrong at least as much as they're right). Would XP work here? (Yes, I know its designed for small teams, but humor me to get to the point.) I say no because the one person who needs to make the big decisions can't have them communicated to the team fast enough through pair programming and discussions. (I don't trust B learned it when paired with A, so that C can learn it when paired with B. Those channels can get noisy.) I think some degree on "decisions from a central authority" is needed and must be formally communicated.
Now as I noted, the example above was taking an idea ad absurdum. But if you accept the above, then can imagine scaling it down to reality. We can summarize it as follows
There exists a project of complexity C such that for some team of N senior engineers with combined ability X, and M junior engineers with combinaed ability Y (and perhaps all sorts of other parameters), XP is less efficent then some upfront design.
The example above involved N=1, X=1000, M=100, Y=50 and some Z (yes, units are made up). While these numbers are unrealistic for a team, I believe realistic numbers exist which satisfy the condition above.
--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I see your point, Mark. But I think XP would still have its place among root-level actions. The senior staff may set the general direction, but the junior developers can still achieve accelerated learning pace from some XP practices. I said "learning pace" because the overall productivity will suffer from a learning curve anyway.
Your exaggerated example setting actually could be very realistic when taken to educational institutes. Think about a lecture for 1st year students in Acme University on Software Processes. The lecturer's knowledge about the subject is probably several magnitudes more dense than that of the students on average.
With this lecture situation in mind, don't you agree that a lecture exercise would be absorbed better when the students pair up and discuss together about a problem presented by the lecturer, or would you claim that a model solution for the problem presented by the lecturer would provide the best lesson to learn?
There is no correct answer for those (rhetoric) questions. Both (team work, model solution) assist the student to grasp the issue at hand. My point is that even the shortest think-time you had before your answer would indicate that there's room for both.
But then again, I'm not really saying anything new or anything controversial to what has been already discussed... I think we're just pushing against the extremes to discover the limits, which is a good thing.
[ May 17, 2003: Message edited by: Lasse Koskela ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
We somehow managed to diverge significantly from the original topic of this thread, so lets open a new one.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
To get back on topic:
Mark, would you mind to give a rough list of XP practices that you think a team shouldn't do without informing their manager, with reasons why? Thanks!
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Stealth XP
 
Similar Threads
Tomcat not seeing setenv values in Windows 2003 Server
Node selection in JTree stops working
scrum and XP together
How to Use TOMCAT in XP prof.
Cannot start Tomcat 5.0 on XP