Fog Creek Software
Discussion Board




XP development is biting me in the...

A$$!!!!!!

I am trying to incorporate some XP methods into a "new" project I am working on.  I have a base framework that our software runs from.  So when a new client signs up, we customize certain GUI parts and some logic to accomodate them. 

We have a new client and I wanted them more involved with this development/implementation process then we have in the past.  It's a good thing I did b/c my initial specs (from my boss) did not all match what she wanted.  My company has a bad habit of writing contracts first, specs second.

So here is my problem.  The client is a crazy b!tch!!!!!  She is now arguing, I believe, for arguments sake.  Iteration #1 was supposed to be completed 6/14.  We are still trying to button it up.  After I finished developing this iteration, I sent her a test form to complete and accept so that we could move on.  The first time she filled it out, she failed us on EVERY TEST.  Some of the problems:

1.  Data is ordered in alphabetical order (A, B, C) she has a special order that she wants to apply (B, C, A).  These were not explicityly discussed in the specs.
2.  Remove these particular items.  These items would later be added back in.
3.  Take this button out of the GUI because it confuses me.

The problem with telling them that Request #1 is out of scope is that they think it should be a simple fix (which is sort of is).  However, stack 10 to 12 fixes on top of each other and now we are adding serious hours.

My concern is that eventhough I want her to be happy with the system, if it takes 6 months to do a 6 week project, she will be unhappy anyway.  We spent a long time and several meetings on specs with screenshots in order to avoid this.

This is a very angry woman.  The uses a lot of yelling in here emails to get a point across (i.e.  WE ARE NOT DOING XYZ!).  I'm afraid I opened a can of worms here.  However, I don't think it's the method but the client.  How do I let her  control the project yet still guide her in the right direction?

We currently have a slew of marginally happy clients due to a very poor spec/contract process.  I am trying to improve this and learn some things along the way.

Thanks

shiggins
Thursday, July 01, 2004

XP is iterative...so go ahead and iterate ;-)

...
Thursday, July 01, 2004

Time to get the vaseline out...

Ooops
Thursday, July 01, 2004

Oh dear.

Sounds as though you'll need to capitulate and give her what she wants. I suspect that even if she was more involved in specification from the start she would still be a tough customer to deal with.

Good luck!

TheGeezer
Thursday, July 01, 2004

don't give your soul to this project. and remember that customer is NOT always right. there are people you do not want as your customer. decide on this and act based on that.


Thursday, July 01, 2004

Spend a day going over the email history and document every instance where she requested something that was either a change from the original spec or not in the original spec at all.  Come up with a rough estimate of the total billable hours these changes/additions entail.

Send an email to your boss with all of these emails and the total extra billable hours.  Ask him how he wants you to handle this.

Alternatively, tell her that her requests are either changes to or additions to the original spec and that she will have to clear them with your boss before you can do them.

Alternatively, tell her that you can make the changes in the next iteration.  Then do your best to "accidentally" not do them if they don't make sense.

Should be working
Thursday, July 01, 2004

If the client is going to be unreasonable, you've got to become a stickler for following the contract and specs.

Sounds like a sad company where a developer has to manage the client.  If you're putting up with that crap you may as well be a consultant.

And never ever agree that something is "small" or "easy" to do.  That's client-speak for:  you'll do the work for free.

brad
Thursday, July 01, 2004

Building custom software is like building a house, kitchen or similar.

Ask contractors about their customer for whom they build a house or kitchen and they will tell you the same stories.

Moral of the story: Its not going to change, only thing you can do is to take a job where you don’t have to deal with the customer. So be the bricklayer / painter (coder) or contractor (developer).

somemorone
Thursday, July 01, 2004

Should...

I like you suggestion.  So let me ask you this.  After our specs were done we created a formal document.  She call with a request that could really derail this whole project.  I said "not in the spec".  Not only was it not in the spec, but it was never discussed in any spec meeting.  The client understands this.  However, it IS in the contract.  Thus my effort in trying to break the contract first/spec second process.

How would handle it? 

