Really, we're just trying to help

Last Thursday evening I called my bank to report my bank card had been lost. I answered a bunch of questions and the person said they'd mail me my new card within five to seven business days. Boy was I surprised when a new card showed up in next day's mail. The following day a new PIN code came in another letter. I called up to activate my new card and strangely, the person on the line asked me a whole lot of questions including one that I couldn't answer--what date did I open my account? I've had my bank account so long I didn't remember. After being placed on hold and asked a few more questions that I could answer, the person said my card had been activated. Boy this was excellent service!

Except it wasn't...Sunday the ATM refused my transaction with a cryptic "your card couldn't help us" message. Today I again tried my card (maybe I'm dense),with no luck. I went inside and told the teller my new card wouldn't work. She looked me up in the computer after checking my ATM card and my ID and said that this wasn't my new card, it was my old card. It had been reported lost or stolen so I couldn't use it. All I could do is sit tight and wait a few days for my new card.

What happened? Why did my card show up early? I think I've figured this out. The last time I used my bank card I'm guessing that I left it at the machine. Thinking they'd be helpful, I suspect my bank then initiated a process to send me a "replacement" card which with same card number as my swallowed card, but requiring a new PIN.

If I had held off phoning in my lost card for one more day, that mysterious "replacement" card would have shown up and I would've been set (after I received my new PIN code in another mail). But once I reported my card as lost that nixed my old card for good. Bummer.

I have some gripes my "replacement" card's arrival. There were no clues about why it was being sent. Secondly, a separate mail came a day later advising me of a new PIN code, again, without explanation.

I can see some analyst pondering what to when a card has been left at a machine. Did they test the replacement procedure on real people (or eager phoning people like me)? How likely is it that someone might report a lost before the replacement mysteriously showed up? Why should phoning in a lost card invalidate the replacement process (I think I know the answer to that one as the original lost and replacement cards, having the same card number, aren't unique...so how can the bank tell which card I was reporting as lost?)

I would've been happier if the person who answered the phone when I called to activate my replacement had told me, "No your card isn't activated." But maybe she didn't know that it wasn't usable. Or maybe she was just being obscure to throw off the card thieff. I can only wonder. After the conversation ended, I knew my card had been activated and thought I could use it. But I couldn't.

I know my bank was trying to be helpful by sending me a magic replacement card. But after one confusing activation phone call, two unsuccessful ATM episodes, and one helpful conversation with the bank teller, I finally figured it out. I'm crossing my fingers until my new card shows up and I use it for the first time.

But Joe says....

I've posted a copy of my Agile 2006 tutorial slides and notes for Skills for the Agile Designer on my website’s resources page. The tutorial was organized into skills for seeing problems, seeing and shaping solutions, and working in collaboration. In addition to introducing problem framing as a technique for identifying what questions to ask of your customer, I presented several ways for seeing and shaping your design. The last part of the tutorial covered some “soft skills”- how to recognize false arguments, handle design criticism, and adjust to different design rhythms. So, if you want to know a bit more about red herrings, proof by ignorance, false dichotomies, shifting the goals posts, democratic fallacies, or the companion in guilt move, check out my tutorial notes.

A designer, especially one in an agile team, has to be a good communicator. Part of being a good communicator means knowing how to tell a sound from an unsound argument, and then knowing techniques for countering certain arguments. By the way, argumentation isn’t the same as “shouting” or “having a fight”. When I’m talking about argumentation, I’m talking about having a discussion on some topic. I must caution you that while recognizing faulty reasoning in illogical arguments can be useful, it isn’t always easy to counteract.

For example, changing what is being argued for in mid-debate—or shifting the goalposts—is a common argument move to avoid criticism. As soon as an arguer sees a position becoming untenable, he or she shifts the point of discussion to a related, but more easily defended one (think how a stereotypical politician never directly answers the question you ask but answers tangentially...and you understand what it means to blatantly shift the goalposts). Most co-workers aren’t so blatant. But having reasoned discussions with someone who habitually shifts goalposts may not be easy. The best you can do is politely but insistently point out their shift, once you spot it, then try to steer the conversation back to the original topic.

Knowing the names of common argument moves comes in handy. Personally, it has helped me slightly detach during the heat of a discussion (in order to think just a bit before reacting). This has been a good thing. Instead of diving into debate or getting sidetracked or frustrated by faulty reasoning I can spot it for what it is…and then try to reel in the conversation if possible.

During the tutorial I presented an example of a companion in guilt move—how a teenager might point out to a parent their inconsistency in how they apply the rules: “If Joe gets to do such and such, then why can’t I?” At this point, an attendee raised his hand and said, “How did you know that my name is Joe?” That brought down the house. After the tutorial I had a long conversation with Joe who thanked me for my presentation and said that dealing people effectively on an agile team was the “hard stuff”. New technology and tools are easily learned, but being aware (and knowing how to effectively work with your mates in spite of their biases and or backgrounds) requires daily diligence. Thanks, Joe. I enjoyed our conversation.