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 :-) )

Is Agile development/testing also recalled?

The book
Sometimes I heard and read about the “Toyota Way” when reading articles or attending presentations related to Agile Testing/Development. Quite often the Toyota Way of working is mentioned to support the Agile way of working/Thinking. There seems to be a good book which explains this approach. I hoop to obtain this book very soon : The Toyota way – Jeffrey K.Liker ISBN: 0-071392-319>

The source
Even a “wiki-pedia” page is supporting the approach and mentioning it is one of the pillars of lean software development.
From Agile software development: "The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development"

The Assumption
When you follow the news lately you might have noticed that cars are recalled. In this case also Toyota. If I assume correct, then the products of Toyota are also cars, their way of working is like the Toyota Way. Based on that way, cars are produced. If cars are recalled because there is an error in the software. then it seems that people rely too much on that approach. If this approach is fallible, the perhaps the approach which using it as basis is also fallible.

The news
Quoted from Toyota Recalls Reach Prius, Hybrids on Brake Software (Update1): “In Japan, Toyota will call back 223,068 hybrids to repair computers in anti-lock brake systems, according to a notice filed to the Transport Ministry today.
“We will redouble our commitment to quality,” Toyoda, 53, said today in Tokyo. “I would like to apologize again to our customers who are worried about Toyota’s quality and safety.”

From the same article: "49 Lawsuits
“The carmaker faces at least 49 lawsuits filed on behalf of customers in the U.S. and Canada seeking a range of damages in sudden-acceleration cases. It also faces at least 13 lawsuits brought by individuals claiming deaths or injuries.” "

The question
I wonder if an error of a product have such an impact would the approach also be revised or only the products of that approach. If parts of the agile thoughts are based on the Toyota Way, shouldn't the Agile approach also not be recalled for revision? Shouldn't the people who are relying on such an approach be recalled?

Recalling
I don't think Agile should be recalled. Still we can learn and should learn from it. If you rely on an approach, keep questioning that approach. Perhaps the issues could be found if they tested better. Looking to this specific issue I can imagine that this error couldn't be found in normal testing easily. Experience testers can make the difference here. Instead of checking exploring or thinking about "touring" might helped. I wouldn't recall Agile. Instead using an example as this to define other tours might support/help.

Risks of "definition Done"

Somehow I see some risk in agile projects working with definitions of Done. Here some risks which slips my mind.


Risks:

- Usually only the functionality which meets the "definition Done" will be shown in the demo to the customer. Undone functionality is in the code available although it is not presented in the demo. This might lead to failures in production because based on acceptance of items Done a release might be shipped in production;
- If there are minimal skills in the teams and organization the "definition Done" might also be too small. This might lead that although the software meets the definition huge errors related to fit to process and usability will occur.
- Business has too less knowledge to define a "definition Done" and the team supports the definition phase based on their current knowledge. Definition is written mainly from technical perspective due to expert knowledge of the team of coding and too less knowledge of the business processes;
- "Definition Done" is used by project management to meet their project goals and deliberately narrowing the scope and content of the definition during the project. Instead of proofing that the system fits the business it is turned into proofing that the system fits the project.


I know that there will be more risks to mention, these were just some few which slipped my mind. I certainly not am saying that Agile is not working. I certainly not am claiming that "Definition Done" is creating false trust. I just wanted to show that we have to precise on defining Done instead of stepping too easily over this important tool.

9 reasons why agile testing could fail

Agile development is hot. When there is development involved there should also be testing involved. I think it might be hard for a traditional tester to be involved in an agile project. Here some thoughts of mine of which I think Agile testing might fail:

1. The tester might be outnumbered by the developers and therefore their voice about testing will be ignored or even the tester ignores him self
2. Only "Done" Functionality is shown in demo, the undone items are also their, if the business decides to take the product in production they accept the risk that untested, undone items are also face the production line
3. In demo's only the working items are shown, won't it be good to explain also what is not yet working?
4. If Agile is new for business how can equally trust exist? Understanding is a basis for trust, if something new you cannot expect that business understands what the team is doing or trying to do. If trust is not available in the beginning delay will start and adaptation and learning will be much harder.
5. If trust from the business is based on traditional methods then part of this trust is also based on traditional testing. A traditional approach might danger the benefits from an agile testing approach. The schedule might slip and also reliability in functionality and value;
6. Often you hear that the first 2 a 3 sprints are used to define structure, process, communication and mutual understanding. On the other side you hear that an agile approach is also very suitable for small projects (not only large projects) which needs quick delivery. If already 2-3 sprints are lost nothing will be delivered within a small period of 3 months although the business needs the functionality already now. This might turn into mistrust. The project will fail after all or cost more money
7. Experience testers are focused on traditional testing approaches and traditional testing techniques and demanding traditional documentation. If this is not part of the definition "Done" they might be using time to gain that information instead of supporting the team and adapt their approach to identify the value which is delivered.
8. Agile developers and traditional testers might not be able to adapt their selves to the team goals as in human nature there is some suspicion towards new and old approaches. they are not looking how they can support each other instead they are spending time to convince each other
9. When agile approach is new for the business then the team values the proof that their approach is working above the transparency of their work. Metrics are tuned on to this proofing activity. As testing is often used of proofing the quality of products, often they are also used to proof the process. Metrics are presenting a more ideal situation of the project instead of the value for the business

I'm sure there are more reasons why Agile might fail and even more reasons why it will become a success. The points mentioned above are just some thoughts of which I can think of why it might fail after all.

SCRUM: definition "DONE" and the influence of a tester

What I hear and read about the impact of SCRUM for testing differs from success stories to fear when using SCRUM. When using SCRUM a tester might have to change his perception of testing. In these kinds of projects requirements are not that solid. Documentation is not that final. How are we able to test? How can we influence as tester a development process like this?

There are some ways we can walk, here some of my ideas:

I think the power lies in the concept that the team is responsible for the delivery of a potential shippable product. The first thing which comes up in my mind is: Make sure you are on that team. Become also on of the responsible persons. Don't be the outsider test coordinator who sit down and wait until everything is delivered.

When you are on the team you can discuss about one of the concepts of SCRUM: the definition "DONE". If it is important that documentation is available and also according certain standards you have to bring this up for discussion and see if it fits in the goals of the organization that time is spend for good documentation. The same you can do with requirements.

I'm sure that there are more opportunities to help the team, the organization and yourselves. I suggest start with these 2 basic steps first.