The innovation killer, ask “But what about…”

Does anybody in your team come up with an idea? (I’m not saying a good idea), the easiest way to end the conversation is simply ask “But what about…” followed by your intellectual vision about the topic that was created in seconds in your well defined brains.

This blog holds (in my humble opinion) two brilliant videos about how you can kill innovative ideas. I guess everybody has people in their environment with a primary response that is negative if you come up with an idea. Either if this idea  is for new product, a new service or just simple improvement for your test process,  all ideas can lead to innovations. The goal of this blog is to let you think about your primary response on ideas. First of all, watch at least one of those two short videos about killing innovative ideas. Both present the same.

These cavemen are not able to step out their own limitations that are created by what they know from the past. The best part is when they come with the solution to create green fire. It’s not hot, hasn’t the color of blood. Whilst the brilliant idea was the one with the red color for wild animals, and the hot temperature for cooking and heating. The good idea is turned into something useless!

This sounds frustrating doesn’t it? What would your response to new ideas be? Could you imagine a situation in which people come up with a good idea? Have you really listened to what they were saying or mean? Are you asking questions like, “what do you mean with…”  or is your primary response :“But what about…”

Negative questions lead to nothing
A good idea can be the start of an innovation. If you challenge the creator of the idea with questions that deepen the idea it can grow to an innovation. Questions starting with “But what about…” are often showstoppers and are killing the idea.

Some examples: But what about the planning? What if we cannot cross the finish on time? What about the budget which we have already overrun? What about the efforts?…this will cost us weeks of research?

However good intentions you have with these question, (and believe me, they are so true), in the early spring of an idea they will lead to the end of a conversation. If this happens a couple of times in for example test process improvement projects, people will stop generating ideas and the improvement process will stop immediately.

Positive question can lead to innovations.
Thomas Koulopoulos says in his blog:

Great ideas are the seeds of innovation, but they are not innovation itself.”

Albert Einstein also said: “imagination is more powerfull than knowledge” I think this is definitely true, but the thing is in this case you have to challenge the other. As mentioned before, and idea often isn’t directly an innovation itself but can be the beginning of something really big and exciting.

Our primary questions are often created by our own limitations.
Cynthia Barton Rabe has in her book “The Innovation Killer” a subtitle that fits in this situation “How the burden of what we know limits what we can imagine”  (I guess she studied Einsteins work too)

Things from past, experiences, things we learned before, and sometimes also human insecurity burden the things we want to imagine. If somebody else comes up with an idea we start asking questions from our limited point of view.

People often think that innovations are dedicated for a very small group of people within an organization. in my opinion ? This isn’t true, or is it? People in every role and in every team can create idea’s that can be the seeds of innovation. How else do you think all great inventions were made?  For instance sport car brand Tesla, Well known for its great designed sport cars, but now leader in electronic vehicles…. Try to guess how much resistance he received on going into the flow stream. But it was the idea of one of their technicians who saw a future revolution. Thank goodness they listened to him! But how many innovations never made it to the shelf but landed in someone’s desk leaving a disappointed worker…..

Cynthia Barton Rabe has in her first chapter a phrase I agree with: “The point of the definition is to emphasize that the ability to think innovatively should be a goal for every function in an organization—not just the new product or technology development team.”

What are your questions?
What type of questions are you asking? Are you asking questions that will challenge the others? Or question that kill the seeds of innovation?

I think if we can create in our teams an environment in which everybody feels comfortable by asking the right question it can lead to great innovations.

I leave you with two famous quotes, and look forward hearing back from you all!

A person who never made a mistake never tried anything new.”
“Logic will get you from A to B. Imagination will take you everywhere.”

- Einstein -

Bad certification and the pesticide paradox

Certification of software can be useful
If you have a large network of applications connected to each other, exchanging critical information to each other and the software is of different vendors, certification of the software can be very useful. Take for example the electronic health record (EHR), all kinds of vendors are sending and receiving information to and from each other. This data is very critical in the meaning of life and dead of people.

