Posts tagged development

http://en.wikipedia.org/wiki/5_Whys

Just like a four year old kid, innovation has to do with curiosity and asking questions.

Why? Why? Why?

“The 5 Whys is a question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem.” re: http://en.wikipedia.org/wiki/5_Whys

In the book, The Lean Startup http://theleanstartup.com/book, the author Eric Ries shows an example about using the five why’s to get to the bottom of a support failure issue:

1. A new release disabled a feature for customers. Why? Because a particular server failed.
2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
4. Why didn’t he know? Because he was never trained.
5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers because he and his team are “too busy”

What began as a purely technical fault is revealed quickly to be a very human managerial issue.

Example from: http://theleanstartup.com/book

By using this technique for every feature request, you as a developer can get to the root of the actual problem, since most feature requests come in as solutions, not problems.

It is also important as Eric Ries points out in his book, to be very careful with this technique, it can sometimes do more damage than good. I have been using it internally for the last few weeks and it is definitely help me process through feature requests and ask some external questions not only to challenge the solutions, but to understand the problem better.

This book is full of great information and I think it is a must read for any Agile Development Team.

Here is a modified example of how I used the five why’s:

This morning, we were discussing the need to have a specific name for a type of widget that came from an electronic interface, I internally asked the 5 why’s and thought:

1. Why do we need to call it something different than widget?
   Because users are already using the term widget to indicate widgets that were entered by staff members.
2. Why do users need to know the difference between a widget generated by a staff member and a widget generated by an electronic interface?
   Because they may need to know how to respond to widgets based on origin.
3. Why can’t they identify them by background colors?
   That is an interesting idea. Then we could refer to them as green widgets, and not have to invent a term that does not make sense.
4. Why call it a color, shouldn’t we just label it based on the origin, ie. (staff or interface)?
   The problem with this approach is that, in theory, the origin can seem to be the same, the staff could be using our system, or they could be using a system that is going through this interface, or both, so while origin is important, using the origin as a term could be equally confusingl. I think it may be best to start with the color solution.

By thinking through this internally, I think we will be able to save one more brain cell in our users head having to call some made up term that does not relate to them. By coloring the background of the particular widgets green, we should be able to manage and support the user base and they can train to understand and react based on color.

Disclaimer

My personal example, may not be the best practice, and there may be better ways to go about it, but I am learning and experimenting and it was much better use of time than sitting around all day thinking of what word to make up for a particular widget.

After having the opportunity to hear Yehuta Katz talk at POSSCON about Rails 3, I left with the impression that it is a good time to start learning Rails 3.

If anyone would like to join me on this adventure to get up and going on Rails 3, Jack Russell Software and the Charleston Ruby Group would like to host a Rails 3 Hack Night to go through the process of creating a Rails 3 application.

When?

Wednesday, April 28, 2010 6pm - 9pm

Where?

Jack Russell Software 1067 Cliffwood Drive Mount Pleasant, SC 29464

Prerequisites

• Ruby 1.8.7
• text editor
• Linux or Mac
• ruby gems 1.3.6

It should be a lot of fun.

See you there!

Thanks

Tom WIlson