Tuesday, August 13, 2013

Trust No One!: 99 Ways Workshop #52

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 



Suggestion #52: Trust no one! In sense that what people say is not always what they REALLY mean. So the more you conversate, the more you trust. But your trust level is always less than 95% - Oleksii Burdin


I get the point that is being made here, or I should say, I am looking at this point from a particular perspective. It may or may not be what Oleksii meant, but it's the avenue I'm going to use for this particular post. 

We've all been in this situation. We describe to a potential customer or client the product we are designing, and the features we are looking to include. They respond in the affirmative. We describe in more detail, and we keep getting feedback. "Yes, this is exactly what we want!" Story kickoff, acceptance criteria, development work, testing, demo, staging, delivery, all go according to plan. We deliver on time, we deliver on budget… and then? We hear nothing. 

We query back later as to their use of the new feature, and we get a response of "meh". When we press more, what do we hear? "It's not as we envisioned" or "It doesn't really meet our needs".

Head. Desk. Repeat.

The example I describe above borders on hyperbole, but just a little. The truth is, customers really are this fickle. The deeper truth is, they can't entirely help it

For many of them, as the process was being described, it sounded great. It certainly fit what they envisioned they would need. They liked the idea of the project. They liked the feature as it was described to them. They saw in themselves or their users the idealized state of the feature or idea

Then the feature is released into the hands of actual, flesh and blood, entirely too human users, and the model of idealism and perfection falls apart under the reality of how people really are

This happens ALL THE TIME. It's unavoidable, but it can be mitigated considerably.


Workshop #52: Take on a story in a truly Lean and Agile way. From spec to delivery, focus on a small aspect, examine the scope, examine the users, communicate often, deliver quickly, fail fast if necessary, then refine and try again.


If you have ever wanted to have a discussion of Lean principles or Agile methodologies and why they may be helpful, if the above sounds far too familiar, then here is a great opportunity to initiate this discussion.

The process is aimed not at some nebulous, idealized product, or perfect implementation, but a real blood and guts discussion about how people really are. We expect them to lie… well, really, we expect them to exaggerate. We expect them to see themselves in ideal terms. We expect them to focus on their industriousness and innovation, instead of their genuine capacity and a very real resistance to change. 

With this in mind, ask for the opportunity to:

- determine "how can we test this idea with the least investment (time or effort)?" (thanks Paul Ruberto for the comment ;) ).
-  actually see and interact with the customers in question (easier if it's an internal project).
- ask if the users would take part in early demo and modeling of the feature.
- be directly involved with feature testing in the early stages to offer feedback.
- take part in usability studies as the feature is developed and tested.
- be part of an early deployment scenario on a staging device.
- define some key workflows where the feature would be helpful.
- work with them in a pair setting as they actually use the workflows.

What can these situations tell us? They can give us the real world interactions of real people with a real feature. Idealization is jettisoned for a much more pragmatic reality, and the lessons we learn can help us fail fast, get better, and make something that will actually be useful for our customers. What's more, our total outlay of time, resources and energy will be much less expensive than going through a more traditional development process only to find out at the end of the process "this isn't what I was looking for"… and they will be right. It wasn't what they were looking for. They wanted an ideal. They received reality.



Bottom Line:

Chances are, we can't prevent the reality of what people will want vs. what they will get, and how they will react to what they get, but we can get closer to the mid way point between idealism and reality. Again, this is not me being a critic. This is me being as honest as I can be. 

We should not trust people not because they are dishonest, but because they see themselves far more ideal than they are. That's balanced by the fact that we often see ourselves in idealized terms, too. We think we can program the amazing and life-changing. We think we can test the all-encompassing and complex. The truth is, our results will be "human", too. It's easier to learn these facts and become comfortable with them using Agile and Lean methods than in a more involved, expensive traditional release process.

You're just going to have to trust me on that one ;).

No comments: