Better Criticism

Criticism is an attempt to influence

• Do not afraid to give feedback.
• Choose the appropriate time for feedback.
• Do not blame. Instead tell what  could be done better and suggestions of how to achieve it.
• Give criticism about work. Do not critique the worker.
• Present the benefits of improvement, rather than scare about risks and disadvantages of mistakes. List of failures does not motivate people.

Feedback is the breakfast of champions. -Ken Blanchard

XY Problem

XY problem seemed to be theme for many conversations I participated this week.

Someone asks how to do X when they really want to do Y. They ask how to do X because they believe it is the best way to accomplish Y. 

It's a pattern of miscommunication where questioner seeks premature closure with wrong assumptions. It's quite hard to convince questioner to accept any other solution than he originally considered the best. Usually the questioner have I-Know-It-All attitude, they just need help for doing their X.


XY problem can even be extended to XYZ problem

There may be a solution Z that is even better than Y, but nobody can suggest it if Y is never mentioned.

This is quite common time-wasting problem especially on customer support and help-desk work, but there have been documented cases even on project work.
It would be great that everybody would take time to learn  How To Ask Questions The Smart Way by Eric Steven Raymond :
"

Describe the goal, not the step
If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.
Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.
Stupid:     How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?
Smart:     I'm trying to replace the color table on an image with values of my choosing. Right now the only way I can see to do this is by editing each table slot, but I can't get FooDraw's color picker to take a hexadecimal RGB value.
The second version of the question is smart. It allows an answer that suggests a tool better suited to the task.

"
But it could be inconvenient to RTFM the customers. If the question sounds strange one can apply simplified root cause analysis methods. Specially 5 Whys works quite well. You just keep asking "Why?" until the questioner actual tells the Y he wants to accomplish. It may sound childish and silly, but in the end save you both time.

Asking the right questions is much harder than giving correct answers

Lean principles - Amplify learning

Most things I have ever learned, I learned from failures. Not necessarily my own failures but something somebody has tried and failed so that I have not need to try it myself. Fortunately sometimes I have also learned from other people's success too. And I have to say; sometimes I have success before failing and learnt. And after all, I have gained experience while trying or following others.

( success | failure ) of (your | other people's)
-> experience
-> skills and knowledge

Sharing information regularly creates group knowledge from individual knowledge. Daily Standups are your local best friend.

Competence = skill * discipline * knowledge * social connectivity
And connectivity has more effect than knowledge
@jurgenappelo: from "The Hidden Power of Social Networks", Cross, Bob et.al

But usually I tend to give away little bit discipline by varying my methods. Doing little changes to project plan on every project. Using different test libraries on different projects etc. Some changes are rejected, but best changes remain in effect. It's kind of genetic algorithm for developement process.

Although you can learn some ungooglable little things with other ways too.


Get feedback.

Getting constant feedback from customer, and more importantly from the actual end-user, is essential way to learn about the problem we are trying to solve with the end product. By (my) definition Agile requirements management is a learning process where both the customer and the developer are working together to learn more about the problem. But even then requirements are constantly evolving and only way to make things work is have continuous feedback from actual users of the end product. So you have to commit to continuous integration, deployment and delivery so that the customer has something she can use to give the valuable feedback we need.

Use pretotyping to get feedback (actually you are trying to get prefeed...) on early stages. The main objective of pretotyping is to answer questions about the product's appeal and usage: Would people be interested in it? Will they use it as expected? Will they continue to use it? ... Failing ideas even before prototype stage is much cheaper and you have more time for new ideas to prototype.

Use prototypes to learn about technical challenges you are facing before starting large scale production. The main objective of prototyping is to answer questions related to building the product: Can we build it? Will it work as expected? How cheaply can we build it? How fast can we make it?

But sometimes you can introduce deliberately failures to learn. For example Netflix uses system they call Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within their architecture to learn what happens during outages.

See also

• 7 Lean principles

"I have not failed. I've just found 10,000 ways that won't work." -- Thomas Edison