For this type of software certification is useful. As a part of the assessment is the execution of a test set to validate of the software works according certain standards. To be sure that each tag in for example an SOAP message has the same meaning. But there is a little problem…

The pesticide paradox
If you’re using always the same test set to verify the software and you don’t change the test set you will not find any new bugs except for regression. This is according to the ISTQB source the pesticide paradox.

But what if you’re executing with for example the EHR an end-to-end test after you’ve certified the software? What if you find new bugs while you’re exchanging the information between systems of different vendors? What if you find issues when you’re live? Why haven’t you found them during the certification process?

If the test set of the certification process doesn’t change, you’re not able to find more issues in the software. Even if the software works according to certain standards this doesn’t mean the software works correct in each situation, it only works good enough according to the certification standard.

Bad certification if the test set doesn’t change
Does that mean that if you do not change the test set of the certification procedure of the software that the certification is bad? I don’t think so; it’s good enough according to the standards.
But failures in the software can lead to failures related to the dead of people why not improving the certification procedure?

If your software is certified with a certain version of the certification you know it works according to that certification. But this doesn’t mean it works fine in every situation.
If we give our software certificates must we change continuously our test set to improve the quality?

Continuous improvement of the set of qualifications
That’s why it’s important to change continuously the test set, make it bigger or better to cover more situations. If there occur bugs during the end-to-end test among different vendors, if there are new issues from production in for example the hospital, why not adding them to the test set?

If you improve the test set, change the certification, bugs from the past will not occur anymore in that situation because they are covered. And yes, existing software must be recertified maybe every half year.

Adding new tests to the test set cost time and money, but if you automate the test execution it’s not that much work. It shall give you more profit because the certification takes place before the end-to-end test with multi vendors and more important it takes place before you’re in production.

What I want to say is, learn from these important lessons learned. An extra test can save a life or a least a failure and money!

One definition, one goal but two perspectives at testing

My assignment at this moment is to define some test goals and goals from the test community for my client. This is an interesting job to do, because you have to go back to the start and define why we’re doing our work. During this task I had a nice discussion with a colleague and I will share this with you.

This discussion brought me to the conclusion that there are many things that have an impact at the perspective of software testing. An outcome for me is also, be very clear to each other (in this kind of discussions). If possible draw a picture or something to explain your thoughts.

The following picture is my conclusion and if you see this picture I hope it’s very simple.

2 perspectives of testing

But first let me tell you the discussion. I started with some definitions of testing and it doesn’t matter which one you take in general they have the same message.

Here are three of them:

TMap®: Testing is a process that provides insight into, and advice on, quality and the related risks. (source)

ISTQB: The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products 39 to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. (source)

ISO/IEC: Technical operation that consists of the determination of one or more characteristics of a given product, process or service according to a specified procedure [ISO/IEC Guide 2, 1991]. (source)

I chose the TMap® definition, because in my opinion this was the best my client. After describing them I send an overview to my colleague. He send me this comment (free translation Dutch to Englisch). What he did is to split the definition into two parts and described, in my opinion, a combination of definitions and goals of software testing.

Goal of testing from the perspective of the test engineer: testing is doing research to give an answer to the question: Do we deliver the products with the correct quality to our customer?

Goal of testing from the customer perspective: Testing gives an answer at the question: Do we get the right quality of services caused by the product, as a result that it is fitting to the end-user.

These two definitions are different! That conclusion we made together when we read these statements.

I think these two statements are not definitions but “roadmaps” or “routes” of how we’re doing our work. In the picture this is the twisted line. And as you can see in the picture there are two lines with different colours.

Each line is different and this is caused by the background of different people. The tester has other knowledge; another role and other interest as for example our customer. The tester for example knows a lot about test approaches,  test design techniques and more While the customer has the interest to deliver the product in a specific time, to overwhelm the market.

I think that in what kind of role you’re having, the definition is equal. But the goal is shared, in terms of delivering an information system that fits the use and meets the requirements. Because of a background the route (twisted line) to reach this goal is different.

So realize that if you’re doing your work, there will be differences. But what more important is, there are agreements and there’s always a common goal. Try to figure out how this drawing fit in your situation.