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

Silent Hour - Experiences

Week ago I blogged about our new experiment - Silent Hour.

Our team has just one room, people sitting next to each other and even if you are discussing with only one team member, others are also easily distracted. Headphones do help a little, but we decided to try something different. Between 12:00 to 13:00 we close doors of our team rooms to avoid all unnecessary disturbances both from internal and external origins.

For customer contacts we fortunately have first tier customer support which can handle easy tasks independently. Complicated tasks and problems are forwarded to developers, but during Silent Hour we encourage them to try little bit harder before doing that. Or they can take request for callback if the issue is not too urgent. But rules are not absolute; if they really needed help they can ask advice from developers anytime. Common sense rules.

On the other hand managers and salespeople tend to rush to ask questions from developers at any time. And just fiver minutes later they come back to ask follow-up question. Face to face communication is good thing -no doubt about that- but just when you are getting back to flow for programming, there is already new distraction waiting... With Silent Hour closed-door-policy should encourage people to at least think do they need the answer right away or could they wait 30 minutes.

This have been working quite well. After little over week of experiment I did questionnaire to all stakeholders including developers, customer support, managers and salespeople. Almost all answered. Results were quite encouraging. Nobody thought that Silent Hour-policy had made his own work more difficult. Even that sometimes people did not remember the policy and have to turn away when they noticed closed door, they did not feel that additional waiting time for their communication needs did do any harm.  Everybody understood the need for developers to have some time when they can just concentrate task at the hand. And naturally developers were quite thrilled for the uninterrupted time. Sometimes we got visitors even during silent period, but always with good reason. 

Conclusion was that we end this as experiment and make it as permanent policy.

Silent Hour

Agile puts great value for interactions and communications but sometimes too much communication can turn to waste. Interactions should not be part of WIP and should not have their own sticky notes on board.

The Agile principles embrace

Co-Operation

Business people and developers must work together daily throughout the project.

Communication

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 

But also

Sustainable Development

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Simplicity

Simplicity--the art of maximizing the amount of work not done--is essential.

In order to put more emphasis and improve the latter two we now are in progress of testing the new practice we call Silent Hour. Between 12:00 to 13:00 we close doors of our team rooms to avoid all unnecessary disturbances. We urge everybody to think at least twice before distracting developers during Silent Hour. Average waiting time is 30 minutes anyway, so it should not be any problem. Also developers avoid any unnecessary chatter. Some developers are also going to test the Pomodoro Technique® since there is just enough time for two pomodoros.


This is just ongoing testing and rules will surely evolve, but it has received quite good acceptance with developers and also with other stakeholders.

Edit: There is also followup post with more information and experiences: http://ikettu.blogspot.com/2011/11/silent-hour-experiences.html

Performance = potential - interference (P=p-i). Tim Gallwey 

Lean principles - Eliminate waste

Provide market and technical leadership by creating nothing but value. By definition waste is anything that does not contribute value to the final product or customer. Also first principle of Agile Manifesto says: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Everything else is considered to be waste.

Mary and Tom Poppendieck later mapped original seven wastes from Toyota Production System to wastes we found on software development. (Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.)

1. Partially Done Work
2. Extra Features
3. Relearning; Extra processes
4. Handoffs, Motion
5. Delays; Waiting
6. Task Switching
7. Defects

With value stream mapping we can try to identify steps on processes that add value to customer. But how we can measure direct value for example Configuration Management or Risk Management?

Root cause analysis can be used to try to find what was the original problem. There exists many methods, but I have find most effective to just ask enough why's to get the answer. Official name for this is 5 Whys. IMHO Most of time (1-5) whys should be enough.

But even then seeing the waste is hard. And is it actually always necessary?
If carrying along few extra unnecessary lines of code does not cost you anything, is it just waste of time to remove them? Is refactoring always necessary?

Manual work is eliminated by automation. But which one is waste; spending 4 hours to create one time script or doing 2 hours of manual work that accomplishes same thing?

We all are happily carrying 90% unnecessary DNA with us. I don’t want to eliminate it even that I do not know what to do with it. So my best practice for eliminating waste is; use your brain - or 10% of your brain, since nobody knows how to use the rest of it.

See also

• 7 Lean principles

"Just because something doesn't do what you planned it to do doesn't mean it's useless." -- Thomas Edison