Also,  can anyone recommend any good books (in addition to Joel's list) on software management.

I work for a bunch of yahoo's who don't get it and the only way for me to shine is to take control and make sure every aspect gets done right, not just the programming.

shiggins
Thursday, July 01, 2004

brad,

You hit the nail on the head...now somebody please hit me on the head and put me out of my misery ;)

shiggins
Thursday, July 01, 2004

OK, please forgive my poor grammar.  I'm typing furiously (literally)

shiggins
Thursday, July 01, 2004


The problem isn't XP development; it's a problem of poorly managing the client and their expectations. Are you both the developer and the primary interface to the client?

Had you not kept the customer in the loop, the problem would have been compounded ten-fold when you delivered the final product and it wasn't even close to their expectations.

Sounds like someone from your company is doing a lousy job of controlling the client. Clients will bitch, scream and moan if they think it means that they can get free work done. That's just the way it is. Someone from your company has to be firm, polite, but firm and tell the negotiate with the client on how to handle these clearly out of scope items.

As someone else has mentioned, there are some clients that are not worth having. I've had my share of clients that want the world, but don't want to pay for anything. It's much easier in the long run to just  smile, tell them the relationship isn't going to work out and wish them the best in their business. These types of clients will cost you money; not earn you money. Dump them. And fast.

Of course, in your case it sounds as if you work for someone else and that decision isn't going to be yours to make. My suggestion is to start raising a ruckus internally and get someone held accountable for holding this client in check.

Good luck.

Mark Hoffman
Thursday, July 01, 2004

It is not XP development, this is a social issue with your customer. I joke about one of the bigger projects I worked on with someone who was sort of like what you are describing. I call it the pornography method of software development, after a supreme court justice said "I can't explain it, but I know it when I see it." You will always get bad or incomplete specs.

A dialog with a customer who uses the PM method goes something like this:
Them: Make me a hoo-hah.
Me: Yes, sir/madam!
(later, showing them the hoo-hah)
Them: you idiot! What sort of idiot makes a blue hoo-hah!
Me: um, yes, sir/madam. What color would you like?
Them: green.
(later, showing them the green hoo-hah)
Them: (lots of four letter words) What kind of idiot makes a green hoo-hah?
Me: um, yes, sir/madam. What color would you like?
Them: Don't you know the legal/company standard is for a blue hoo-hah?

