Posts tagged agile

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.

On Dec 9, 2011, the Chief Information Officer of the US released a 25 point plan to reform Government IT:

http://www.cio.gov/documents/25-point-implementation-plan-to-reform-federal%20it.pdf

Here are some highlights of the document:

• Turnaround or terminate at least one-third of underperforming projects in IT portfolio within the next 18 months
• Shift to “Cloud First” policy . Each agency will identify three “must move” services within three months, and move one of those services to the cloud within 12 month and the remaining two within 18 months .
• Reduce number of Federal data centers by at least 800 by 2015
• Only approve funding of major IT programs that:
  • Have a dedicated program manager and a fully staffed integrated program team − Use a modular approach with usable functionality delivered every six months − Use specialized IT acquisition professionals

My Opinion

After briefly reviewing the document, I read modular development as Agile Development Practices. If this is the case I applaud the CIO of the US in acknowledging that Waterfall does not work!

Information technology should enable government to better serve the American people . But despite spending more than $600 billion on information technology over the past decade, the Federal Government has achieved little of the productivity improvements that private industry has realized from IT . Too often, Federal IT projects run over budget, behind schedule, or fail to deliver promised functionality . Many projects use “grand design” approaches that aim to deliver functionality every few years, rather than breaking projects into more manageable chunks and demanding new functionality every few quarters . In addition, the Federal Government too often relies on large, custom, proprietary systems when “light technologies” or shared services exist .

— 25 Point Implementation Plan to Reform Federal IT - Vivek Kundra - CIO USA