File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Agile and Other Processes and the fly likes How to convince management to use 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 "How to convince management to use XP" Watch "How to convince management to use XP" New topic

How to convince management to use XP

Peter Tersteeg

Joined: May 12, 2003
Posts: 3
We're commencing a new project and the company I work for is very process oriented. We have the basic requirements and breakdowns for the various components of the project, but we're required to go through extensive analysis, requirements, design, development, acceptance, etc phases.
Each phase has a lengthy review process which in the past has tended to be a bottleneck as it's up to a few senior engineers to perform the reviews.
Another problem that occurs is that as components are specified and designed at different rates, they tend to impose requirement and interface changes on other components. This usually mean we have to update the requirements analysis and the design, going through the review process again before we can even think of updating the code.
Management requires us to go through this process primarily for tracibility reasons, whilst a few on the team believe an XP approach would allow us to build the product a lot more efficiently. Are there any tips on how to approach management about using a XP?
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Well, that really sounds hard...
Why do you think *is* management persisting on this process? What value do they see?
You probably can't convince management by saying "XP would be better". Instead, you should try to find out how management could get more value by applying XP (or other) principles. Give them alternative options and let them decide what to do.
Hopefully, with time some things will work better that way. Than you might say "Those things we have shamelessly borrowed from XP (whatever). We might want to dig deeper into it to see if it can provide even more value." Always keep in mind that the goal is not to implement XP, but to improve your software development process.
Some articles at might give you more ideas.
Hope this helps...

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
Stefan Maric

Joined: Sep 12, 2001
Posts: 8
You should talk to your Quality Team - typically they OWN the standards. BUT that doesn't mean standards cannot be changed
It just has to be done in a structured & controlled manner
You will probably need to identify a small (non-critical path) section of a Project & define an alternative proposal based on XP practices
You will have to somehow show how XP will be a better way of doing things
If you can identify 2 similar sections of your project then you may be able to get a comparison
REMEMBER though first (& all) itration of XP isa learning experience
Gavin Bong
Ranch Hand

Joined: Apr 25, 2003
Posts: 56
Each phase has a lengthy review process which in the past has tended to be a bottleneck as it's up to a few senior engineers to perform the reviews.

You said that only a few of your team members favor XP. Does that imply that only a portion of the team is suffering from the process while the rest is silently contented with it ? This smells like a team communication problem.
How successful is your team in delivering past projects using this "process" ? Who are your clients - internal or external ?
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
Originally posted by Peter Tersteeg:
Management requires us to go through this process primarily for tracibility reasons...

Unless you can find a way to address this issue, it doesn't matter what the team wants, or whether XP is a better way to get things done.
If you want to change things, you'll need to find out why tracibility is important, and either get Mgmt to change their view (possible but...) or figure out how to give them what they need while improving the process for the team.
Good luck with it,

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

Joined: Jan 23, 2002
Posts: 11962
Peter, I assume you're talking about "requirement-to-code-to-requirement" kind of traceability?
I don't think XP prevents this at all. You're free to exercise change management as you please. As Burk suggested, the first step should be to figure out how the current process supports this "traceability" and go on from there.

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Mark Herschberg

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Peter Tersteeg:
Each phase has a lengthy review process which in the past has tended to be a bottleneck as it's up to a few senior engineers to perform the reviews.

I can't tell you how many manager don't understand the concept of phasing teams (this is one area where consulting firms do quite well). Manager tend to see all engineers as the same. The reality is (warning: generalized numbers, just to give an example), during the last 10% of the project the architect don't need to be as involved and can start focusing on the next version or the next project. Unfortunately, most managers think the architects can't move on until the whole product is shipped. Could the process be changed simply to better optimize the time/skillset combinations?
I'd alo like to remind you of a comment made by Fred Brook's. In The Mythical Man Month he talks about a project he ran where two groups were both asking to do the upfron design. One was a small team of architects (about 30 in size); the other was the full engineering team, about 1000 people in size. Brooks gave the design to the latter, feeling that he couldn't have the latter sit on their hands for 2 months while the architects came up with the design. He regretted that decisions because, in short, too many cooks spoiled the broth. The reality was, the project as a whole would've been better off if those 1000 engineer had sat on their hands! Of course, better ye, during those two months, they could prototype different ideas, train in new tools, refactor old code (oh, my mistake, I'm sure the old code in your company is spotless), career development, skill sharing, building reusable component libraries, etc.
So you may want to look to other means of improving your process, aside from XP.
I agree. Here's the link:
subject: How to convince management to use XP
It's not a secret anymore!