In short, I don't jump up and down and tell them they are idiots. Doesn't matter if they are or not. There may have been some new improved Sarbanes-Oxley or HIPAA act that came along. Or, like most of the time, they did not know what they wanted when they started the project. Being able to listen to what the customer and to what the end-user (they ain't the same) wants and need, is a real life and budget saver.

The last project I had like this lasted 18 months. The project was budgeted for 4 months, but it had so many examples of the above dialog, that my boss asked if I could deal straight with the customer (he was about to quit in frustration). The customer sort of knew what she wanted, but was unable to articulate it (orig specs were 1 page plus 2 mock up screen shots in excel). And like in your project, things came out, then went back in repeatedly. Sure, she was real happy at the end.

Why do I put up with screaming customers? Because stuff rolls downhill: their boss/wife/dog may have jumped on their case. Or they may have been confused like the above example (I put up with her because she was real cute). She had the power to fire me, my boss, my bosses boss, and pretty much anyone she disagreed with.

If you can't handle screamers, then may I recommend you take a part time job at a fast food restaurant. Try to get on the drive thru window, you will really learn how messed up things can be. It will also teach you the patience to deal with them. If not, we will be seeing you on the news one evening. Handling the customer is the real job of the project manager, not making pretty little gantt charts.

Recommended books:
Peopleware
Death March
Under Pressure and On Time
Software Project Survival Guide

Movies:
Office Space

Peter
Thursday, July 01, 2004

Is your customer onsite? If so, these issues should have come up early in the iteration. If not, these changes are new user stories - stick them on cards, make your estimates, have the customer prioritize the stories, later, rinse, repeat. If she's failing you on the acceptance tests by changing them after the fact, sounds like you have a bad client who's not dealing in good faith. Kick it upstairs to management, the lawyers, etc.

Michael Ealem
Thursday, July 01, 2004

Peter,

Thanks for the book recommendations.

"Handling the customer is the real job of the project manager, not making pretty little gantt charts."  However, I am not the PM, I'm the developer trying to help the PM do his job so we all don't come out looking like idiots.

shiggins
Thursday, July 01, 2004

Sorry...I don't think I made this clear.  I am the programmer.

shiggins
Thursday, July 01, 2004


"Sorry...I don't think I made this clear.  I am the programmer. "

You meant scapegoat, right?

Tada
Thursday, July 01, 2004

Sounds like my last job... lemme guess - you work for a teeny mom & pop services shop ?

There is no solution, alas.  It's far too late for you to escape the trap.  Next time, let your PM deal with this.  If your PM can't handle his / her workload, he / she needs to communicate that up the tree.

You can't fix your company - you can only CYA in these positions.

Sassy
Thursday, July 01, 2004

shiggins, you have all our condolences. This is a horrible situation and you won't be able to win.

You need to get external involvement, such as hiring some specialist to come in and arbitrate.

Said specialist talks to customer, talks to your contract writers and then talks to programmers, and then goes and gently explains to customer that she's got six months work while paying for two, and that there is actually quite a bit of work in writing xyz.

Must be a Manager
Thursday, July 01, 2004

Your manager sucks.  But you already knew that.

 
Thursday, July 01, 2004

It sounds like the issues are mainly UI issues. Hire a user interface consultant, someone along the lines of Jeff Johnson who wrote the book, "GUI Bloopers".

Derek
Thursday, July 01, 2004

This customer will never be on-site and nobody
can be their proxy. So it's kind of an unrealistic
requirement for sucess.

Anon
Thursday, July 01, 2004

success is an unrealistic requirement ... sounds like a Dilbert frame

 
Thursday, July 01, 2004

So your contract is a problem, and the client is a problem.  The question is, do *you* have a problem.  I'm sure you want to do right by your company, you don't want to see them take it on the chin.  You also don't want to take it on the chin yourself, either by having to deal with this client for the next six months or by looking like you're the problem to your superiors.

This is a delicate situation, and how you handle it depends on what kind of relationship you have with your boss and the company, how much you're willing to put up with, and what you want to see happen.  A few thoughts:

Look for an escape clause in the contract that lets you get out of this without taking a huge hit.  Be creative in your interpretation of the various clauses.  Maybe you can renegotiate the contract; maybe you can point to the spec as the authoritative document; maybe you can bill for work beyond a certain point; maybe you can find a way to render the contract null.  You might hand it to your legal counsel and explain the situation to him and see if there is a legal angle you can use.

If none of those options exist, you might "take the hit" on this contract and allow it to be a learning experience for the whole company.  Pain is an incredible motivator... if the company suffers enough on this, that will effect a much greater change than anything you can do.  If you do take this route, make sure you document everything and keep your boss informed so it doesn't look like you are the problem.  Also, make sure you do NOT pull any fingerpointing or scapegoating maneuver that makes it look like you're blaming anyone else.  You want to make it look like you did your best to satisfy the client without hurting the company, but the way the contract is written it says you had to do X and so you had no choice but to do X.  If possible, notify your boss about requests that will cause serious problems or otherwise take a lot of effort, and make him be the one to tell you to go ahead and do it.  (And, if he's on your side, he will kick it further upstairs.)

As for dealing with the client, do your best to work with them.  With angry people, a good strategy is to let them do 90% of the talking -- let them vent all their frustration and just listen (without getting worked up yourself), and then once they've calmed down go into the "let's all work together and see what we can get done" routine.  Often, 90% of the "problem" is just that they are frustrated and need someone to talk to.

Does any of this make sense to you?

Should be working
Thursday, July 01, 2004

I hope I live 50 more years and dream of a Star-Trek life lifestyle where everyone is on a quest to explore strange new worlds and it will the future so everyone will be smart enough to know when they are adding to the group or just being a pain like the client you speak of.  And while we may never get to this point where everyone is soft-spoken and intelligent sounding,...... it always helps to keep an updated resume in case you can't take it anymore and have to abandon ship.

Berlin Brown
Friday, July 02, 2004

If you're *really* doing an XP process, then the solution is for her to put the request in the planning game. How long are your iterations? If more than three weeks, they're too long.

Where are your customer story cards? If she's failing you for stuff that's not on the cards that SHE AGREED TO at the start of the iteration, there's not much more you can do other than say "Ok, let's put it into the next iteration" and do your next planning session.

If she's making stuff up out of her ass, you're pretty much screwed regardless of process, alas.

Chris Tavares
Friday, July 02, 2004

Whatever you do, do NOT let your boss (or whoever made the contract) weasel out of this - not because he deserves to get some crap, but because otherwise he won't learn, and will make a similar contract the next time and you'll be in the same mess again and again. Learning is important. He needs to learn the development realities just as your customer needs to learn them, and while we're at it, maybe you can learn something too (I'm not saying you've done anything wrong, but just that learning is a positive opportunity that should always be taken).

So drag your boss to all the meetings with the customer, and when you explain things to your customer, make sure you explain them to your boss as well. Also, discuss with the boss about the contract, and see if you can make him understand what sort of things are not good - and most importantly, why.

You'll probably never get this project on the "wins" list directly, but if you analyze every step carefully enough, you may avoid similar situations in the future. And don't despair; it's only one project.

Antti Kurenniemi
Friday, July 02, 2004


It sounds like the problem isn't necessarily XP, you just have a crazy client.

If you have your functional requirements figured out, meet with her concerning *purely* look & feel issues.

After you have that, treat them as regular requirements/stories and start fitting them into your iterations.

Try to get her to realize the difference between "it doesn't work" and "I don't like the way it looks".  I know this is tough, but it will help you out in the long term.  Maybe you can seperate them on the evaluation form?

KC
Friday, July 02, 2004

i don't want to blatantly just blame XP and the methodology (a lot of people blame CMM but a lot has to do with whom/how it is implemented).

My understanding with XP is that you should welcome change. So you have say 2 week iteration cycles, and they can change all along. But, at the end of the 2 weeks you deliver whatever you can.  Paired programming, user involvement, etc.

Would it be possible to get a firm date in the cycle where any requests after that would not be considered? Maybe, the Wednesday of the 2nd week?

just a thought.

Patrick
Friday, July 02, 2004

Judging by a lot of these responses, a lot of IT guys really don't have much experience with the big wide world. Guys, there are people who don't give a flying fck about use cases and XP stories and contracts.

tree
Friday, July 02, 2004

that i agree with! I personally just quit working for an investment bank (where i felt like a b*tch) to a software development company. True, now i have 80 client groups . But, we dictate to them how software will be developed.

Patrick
Friday, July 02, 2004

Sassy - Yup

Should - Absolutely.  I have been letting her vent.  The more bitchy she gets, the more understanding I am.

Chris - Regarding the story cards, our problem seems to be interpretation.  For example, data items A, B, C, etc must be displayed on page X.  She assumed that they would be ordered B, C, A and I ordered them alphabetically.  If I go back and say her ordering scheme is out of scope, her response is "WHY IN THE HELL WOULD WE WANT IT ORDERED ALPHABETICALLY?"  Any suggestions on that?  Did I we not make our user stories detailed enough maybe?

Antti - You're right.  A huge part of the problem is my boss.  He doesn't manage well and doesn't want to learn how to manage well.  However, if I force him to be part of these discussions maybe that will help.  In the past, though, I've found that when I involve and try to guide him in project management, he ends up relying too much on me.  For example, in this project I told him about and out of scope problem that maybe we needed to escalate and that he should call Bob and discuss it.  He called me back and said "Should I call Bob and Joe?"  FOR CRYING OUT LOUD IN THE SOUP!!!! He can't even make a simple phone call without my input.  He totally uses me as a scapegoat so I am very leery about giving him direction.  Because if a mistake is made he goes to the PHBs and says, "Shiggins told me to".

KC - Excellent idea.


My iterations are 1 week, fyi. Thanks all sooooo much for your input.  It really helps.  I've though about jumping ship a lot.  But I just recently started school again to finish up my BS.  It'll only take a year and I figure it will be easier at a company where I know the ropes.  Maybe I'm wrong.

shiggins
Friday, July 02, 2004

Regarding your boss, you need to get yourself very clear about what's *your* responsibility and what's *his* responsibility.  If he calls and asks "Should I call Bob and Joe", the proper response is "That's up to you."  If he asks for a recommendation or what you would do, tell him you don't know since you're not in his position.

In short, give him the opportunity to either step up to the plate and learn how to be a real manager, or fail to do so.  Just be careful about documenting things so he can't scapegoat you.

About school and work: while you know the company you're at, it sounds like it's a fairly stressful environment.  This does have an effect; consider looking for a less stressful job while you're in school.  And good luck, BTW.

Should be working
Friday, July 02, 2004

You mention XP, but I'm not clear on one point, is this crazy person you are having problems filling the Customer role (in the XP sense)?

http://c2.com/cgi/wiki?TheCustomer

If she is, then have you been able to use XP to "control" her? If not, then who is the Customer?

Bill Tomlinson
Friday, July 02, 2004

Bill,

Crazy Betty is the customer.

"If she is, then have you been able to use XP to "control" her? If not, then who is the Customer?"  - I'm not sure what you mean by this.  This is actually my question.  How do I control her?

Thanks

shiggins
Friday, July 02, 2004

I mean, is she doing the things that an XP Customer is supposed to do? From the web page I included:

- Writes and explains UserStories.
- Specifies FunctionalTests.
- Sets priorities
- Views CRC sessions.

Does she understand XP and what her responsibilities are as Customer (and buy into that)?

Perhaps "control" was the wrong word. I just had trouble seeing how someone who was *really* doing the XP role of Customer was causing that much of a problem.

But, admittedly, Customer is the hardest role in XP and the place where a lot of XP projects fail, IHMO.

Bill Tomlinson
Friday, July 02, 2004

Bill,

- Writes and explains UserStories. - Yes
- Specifies FunctionalTests. - No
- Sets priorities - Yes
- Views CRC sessions. - No

We are implementing half-ass XP.  I had a very hard time getting my boss on board with just communicating at all during the development, so I am not pushing a full blown XP process.

However, I don't think the problem lies there.  I think it lies with the customer attitude.  You said yourself that's where many XP projects fail.

shiggins
Friday, July 02, 2004

I apologise. I got a little defensive because your topic heading was "XP development is biting me in the ass". But then your description didn't really sound like you are doing XP (which, with all due respect, I would say you aren't[1]) but rather that you had a difficult customer (in the general sense of the word customer, not in the XP sense).

If your topic heading had been "Difficult customer keeps changing her mind, what can I do?", I think you might have gotten a different conversation here.

On that topic; sorry, it doesn't help much, but I'd tend to agree with the previous posters who said that it's pretty much too late at this point for you to recover. It's a little too hard to change the process in the middle of development; you've already established too much precident for accomadating her behaviour. I'd suggest keeping your head down for now and instead try like crazy to mark a clear finish point and then try to improve the process before the next product/contract/release.


[1] I'm in the camp that believes that you have to do practically all of XP to count as XP; and that several of the individual XP practices can be dangerous if done on their own without the full XP framework to support them (eg. someone writing user stories but not specifying functional tests for them).

Bill Tomlinson
Friday, July 02, 2004

Thanks for the info Bill.  I though there were those that said you can implement components of XP before committing fully to the process.  However, what you said has made sense.

The trick now is getting my boss to get on board, despite this miserable first attempt.

Regarding the title, that was my lame attempt at sarcasm:)

shiggins
Friday, July 02, 2004

Sarcasm in that it is clearly not the method but the client, IMHO.

shiggins
Friday, July 02, 2004

There's differing opinions in the XP camp about wether you you can use just some of the practices, or if you need to apply them all. There are interesting arguments either way.

Though I did think of another approach to your problem. The software development office can be a dangerous place. Accidents happen...

Here's some inspiration:

http://www.theregister.com/odds/bofh/

Bill Tomlinson
Friday, July 02, 2004

*  Recent Topics

*  Fog Creek Home