own sake. But even if you're not into character building like that, developing
honesty and humility is great. They give you the freedom to maximize your
potential.
Here is a stereotypical discussion between a developer and a customer in a
"traditional environment":
CUSTOMER: "I want everything yesterday, and I don't care if it kills all of your
people to get it done!" (we're paraphrasing, of course)
DEVELOPER: "Well, that's a lot of stuff. Do you really need it all? Isn't there some
subset that's more important that we could focus on first?"
CUSTOMER: "It's all critical. If we don't get it all, my butt's in a sling."
DEVELOPER: "I hear you. We are in this together. We'll get it done. You can count
on us."
A month later:
CUSTOMER: "You didn't deliver! I want this stuff now!!"
DEVELOPER: "There were some unexpected speed bumps. But I hear you loud and
clear. We are in this together. We'll get it done. You can count on us."
Uh…this is rubbish. The customer is lying to the developer. Not everything is a
number-one priority; that's being lazy. The developer is lying to the customer, too.
He's committing to something that's ludicrous, and he's doing it with a straight face.
When he fails (no surprise, really), he learns nothing and makes the same stupid
promise again. The customer acts like he believes him. It's like a big game of
charades.
What if it went like this instead?
CUSTOMER: "I know I can't have everything right now. I really don't need it. What
I really need is Feature C. Everything else can wait, but we've got to
have Feature C ASAP."
DEVELOPER: "Hmm. We have Feature B in this iteration already, and there isn't
enough room for Feature C on top of it. Should be push Feature B off
and do Feature C first?"
CUSTOMER: "Yep. That will give us what we need."
DEVELOPER: "Okay. Feature C it is. It's about the same estimate as Feature B, so
it's an even trade. We'll get it done."
At the end of the iteration:
CUSTOMER: "Feature C works great! All the acceptance tests pass, so it's exactly
what we were expecting. Can we get Feature B in the next iteration?"
DEVELOPER: "No problem. The next iteration used to have Feature C, Feature F,
and Feature G, based on the original priority order. Feature C isn't
there anymore, and it was the same size as Feature B, so we'll just do
Feature B in the upcoming iteration. We'll get it done."
CUSTOMER: "I know. You have for the last four iterations."
That is honesty and humility in action. Which scenario would you prefer? We
prefer to be free to tell the truth. If everybody expects this, and does it, everybody
wins. If either side doesn't, you will crash and burn.
Come on! You say. Isn't that a bit contrived? Here's a real one from a few days
ago:
We're not very far away from a release date, and people are under a lot of
pressure:
CUSTOMER: "I know you just got the relative date thing working by typing in a
plus or minus followed by a number, but I'd really like to be able to
specify today by typing in a zero."
DEVELOPER: "That's not going to happen. You said you wanted a plus or minus.
That would be a new requirment and it would push the end date out."
CUSTOMER: (angrily) "Don't tell me that's what I wanted! I wanted a zero from the
beginning and you talked me into the plus or minus because you said
it would be easier to do."
DEVELOPER: "Calm down. I'm sorry I used my words poorly. It wasn't what you
wanted it was what you agreed to."
CUSTOMER "OK. It's what I agreed to. Don't tell me it's what I wanted."
DEVELOPER "Again. I'm sorry. I should have said it was what you agreed to."
CUSTOMER "Well, how much longer would it take to make it work with a zero."
DEVELOPER "Well, let's talk about it calmly. OK? (pause) I don't remember what I
told you originally. The issue was that a t for today or a y for
yesterday wouldn't work for internationalization. A zero would work
theoretically, but it's ambiguous could be interpreted as the beginning
of a valid date. As soon as you type a plus or a minus, there is no
confusion and we can shift into relative mode. That date widget we
are using from the 3rd party has some really raunchy code and it wasn't
easy to get it to work with the plus and minus, but writing our own
date widget at this point would be foolish. I don't think it will be
difficult for users to get used to typing a plus or minus for today even
though it isn't intuitively obvious. Of course, either is plus or minus
for that matter. We're going to have to teach them to use them, so I
don't see that it will be more than one sentence in the user manual to
teach them how to use plus-zero, minus-zero, or just plus or minus to
get today."
CUSTOMER "Well, maybe not. But how much would it cost to make it work only
when you type a single zero and tab out of there."
DEVELOPER "Well, now that I've been in the code and pretty much figured it out, it
might be a little easier. But, this isn't the same as keying off a plus or
minus because when you type in a zero, you don't want to switch to
relative mode. If you wanted a t or some other character that wasn't a
number, that would be a piece of cake and I could do it for you right
now. But I can't think of any other characters that would be more
intuitively obvious that wouldn't cause problems for
internationalization. There's also a lot of hairy testing to make sure it
works for all the ways you can get to the point of one zero followed
by a tab. I don't think it would take more than a day, but I'm not so
sure there won't be some other gotchas in there."
CUSTOMER "Hmmm… I still think I want the zero, but I'm not sure."
DEVELOPER "Well, we'll just leave it out for now. If you are sure you want it, let
us know and we'll put it back into the remaining list of things that still
need to be done."
It wasn't perfectly smooth, but brutal honesty got us to the point of reality.
Would "Yes Ma'am, the customer is always right" have gotten us a better result?
Maybe it would have been better if the customer said, "Look here, it shouldn't take
you more than a couple of minutes to make it work with the zero. So make it
work!". If you think that's a better way to work, please don't apply to RoleModel
Software for a job or to hire us to write your software.
It's not just about honesty and humility between a customer and developer.
Think about interaction within a development team. Here is a stereotypical exchange
at a development status meeting where bravado and deceit are rampant:
BOB: "The Humphsplat class was a mess so I completely overhauled it to use
different methods on DinkyDoo. It's much cleaner now. I had to change
the public interface a bit, but it shouldn't be too much trouble, so I went
ahead and migrated it to Integration Test."
JANE: "I'm depending on that class! You should have told me you were going to
do that. Now my stuff won't work!"
BOB: (out loud if he's really brash, to himself if not) "You're always saying that.
You don't want to do it right, so you leave junky code around. Just
implement the changes and get on with it!"
JANE: "I can't get my current list of stuff done and upgrade to your new class.
Unless you'd like to take on some of my tasks?"
BOB: "No, thank you very much. I've got plenty to do already."
FRANK: "I'd love to help out, but I'm really having trouble understanding that part
of the system. The logic seems really complex. Can either of you walk me
through it? I'm sure it would help because I need to add logging to the
DinkyDoo class."
BOB: "The logic is complex because some people don't make it elegant like they
should. I would walk you through it, but all my time is booked cleaning up
other messes."
JANE: "I'd love to, Frank. But now, thanks to Mr. Senior Guru here, I've got too
much work to do to take the time to explain it to you, much less get a good
night's sleep."
And so on. Nobody is communicating with anyone. No problems, interpersonal
or otherwise, have been solved. Everyone is defensive, caught off-guard, or
continually ignorant without any hope of catching up. After the meeting, everyone
returns to their cubes and gets deeper into the jungle without an escape plan.
What if it went like this instead? At the daily stand-up meeting on Tuesday:
BOB: "The Humphsplat class was a mess so Jane and I paired on that yesterday.
We refactored it completely and it's much cleaner now. All the tests pass
on the integration machine, so we're integrated and everyone else should
be fine."
JANE: "That refactoring was tough, but I learned a ton. I understand how
Humphsplat fits into the world now. Bob almost hammered the public
interface, but I caught him and we worked through it."
Bob and I are done with that, so I'm available to pair."
BOB: "Hey! Well…yeah…I was going to…never mind. It was really stupid. I'm
an idiot! But all the tests pass, so I guess I recovered gracefully. Thanks to
Jane, that is."
JANE: "I better watch out or I'll get a big head. I wasn't that brilliant. Bob taught
me a few tricks that I didn't know. Anyway, he and I are done with that
stuff and I'm available to pair."
FRANK: "I'm really having trouble understanding that part of the system. The logic
seems really complex. Can either of you walk me through it? I think it
will help me with my next task. I have to add logging to the DinkyDoo
class."
JANE: "Sure. I understand it now. I can walk you through that first and then we
can pair on your next task."
Again, which scenario would you prefer? We prefer a supportive environment
where everybody is learning, no one gets left behind, and nobody is a prima donna
no matter how talented they are. If you have an environment like this, you feel like
you can do anything. If you don't, prepare for battle.
When you're honest with others and with yourself, you have no choice but to be
humble. When you are humble, you are teachable. When you are teachable, you
learn. When you learn, you can use what you learn to achieve great things. That's
winning.
No comments:
Post a Comment
Your comments are welcome!