Seminar: Are you innovating

Although this is not a correct translation it might make things more clear then call it "Innoveer jij mee!"

Today I attended a free seminar sponsored by Ordina with to great speakers: Gojko Adzic @gojkoadzic en Anko Tijman @Agiletesternl

The evening started with a long row to obtain "bad" coffee. With this start everything can only improve. And it did. Sure, there are always some things which are worse or could be better. Let me start with some small notes about the impression I gained. It is not the full story, just some snap shots and ideas.

Gojko's "Sleeping with the enemy".
As the chairmen mentioned, "Oh, no, not that again" It was not about testers and developers. Us and them. Hearing Gojko mentioned these words I immediately thought about the song from Pink Floyd Us and Them

Looking to the lyrics it can be so true. It also start with:
"Us and Them
And after all we're only ordinary men"

Gojko did not emphasize the idea of Us and Them. What I remembered was that he want to skip the functions. In teams we don't need functions, we perhaps need roles. We should get rid of our who's to blame culture.

He started with a great statement "Why are we[programmers] going to stop telling testers how to do their job? They know testing much better than we do!"
There is still some discussion possible if developers should test or testers should test. I think we should do both. I will come back to this later on.

In my opinion he used a very strong example. (Keep in mind that these are some pieces I remember from this evening. Therefore these are my interpretation and words).
A driving instructor is not telling you: you hit that car, and that car and that pedestrian. A driving instructor is teaching you how to drive.

A similar thing we testers should also do. Teach the developers how to test, participate. If they are able to do the testing for you. You gained time to do more important things.

Meanwhile @michelkraaij tweeted a statement @gojkoadzic, you keep making the distinction between developers and testers. Testers ARE developers!

We discussed this in the short break and Gojko marked that within a role there is also persons are involved. I translated that into a thought that personality is also important how a person can interact within his role.

So I polluted the twitter sphere with this idea as response:
ppl matters,personal value creates personality help define skills 2 form attitude able to act in a role

My idea with this statement is that it is easy to think that every one should be able to test or develop or do the same. Skills should be equal. Who does is doesn't matter. If people are involved we should respect them and human beings with a certain value. People differ and therefore have different personalities. I think the personality able a person to use their values under certain circumstances which will express their skills under those conditions. When it is noticed, people will respond on it and this will influence their attitude. And now based on the attitude, the presentation of the role which is needed will be express also. (don't shoot me for these thought, it are just ideas which seems reasonable to me, I did not read a book to support these ideas)

As promised, based on this concept it should not either be developers or testers who do the testing. Testing should be done by those who care about testing. If a developer cares about testing then let him test.

This was in other words also Gojko thought; he explained that when testers were involved quality reduced as they rely on the tester and no longer on their own skills/value (testing).

After all Gojko held a great presentation with hand drawn slides :) With perhaps a credo: "let developers help us to test so the testers can do other important things."

I think this can also be expressed by the words from Pink Floyd from the song mentioned earlier "And who'll deny that's what the fightings all about
Get out of the way, it's a busy day"

Agility in the waterfall?

After dinner Anko started the presentation he also held at Eurostar 2011 called "Building a Quality Driven Team". After some introduction he came up with some slides I initially thought he wants to bring us back into the waterfall. I can come up with argument I reject his story. I think he showed me some other ideas concepts. He made me think. Although his slides seemed to look like waterfall explanations. If I turn that concept around: He made me able to bring put arguments to the traditional project manager who relies on requirement, design build etc till it is good and supported by waterfalls ect.

The model Anko made for me was a model I could use to explain how certain phases of Agile testing fits in a V-model approach. If a PM fancies a V-model, why not use it to explain your thought. It can help to express that your ideas about Agile attitude and quality firs in his project also, only there are some other conditions. You might be able to build a bridge between different thoughts and gain some understanding. This might be a solid base for obtaining commitment.

Anko posed another statement about the emotional acceptance factor. I would translate that into an example I learned a few years ago.

I was on a project with the ideas of Agile and with a lot of commitment from business, team and project management. We tested together and did a great job. As well as developers and testers were able to tell on daily basis what they did and how the project was evolving and value was introduced. We were almost finished and one of the stakeholders complimented us with the result and made one final addition. I see you did a great job, I see that the quality is somehow made visible. The only thing I would ask you to do: Coach and support one of my key-users, make him test in his uncoventional way. if you are able to help him gain trust it would help me to sell it to the business.

This was not about not trusting our results. This was about some feeling based on emotions. This was emotional acceptance.

Hearing those words, I start remembering more of those examples. It is not explicitly written in books. It is there. And we should care.

There are more things I have remembered and should remember. After all, it was a valuable spend evening. Of such value I want to share it with you.

At the end I had some great conversations with other people and thanked Anko and Gojko.

While driving home I forgot to ask him if he had a copy of his book available and ready to sign, perhaps another time (@gojkoadzic you have my card :-) )

Navigation by blindness

Let me start again with a phrase: a few weeks ago.... some how I got triggered by the navigation system I own. I drove back from work towards the place I call home. I push automatically the “home” button and the navigation system calculated the optimal trip home without asking me for any questions if I prefer another way to follow.

Normally I would consider this normal behaviour and follow the advice route or ignore it. This time I got aware of “it”. “It” gained is this situation a new context. “It” turned from an accepted situation of which the rules did not matter into a situation with several conditions. “It” turned into a predefined path into an path which could be overruled with made decisions which I controlled.

You might think, this is nothing strange, you always follow the route which is calculated, or you also overrule the calculated route.
If so, are you able to make the connection with software testing? Do you even wonder if there are connections?

At that moment driving back at home there were several things I thought of:
- Why do I ask for a defined route calculation although I know were I am, were to go and how to drive?
- Why did I still continue to add the destination?
- Why was I curious about the ETA, I had a watch and I know how long it would take approximately and somehow it was not higher maths?
- Why did this remind me of some moments in regression testing? Performing the same actions although you know the outcome?
- Why did it give me a bad feeling that using a tool did not provide me any additional value?
- Why did it feel as false trust to rely on a tool although I could use my own knowledge, skills and senses?
- Why did it look like I was in control and in testing using standard regressions test or standard automated tests provide same feeling of control?

So why do I bother at all to write about such a simple action. That is “Why”.

While driving I deliberately ignore the advice as I know another route, not faster, not slower, a route which worked for me. I ignore the tool, the navigator, and followed my route. I used a who-cares-factor.
So who cares?
I cared because:
- I got aware that I was able to overrule the system
- I got triggered to ask me the question why to ignore the system
- I added new value to the meaning of the route, as I was curious about some parts of the area
- It made me also challenge the tool I was asking for information. I compared the initial prediction of ETA combined with KM’s to drive with the newly forecasted information
- It made me able to listen to my car under other conditions, instead of driving 80 km/h driving the care with 120 km/h. somehow certain speed at certain moments gave some other thrills.
- I got aware of a situation were things seems so obvious you have to change focus to learn new things and redefine old behaviour.

That evening I learned more about not following blind advises provided by people or systems. I learned to play with the context, instead of accepting the situation I got new insights about the way I behave, think and act. I learned that I and perhaps others using tools out of familiarity instead of certain purpose which value has changed.
I learned that if you don’t change the situation or circumstances then the value will be minimized. This remembered me of a lessons I read somewhere sometime that if you don’t change your regression tests then they are worthless, they don’t add anything. So why do it, spend time, and valuable skills if you skilled testers?

I think we should avoid navigate with certain blindness by relying on tools and defined routes. Instead we should change our test cases and not rely on our “old” regressions tests or other tests we scripted in the past.