Here's wishing for a great 2012

Greetings!

Here's wishing for a great 2012. Not doubt next year will be an interesting one. Several domestic indicators late in the year (shopping trends, job creation and housing starts) have provided reason for cautious optimism, while international economical/political news still require that I keep an adequate supply of antacid tablets on hand.

Several topics have caught my eye recently. And, like I did at the holiday buffets that I was fortunate enough to be invited to this season, I have decided to visit each one and sample its contents:

First, I attended an ASQ meeting recently and was introduced to the Hoshin planning model. Yes, I am a member of ASQ. And yes, I am a CQM, however, I have to admit I have next to no knowledge regarding this model. A vice president of quality for a local medical equipment company has made it his mission to spread the word and spoke at a recent ASQ meeting about the model - and has even developed a software package to aid folks bold enough to test the waters with it. However, the fact is, it's simple. Basically, the model requires company executives determine and agree upon the company's most important goals/objectives for the year. Then, they develop strategies for each goal - then tactics. Each tactic at one level of the organization may then drive a strategy at the next level - which in turn drives another tactic set. Sounds easy enough - right? The problem, but not with Hoshin is (actually, there are four major ones):

1. Executives have to decide and agree upon objectives. Some good organizations do this very well. However, for too many companies, somehow this remains an elusive goal. I can't help but believe the numbers would improve if more executives had formal quality and/or project management backgrounds. I may be partial, but that's my story and I'm sticking to it.

2. The management team (and employees) all the way across the organization have to ensure that they have interpreted the objectives correctly so that their strategy/tactics align with objectives. In other words, there needs to be an ongoing communications stream across the spectrum.

3. Be able to audit status against goals for each level of the organization. Please see#1 above for the reason this is often not successful.

4. This planning model doesn't work overnight. It can take 2-3 years before the organization speaks and acts with true unity regarding its goals and objectives. The organization has to be disciplined enough to stay with it until positive outcomes prevail. Yes, I am saying executive teams lack the perseverance to stay the course. Doing RCA on this topic for many teams may yield some profound outcomes.

In summary, for Hoshin to work, companies need to be able to agree on the decision making process - and stay with the decisions once made. Embark on a constant communication program, develop measurable feedback with full engagement with employees on what measurements should look like, and have the discipline to stay with it. So simple - yet so difficult. No wonder the Hoshin model lacks more widespread adoption. The road to Hoshin may not be a short drive, but still worth the effort when you arrive.

Second, a terrific article was written recently by NiloferMerchant in the HBR entitled; 'People Are Not Cogs'. She feels that the new economy is about producing ideas, experiences and meaning. The output of these singular and collaborative entities may produce revenue on its own, or could be the input to other ideas, experiences and meaning. The full engagement of all employees as collaborative partners is imperative for success. As she states:

'Look at Apple. Their earnings per employee figure is $419,528 per head, beating out even Google's of $335,297/head and well on its way to be double that of Microsoft, currently at $244,831. They outperform their industry because they've figured out how to enable the key asset of the new economy: scalable leverage many people's contributions, including the app developers eager to piggyback on the industry's most attractive devices. Yet most organizations still operate much as they did in the industrial age. We manage the measurable, rather than the things that create meaning that fuels creativity, that enables innovative thinking and that helps any company to outpace the market.'

Also, she goes on to provide objective evidence when shes states:

' (The) Gallup, the research firm, recently did a meta-analysis across 199 studies covering 152 organizations, 44 industries, and 26 countries. It showed that high employee engagement brings an uplift of every business performance number. Profitability up 16%, Productivity up 18%, customer loyalty up 12% and quality up an incredible 60%.'

Then why do many businesses measure the employee as a resource, which keeps the employee at a virtual 'arms length' with the employer. How can true engagement occur when many organizations run on earlier industrial age thinking. Company performance and people are not mutually exclusive - but are rather mutually inclusive now for company success. Again, it seems simple. And, given the data, why are more companies not sprinting in this direction?

Third, a gentleman recently passed away who was a past CEO of a large company in my area - as well as a founder of a couple of other smaller companies. He was a true believer in the quality philosophies of Dr. Deming, and even received the prestigious Edward Medal from ASQ some years ago for outstanding application of quality principles. He and his wife were frequent donators to many local organizations. They have an ice arena, Boys and Girls Club cafeteria and college building named after them. He was a 'people above all else' person, he was constant in purpose and felt you should continually attempt to improve anything you did - or it wasn't worth doing at all. Looks like his legacy would be a great role model for leadership in the new economy. People and performance - together. Thank you Mr. Conway.

People and performance - together. Sounds like the makings of a good company mantra for 2012 and beyond. I'm ready .... bring it on 2012!

Next topic: Method To The Madness: Rise of the idea system

Can Agile and UAT Play Nice?

Greetings!

This question was posed to me by a QA colleague recently; 'Shouldn't you be able to run UAT testing within the confines of the Agile/SCRUM methodology?'

Fascinating - huh! ..... Or do I just need to get out more often.

If you stop to think about it for a moment, it kind of makes sense. At the the conclusion of every sprint cycle, there should be a completed effort - inclusive of QA testing and documentation. Right?

So why not incorporate UAT into the process? Couldn't use cases be modified to just test the functionality inherent in just that sprint cycle - as well as cases that may tie into functionality from past sprint cycles?

I know, enough with the rhetorical questions. Truth of the matter is that UAT, by it's very nature, can only be accomplished after the last sprint cycle. When the system or solution is nearly ready to be deployed.

But, isn't true you can exercise a use case or three as long as the requirement functionality is present. Absolutely! Won't the chance to discover defects earlier in the development cycle reduce cost (i.e. cost of quality)? Probably.

But here's the thing. Figuring out exactly what to test could become quite time consuming - largely due to the fact the UAT analyst is focused on business requirements - not functional requirements. The analyst also may not have the expertise to separate the functional 'wheat' from the business 'shaft', and will need development and QA help to do so - taking time from their own efforts. Yes, you may be able to execute a few use cases - but with changes post sprint, time lost by associated parties, along with the need to possibly regression test (which is largely outside the scope of UAT), negates any value of testing during each sprint cycle.

If the UAT analyst were able to apply a testing 'centrifuge' to the process that magically determined what to test, then maybe you would have something there (just make sure you patent the thing first!).

Next topic: Quality is Everywhere: The secret purpose of meetings

'Double Header Day' at Quality Sphere

Greetings!

It's 'Double Header Day' at Quality Sphere as I approach two topic areas at once:

Quality is everywhere:Toastmasters, International, and

Methods to the Madness: Things my mother never told me about UAT

I mentioned in my last article how I wanted to touch upon a quality organization - Toastmasters International (TMI). No doubt on my tombstone will be the motto 'Fran saw quality everywhere'; however, seeing why TMI is such a great organization is easy. But before I extol the virtues of this organization, I would like to address a specific area Quality topic: User Acceptance Testing (UAT).

I recently ran into a possible gray area around how best to defined the following:

End state summary

User scenarios

Use cases

User test cases

To many, and I have to admit that I had my doubts recently as well, struggle as to what are the differences between these terms? Are they just different ways to express the same thing, or are they all just different points in the testing horizon? After some soul searching, reading and on the job experiences (OJE), I believe I have found reasonable answers (notice I didn't say 100% correct answers - I'll leave that to ASQ-BOK gurus to put their stamp of approval on it). I would classify them under two areas:

High level

End state summary: is simply what it says. A summary of where we want to be at the conclusion of Test Effort 'X'. There could be 1 or more 'X's', but nonetheless, it's simply a summary statement. You could also use 'Future state summary' as well.

User scenarios: The high level paths that the user is expected to take that will allow them to arrive at the scenario end state.

Specific

Use Cases: Specific action taken in the user path to arrive at the end state. As with any test case, there should be a stated expected outcome and it should be traceable back to the requirement(s).

User test cases: Can be the same as Use Cases, however, the value of these test cases is to tread into areas either expected or not expected to be encountered by the user. And yes, the terms 'black box' and white box' testing could apply here as well. Again, as with any test case, there needs to be an expected outcome and it should be traceable back to a requirement(s).

Simple enough, but then ponder the 'chicken or the egg' scenario. Does one use the high level to drive requirements, or do you develop requirements to drive the high level? This question was presented to me recently, and I am still mulling it over - but would like to hear your thoughts!

Back toTMI ....
I have been a member of TMI since May of 2009. I belong to a great club called the Synergists. What makes TMI a quality driven organization? They exist simply to promote continuous improvement in communication and leadership ability in EACH individual in a very positive, supportive, efficient, and cost effective manner. And, it works very well! .... 'nuff said!