The NLP teachings involved a series of questions to ask someone that you were trying to help. Look at a couple of examples:

What do you want?
User Story: As a [role] I want [feature] so that [benefit].

How will you know when you have it?
Acceptance Criteria: Given [precondition] when [action] then [result].

What else could an Agile product owner learn from these NLP techniques?

What are the advantages to the Status Quo?
This is a valid question. One that should not be glossed over. The current business process must offer SOME benefits, or it would not be in place. When the user says they want XYZ, asking them in what way the current approach is better than XYZ could be a very useful eye-opener, especially when coupled with the next couple of questions.

What are the needs and/or wants behind those advantages?
How can we fulfill those needs while still getting you what you want?
What a great way of getting buy-in from your users!

The NLP teachings go on, asking for beliefs that the client might have which tell them that what they want, their goal, their aspiration, is unrealistic. In the event of a customer/user who has already bought in to and is excited about what you propose to give them, these additional techniques may not be necessary. But when you are dealing with users who have been doing things the same way for years and years, and they are resistant to change, these techniques could mean the difference between acceptance and resistance.

Sounds to me like there should be a book: NLP for Agile Product Owners: The pattern of success!

I first ran into this problem when working for TransUnion. They had a data set of 375 million records, give or take, that needed to be transformed and loaded into a database with a particular schema. The objective was to be able to use our search mechanism to find the records after they had been loaded. Sounds simple enough.

I started with the last name. What are all of the different last names I needed to worry about? I wrote a script to parse out the data set and build a histogram of the most common names. As to be expected, “Smith” came out on top! But there were, if memory serves, about 64 million distinct values. Wow! Way too many to wrap my brain around. I had to simplify. To shorten the list. But how?

The main thing I was concerned about was punctuation. How does the punctuation differ between the records? Some names are simple, single word tokens, like Smith, Jones, Johnson, etc. Others are hyphenated, like Zeta-Jones or Smith-Barney. Others have multiple tokens, like De La Joya. But what else is lurking in that list of 64 million names that I had to worry about?

My solution was to write code to “fold” names that had a lot in common into the same value. I started by processing the histogram of 64 million names, and transforming the name by converting every upper-case letter to an ‘X’, and every lower-case letter to an ‘x’, and every digit to a ’9′. Then, I built a histogram of those. This was very instructive, but I saw that there were still lots of names that were clearly functionally equivalent. I decided that a series of the same character, 4 or more in a row, should be considered functionally equivalent, regardless of how many there were past 4. So I added just a little bit more code to my script, and the number of buckets dropped dramatically. Looking at the histogram, I could begin to see more and more relevant patterns that I had to take into consideration.

The actual work continued on from there, making the analysis and “folding” code more and more complex. But the essence of it is still the same: Transform the value into another value such that two functionally equivalent input values have the same output value. Or in other words, partition the data into Equivalence Classes. Use the class as the key in a histogram, and see what drops out. Repeat until comfortable that the proper categories have been identified. Then, the function that was used to make the transformation is a very concise record of some of the kinds of things to pay attention to in the data. And the histogram (with original values preserved so I knew which input yielded which bucket key) provides good test/sample data.

This is a principle that I have found opportunity to use time and time again. I’ve used it to identify patterns in strings, to strip out uniqueness from highly variable log output so it becomes more standardized and therefore more readily subject to statistical analysis. I’ve used it to identify unique combinations and/or permutations of record field values (more on that another time, maybe). Basically, since that day, there has hardly been a job that I’ve taken on where I didn’t have an opportunity to use this basic principle to help me do a better job of coding for or testing with real-world data.

Interested in learning more? I gave a talk to the Software Association of Oregon monthly meeting on the subject, for which I prepared some slides. Or, post a comment, and I’ll answer you directly.

Mike is right, of course. It is called a Scrum team for a reason. The team will work together in order to achieve success. If the Product Owner has not been able to gather enough information to be confident of the direction to move forward, the team won’t sit around watching youtube until they do. The team will ask the product owner what they DO know, and will exert their efforts in ways that will help the Product Owner. For example, they may build prototypes that the PO can take to the users, to facilitate more constructive conversations.

One might argue that if the team builds the wrong thing, it is on the head of the product owner. But the team is full of living, breathing, thinking human beings. The developers are not mindless automatons serving the whims of the product owner. Everyone should have the mindset of serving the needs of the customer. If team members think that perhaps the product is going in the wrong direction, they have a responsibility to communicate that. If they do not, their neck deserves to get choked as much as the PO. Now, if you have a product owner who doesn’t take feedback, then by all means, you have your single throat to choke.

One argument leveled against Agile is that it can be used as an excuse for not delivering, citing the need for ‘direction.’ This, of course, is a Waterfall mentality trying to do iterative development, and not Agile. The team that takes responsibility for their success will never have that argument used against them.