July 2012
Mon Tue Wed Thu Fri Sat Sun
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Month July 2012

Ready for an informal review?

There are times when you are absolutely certain that what you’ve written or coded is ready for a formal review or release. When you are certain about the artifacts contents, or its impact on the overall process is very low it’s a safe bet to publish and worry about the minutia later. Then, there are those critical artifacts that you might want to consider having informally reviewed by your peers because it does impact others or a critical process. Starting with an informal review will build your confidence in writing great requirements while it also builds additional team core strength.

An easy way to determine whether or not you need to have an informal review is to answer the following multipart question:

Is the unit of work under my span of control complete, such that I know I can

A)Hand it off to other teams to begin working on it without injecting defects into their work flow?

B)Pass a formal review in its current state with some minor tweaks?

If you strive to answer yes to all parts of this question then you are not only demonstrating your understanding of the assigned task, you are also fully committed to taking responsibility of the quality of the work. When you are proficient at this make it a practice to coach and mentor your peers accordingly. Note: being proficient does not mean answering yes to all of the question all of the time.

In my experience I have met many people who can answer yes to only one of the two completely, a few who can answer both the rare genius or a fools optimist . If you are wondering how to tell the difference the fool is the person who can say yes no matter what the facts are.

Review, Approve,Verify

How important is it to get it right the first time?

In nature, species evolve over eons. It’s important to note that with changes gained there is always something lost. Nature often has a way of letting go of what is no longer necessary. That too, also takes a very long time. Everything around us is in the natural world is proof positive of a loosely coupled review, approve and verification process.

“The fossil record implies trial and error, the inability to anticipate the future, features inconsistent with a Great Designer (though not a Designer of a more remote and indirect temperament.)” ― Carl Sagan, Cosmos

Imagine, for a moment, what the dollar cost would be if one were to begin a program with the objective of creating homo sapiens starting with single-celled organisms? Carl Sagan had it right when he suggested a “… Designer of a more remote and indirect temperament.”

I have yet to meet a business partner, CFO, CEO, or a CIO with that kind of patience! In the software development world we strive to get it right the first time. Money is the usually the motivating factor that is used to start quality improvement programs. Expectations are then set to unachievable levels causing a failure to launch sustainable quality practices.

While it’s a certainty that the dollars saved from quality improvement initiatives should and will not be ignored, it is also important that money should not be the main focus. When it comes to problem solving, money is not the most compelling reason for changing the way things are. In fact, money often  stagnates clear thinking, logical thought and creative processes of innovation and change. It often gets you temporary results that do not stand the test of time. To be really good at review, approve and verification you have to be really good at staying focused on innovation and change.

Note to leaders who just read that and thought, “Good to know, let’s start a new quality improvement organization with zero budget and or, resources, leave the rest of the organization well-funded and disinterested and see what we get!” A bad, if not silly (by which I mean, really silly) idea.

In my next few blogs I am going to discuss the known and hidden benefits derived as a result of following lean six sigma review, approve and verify series of workflows that you can build into your current SDLC process.