Oh you poor, poor customer 14
I just got back from my third time at the AYE conference and it was another great time. I had a real eye-opening experience on Wednesday and it had to do with how I interact with customers, QA and even developers. Pretty much anybody taking a class or starting a project where I am involved.
- There were two of us playing customers – we did not understand the problem and we did not necessarily agree or understand where we had different interpretations
- We were freshly assigned the role and did not quite understand the details of the problem, our actual responsibility or how to interact with the team (a deficit of tacit knowledge)
- Time was (perceived to be) at a premium
The session/simulation was run with great expertise by Don Gray.
My first really strong observation was during the first meeting with the development group – about 5 minutes in. My co-customer and I had spent a few minutes (literally) reading the requirements and coming to some partial understanding. We met with the “simulated” development team and all hell broke loose (at least in my head).
The development team did some things well.- They tried to think of something small they could do in a time-box.
- They presented us (the customers) with concrete examples of things they could do as first examples.
- They asked concrete questions about the requirements.
- The presented some preliminary examples of possible interpretations.
These are all good things; things I would and have recommend in the past – and will contine to do in the future. And these things did not work for me.
“Playing” the role of customer, when I came to that initial meeting there were many things in flux.- I did not really have much of an idea of a time-box.
- I had looked at the problem in a very different way than the development team, so many of their questions simply did not make any sense to me.
- I felt bombarded by many voices, with many different kinds and levels of content.
- I am a big-time extravert (Jung’s definition) and I’ve been the source of this kind of bombardment.
- I need to catch myself jumping right in on what I think is important and instead ask what is important to the customer (or BA or QA or developer for that matter).
- I probably have overly high expectations of what can be accomplished before the team has started to form, much of that initial interaction lacks the tacit knowledge of actual roles and requirements, such that many things are in flux.
- Or, given a team that has been together, I need to get a grasp on its structure before making change recommendations.
At one point, someone mentioned (in essence) that the “actual” requirements were coming from Don, not me, and essentially wrote me off. That was quite a powerful experience as I felt completely devalued as the customer. I can imagine a business person or QA person feeling the same thing.
I think the biggest one-word summary of the experience for me is empathy.
“After” the simulation (I still had not fully decompressed I think), one person expressed concern over how the customers (me) had not followed “the process”. Wow is all I can say to my experience during that simple, loaded phrase.
In my world of the simulation, there was no process – explicit or implicit. If there was one used by the team, it was tacit and I certainly was not aware of it (in fact, I don’t think there was one “the process” as far as I could tell because I was able to both participate and observe). But regardless of whether there was or was not an explicit or implicit process, it does not matter. Can you imagine someone who is not fully available (a customer), being treated as if they were “not following the process?”, which I inferred to mean “I was being difficult.”
When I’ve thought that, consciously or even subconsciously, I’m certain that belief clouded my interactions with other people and it probably has come across as aggressive/offensive/inconsiderate. Maybe a good mantra to repeat to myself is something like:No matter how it might look, people are trying to be helpful to the best of their ability.I know for certain my intentions during that simulation were good. I was trying to give information to the best of my abilities. I just wasn’t yet aware of the requirements and I did not know how the development team was working. To be treated as if I was sabotaging “the process” was in fact quite offensive to me. I am certain I’ve done that over the years. “The process”, regardless of which process it is, is a model of how to do things. And something I overheard really speaks about this:
All models are wrong; some are useful.
(Notice how that applies to things like TDD, BDD, Scrum, XP, ...?-)
If you have a chance to attend AYE next year (or PSL in May), I’d encourage you to do so. But be prepared to be overwhelmed with personal observations.
Great insights. Thanks for sharing this. BTW here’s some info about the source of the oft-quoted phrase about models: http://en.wikiquote.org/wiki/George_E._P._Box
Dave,
Thanks for that link. It’s a great first principle.
Add to that:And you get a great, self-referential set of inconsistent words to live by!
Thanks Brett, this is a great post. We get so caught up in doing things (and making sure we do it “right”) that we forgot software is really about people.
“No matter how it looks at first, it’s always a people problem.” ~ Gerald Weinberg
Also like your mantra and one-word summary of empathy. I hope to remember to do the same!
Great blog, you hit the nail right on the head. From the customer side feeling that your input was being discounted due to a preconceived notion or disposition is frustrating. The art of objective listening is always a premium.
These two quotes for me sum up your experience:
“At one point, someone mentioned (in essence) that the “actual” requirements were coming from Don, not me, and essentially wrote me off.”
“I just wasn’t yet aware of the requirements…”
Although they didn’t show you enough empathy, the still assessed the situation correctly. Empathy is great but more valuable is how to treat people who think they have something to contribute but really don’t. If you aren’t giving the team viable information, surely you are subtley sabotaging “the process” (whatever that may be).
@Chris Wellington:
I have to disagree, at least partially. We’ve all had the “opportunity” to have to deal with someone who legitimately has nothing but their ego to contribute, and pushing them gently and tactfully aside is an important skill.
But just because someone doesn’t have a full understanding of the requirements doesn’t mean they don’t have anything to contribute—I’ve seen a number of cases where someone’s focus is only on a specific narrow area of what’s being discussed, and they have a better grasp of it than anyone else. Dismissing their input because they don’t see the whole picture… Well, read Brett’s post to see how that felt from the customer side.
Thanks for reporting about your simulation.
During the exercise, did the team made any attempt to discuss with the customer (you) the manufacturing process?
Few months ago, I was fishing around for building a new house. I was pleased to see that several manufacturers were offering to explain the building process from A to Z.
In software engineering, we have developed fancy processes to extract requirements, to iterate, to test continuously… But, as far as I know, there is no stress on how to ‘educate’ the customers.
Yes we need to listen you them. But when you build a house, it is relatively common knowledge that you will have the basement before the roof. When you build a software application, there is nothing to see besides the UI.
Chris Wellington wrote:
This seems to be exactly the opposite of my point.- To sabotage something, it has to exist. It did not, so I could not.
- You are interpreting the intentions of someone else (me in this case). I can tell you with certainty that I was not trying to sabotage anything.
So I’ll simply paraphrase Gause & Weinberg:What does your feedback to me say about you? That’s, of course, for you to decide. Not me.
Brett
Thierry Thelliez wrote:
Good question. They may have, if so I wasn’t prepared to receive that information. In the initial “meetings” I was bombarded with lots of information, at different levels, coming from may people. So they might have done so, but I cannot say.
Even so, I want to point out that I’m not convinced that this is a generally good (or bad) thing. Ultimately, we are trying to serve a customer. If the customer is served by being educated about the process, then that is a good thing. If not, then it might be a bad thing.
So I think I need to make sure to work with the customer to know what s/he needs. If I do not agree with what/how the customer wants to work, I have options.In reality the first two form a spectrum and might be applied to varying degrees across the spectrum of the interaction.
In any case, educating the customers is certainly something to keep in your toolkit.
The reason why I put “the process” in quotes was to indicate that even though there was no formal agreement on the process, the team was neverless moving forward in some sort of logical fashion. That sounds like a process, even if it is something as accepted as the scientific process. I would find it hard to believe that they were not.
Okay, I misunderstood the use of sabotage. When I initially read it, I thought whoever had used it intended it to mean it as “unintentionally hinder” (which was my use). However that does not mean that the team should put up with misinformation.
If you don’t know what the requirements are (which you didn’t by your own admission), and you are supposed to convey said requirements, what is your contribution to the team?
I think there is a huge gap between “a process” and “the process”. And 10 people going in their own directions does not to me make a process. We might have different perspectives on that but part of what I am saying is: Activity != process. Even so, I was part of the overall development effort. I do not think I was ever brought in to “the process.” So when I was accused of not following “the process” I felt like I was being blamed. It’s a two-way street. Bring me in if you want me to participate. Do not bring me in? Do not blame me for not playing by your rules.
Fair enough – I assumed a particular interpretation of the word, with negative connotations. I won’t quote the dictionary precisely because words like “sabotage” are thing with different meanings and interpretations; their meaning (like all words really) is in the listener, not the sayer – much to any talker’s chagrin. Even expressions like “plain vanilla” are highly ambiguous (as I learned from Rick Brenner several years ago at a conference called The Leaders’ Forum.)
Really, most of the requirements were well understood enough. One particular word, “stack” was at question. As in, make a stack (or a pile) of X. My co-customer and I had the same interpretation of the word. Don, the facilitator did not – his was easier to work with.
In all the projects I have every worked on, “the requirements” are in flux, changing, and essentially unknown to varying degrees. In fact, there is no such thing as “the” requirements. Maybe I am pulling a Bill Clinton on the definition of “the” but that is how I see it.
What happens if nobody knows “the” requirements (which is the norm)? We could do nothing and wait for them to be understood. That’s moving towards the “sign-off” extreme.
We could come to a best understanding, move forward with that understanding, get there quickly, get feedback and readjust.
Neither approach is “right”. I prefer the feedback path, but keeping the option open to say “no” is important. (If you understand the MBTI system, you can interpret that to mean I generally prefer Perceiving versus Judging.)
Additionally, people are often assigned to a given role and it takes time to figure out what that means. If my team members are thinking: ... what is your contribution to the team?This attitude will almost certainly come out in interactions and it will (probably negatively) affect team dynamics. In fact, I’d suggest that the dynamics will be so affected that using the word “team” will be wrong. It will be a group of people called a team as opposed to a team. To me, those are very different groupings of individuals.
On the other hand if I assume:I think that is going to lead to a team gelling.
Does this mean we have to keep everybody on the team? No. Just as it is important to treat one person with respect and consideration, the same thing applies to other members. In some cases, given individuals will not work well with the team. Being able to have a say in the team makeup is an important thing that in fact distinguishes a team from a “group of individuals called a team.”
This is such an interesting read, I think Brett summed it up neatly when he said ‘the process’ and ‘a process’. I think this statement actually probably applies to many different situations in life generally and not just at the AYE conference. As Jay mentions up above, you have hit the nail on the head. I think ‘customers’ are often bombarded with information rather than being clearly explained to, especially when it comes to software! Makes me think of the complexities of buying a house You never feel like you know where you stand with everyone else, because people want to be recognised, a team IS usually just a group if individuals.
i am poor one
A comment on the need to educate the customer:
In the enterprise context ou rarely deal with customers directly. Rather you deal with users and stakeholders.
In this context you are well served to eucate them, as they should be considerred, and made to feel, part of the team.
I think this reinforces Brett’s point about making all people feel like they are making a valuable contribution.