Sunday, November 30, 2014

Exploratory testing teaches a growth mindset

I spent a significant part of this evening re-listening to a great keynote I remember being moved about at Turku Agile Days a few years ago: Linda Rising talking about The Power of an Agile Mindset. I remembered the basic message from the first round of hearing the talk, so I spent this round on more of a personal reflection.

The talk is about fixed vs. growth mindset - latter which Linda calls Agile mindset. The basic idea with mindsets is that what you believe you're capable of determines what you are actually capable of. If you believe in effort and ability to learn instead of believing there's a fixed amount of smartness you were given, your results tend to be better. Actually, believing you capabilities are fixed, makes you worse over time. There's a point in the talk that I like in particular: Linda tells that regardless of what your mindset is today, it can change. And that changing mindset happens through emphasising learning and failing being ok.

On my career as a tester, I found a concept that became central to the way I think about testing: exploratory testing. To me, it is not a technique, it never was. It's an approach. But listening to the talk, I realised that as an approach, it has also been a significant teacher of a growth mindset.

When I collaborate with testers who believe in exploratory testing being pretty much all testing, we talk about learning. We talk about tests being experiments we set up to learn something of value on the software system we test. Experiments provide us information, sometimes failing to provide information we expected and we learn and adjust both our expectations of what is valuable and the experiments we would run next. We talk about testing being endless task and we encourage each other to start somewhere, fail and learn, try again, to put effort into testing in a manner that allows the best possible results with the time we had at hand. It encourages me to try and fail, so I can always try and fail without fear. It's normal, it's expected, it's what is supposed to happen. Trying is worthwhile and necessary. Learning that it works is just as valuable as learning the ways it doesn't work. If the system seems to work, try harder, work more, think more. Only through really trying to show things as broken you will get close to showing it isn't. Close but never there. We test with the attitude of loving the challenge, always knowing that regardless of the results, testing is a chance of learning a lot about the product and the context around it - and of ourselves.

As Linda on the video moves to talk about bright little girls, praised for good results not the effort, I realise how lucky I've been with support from the exploratory testing community and ideals that praise the effort. I work hard to learn but yet make my choices on what I will learn next as the most valuable thing that makes me better at what I want to spend my days on. At school I was a bright little girl praised for results, but I soon got into communities that praised the effort and learned to love the the ability to learn over results. Exploratory testers - or context-driven testers - have been one of those communities. It's not what you are, it's what you are on your way of becoming. It is great to be around people who encourage me to have a growth mindset.

When I do talks on exploratory testing (well, testing in general as all testing is exploratory), I seem to often remember to tell people that the best part of my work is that I get to learn so much. I get to learn every day, so that I'm just a little better every day, and that I believe this will be the case indefinitely. Learning takes effort and the effort is worth it. But as there's limited number of hours in the days even when you combine work and hobbies like I have, you will need to choose what bits you choose to learn. Various combinations of choices can help you be useful in software development.

Bright little girls in schools in particular would benefit from the message exploratory testers have to give on learning. I feel even more strongly that in addition to teaching programming, we should teach testing, and we should teach mindsets. We need to tell our bright little girls and boys that effort is important. It's just work to learn new things. And learning through testing is a great way of learning about how wonderfully interesting software is.

Saturday, November 29, 2014

Safe co-learning and learning about oneself

A few weeks ago I was asked to set up an opportunity to teach "Teaching Kids Programming" -course at a local elementary school in Finland while he was visiting. I contacted a local school, Ylä-Malmin peruskoulu, as I have my own son there on first grade and we set up a few sessions with 8th and 9th graders.

I volunteered to co-teach, but also felt somewhat of a fake. I love computers and software, but if you've ever read anything I post on my blog, I'm not a programmer. I've passed various courses on programming, even implemented occasional minor production features, but I love testing. Not checking (automatable part of testing) but testing - thinking and learning through exploring. Teaching programming, when I have high respect for people who enjoy that while I don't, it's a bit of an odd compilation. 

On the first class, I was walking around the room helping the students until I was at a point of me supposedly leading a part of that class somewhere in the middle of it. The first class was largest, loudest and had most difficulties in concentrating. I failed to get their attention and needed to give up - intimidated by the 8th graders. I could easily remember discussions with a friend of mine from high school who would become a teacher and me swearing I would never ever want to teach grades 7-9, the behaviour our teacher could expect from us back then was just this - not paying attention unless you deserved it. 

With failing once, I set out to not fail a second time, at least not the same way. I would ask to start the class, instead of jumping in in the middle. And then opting to jump out later if I felt I couldn't remember the material, as someone else's material is a very different experience than one's own. 

In retrospect, little did I know of what "co-teaching" would mean. It would mean that by Friday (3rd class), I would be co-teaching with a local teacher from the school and that by the last of four classes, Llewellyn would leave the class leaving us teaching. It also meant that the local teacher will teach more modules from Teaching Kids Programming -materials, as he was telling us he would run the course through spring semester with his computer science students. Co-teaching ended up being a great way of supporting us and enabling things to continue. 

All in all, this was a fun experience. But again the stuff happening inside my head puzzle me the most. I felt safe co-learning materials with the students. I realised again that I set my bar on "programmer" label quite high, and almost regardless of what kinds of programs I could write, as there were things I could not write, I would feel fake. I realised the bar is higher for me, and only set by me - perhaps a little by a brother of mine. 

I'm starting to feel that my year of exploring into code & programming will actually end up taking me deeper. I've found groups I'm comfortable with. I've found application areas I'm enthusiastic about (not checking!) to want to program. One thing has not changed though: I've always known it would be just a matter of choice to learn more about programming. Choice is a time-commitment though. It's always an opportunity cost - leaving out something else. 

I want to learn more together with my kids. Programming, exploring, different fun stuff we can do with technology and the wonderful application areas that I would feel particularly passionate about. Passionate enough to harness the tool of programming outside the "asking programmers do the programs" -idea that I've been working with so far, very successfully. 

Thursday, November 13, 2014

Facing my fears and feeling ridiculous

A fairly long time ago as a student, I wanted to apply for the board of the student union. I remember the day vividly with a strong memory of the feeling of panic I was facing as I needed to introduce myself in front of an audience of a relevant size. I was afraid of public speaking. Afraid was an understatement really, I was panicking. And the mere idea of having to introduce myself with a few sentences cause physical symptoms and while I did it, I was shaking so hard that people were really worried I would pass out - for a good reason.

I did not get to do what I wanted with the student union, but there were other ways of contributing that were probably more appropriate. But that one day and that one experience led me to realise that I want to work on paralysing fears and change things, instead of accepting them. I took a course in oral communications, went through the awful experience of speaking for the class with video and watching that video with the teacher so that I could not avoid it. I learned to talk about my ideas and experiences as opposed to others ideas and through that I realised I could control the experience for me. I could control the fear. I continued stretching myself way beyond my comfort zone, taking a job that included lecturing and starting to do public talks.

People who see me present nowadays have hard time believing the background story. I've worked hard to change my experience, and I still work hard on my presentations and contents. Professionally, it's been one of the smartest moves I've ever done. I'm no longer a least bit afraid of public speaking. When I felt discomfort on doing webinars, I did more of those. I go and face my fears and I grow.

Today, I participated on my second code retreat facilitated by Adi Bolboaca. Or actually, first one, as the other I participated I monitored from the side. The idea of pair programming made me feel panic. I have no problems pairing up for exploratory testing or clarifying requirements, but the programming part brings out irrational fears. I had not really realised how relevant the fears were, I had been coming up with all sorts of excuses on why I wouldn't join these events. I needed someone I love to tell me that knowing the background story of my fear of presenting, pair programming was something I needed to do. To go to the code retreat, I needed people to check on me to actually go and make room for this in my calendar, not giving me the option to back out.

Code retreat was a therapeutic experience for me as a tester, kind of like the video of me talking back in the days. I got to pair with five wonderful developers - one of them twice, who were friendly and helpful - and did not end up hating me like I feared. I did not feel useless. I felt I was learning, I felt I was even contributing every now and then. I felt grateful to people who encouraged me with the idea that it would be ok to pair with developers even if I could not write code at all. And with this experience, I think every non-programming tester should take part in a code retreat and trust that people who are that enthusiastic about building their development skills are also happy to learn about collaborating with people very different to them.

During the code retreat day I got to work on Ruby, Python and Java - not c# at all, which would have been the working language from my office as I found that too much of a stretch for me to begin with. All sessions ended up being Test-Driven with developers already experienced in that, and turned me into a real fan of TDD - I want to learn more programming this way.  While I avoided writing the code and focused more on commenting, one of the developers in particular was really nice and helpful guiding me into taking my turn in writing too without making me feel like the idiot I was setting myself up for. Well, the fact that it was Python and I had done a little bit of Python during summer did not hurt in persuading me to try that even without a proper IDE configured.

With this behind me, I recognise I'm not done. I did not win my fears, but I crossed the first road. And every day at the office is another road I can now cross. Some of the experiences I want include pairing with really good people - professionals in pairing. Some of the experiences will be pairing with people who don't want to pair on code with anyone, let alone me.

Main thing on my mind right now is: why did I think I would rather learn programming alone than pair up with people who volunteer to help me? Learning a little is still learning, even if I would like to be perfect. Having faced the first paralysing fear leaves me feeling ridiculous. How could I not see that wonderful people are wonderful, even when I'm afraid. 

Friday, November 7, 2014

Lessons Learned on Standardisation at a Finnish Standards Meeting

A few weeks back, I was invited to a Fisma (Finnish Standards and Measurement Association) meeting to discuss #stop29119. Fisma is the Finnish counterpart for international standardisation, participating as one member country in all the different committees someone ends up being interested about. The meeting was futile attempt to do anything about an impossible theme, but I came out with some lessons I considered interesting.

With what I learned there, my summary is this. The whole standardisation thing is based on fooling customers of standards into believing they might be buying something useful and respectable. Fooling, because the process of creating standards really sucks.

1. Power of individuals who volunteer in creating standards

Listening in for the whole meeting about deciding on standards and introducing ongoing work in the area of that particular working group, I came to realise how weak the standards creation process really is. It seems a standard emerges from someone having an interest to spend time on writing a standard and finding an appropriate (politically acceptable) title for it and then working on the contents through a great number of stage-gates.

There is no requirement that the standards authors would actually be really experts in the topic. It seems quite common that some professor / researcher from a random university volunteers time and effort on creation of a standard, and if people in countries are not really strongly against it, the process flows forward through various votes.

Countries decide which standards they participate on based on people's interests they themselves have available. If there's an agile standard on the way (and there is, scary!), Finland will participate if there is someone volunteering for the work. Finland (or any other country for that matter) opting out from the work does not mean that the work would be rejected. Rejecting requires active work and more often end result of disagreement is to create just one more standard with a slightly different title.  Organisations pay for being in positions to volunteer and organisations pay for the end results to finance a relatively complex system.

There is very little quality built into the process of creating the standards, quality is left for paying users to assess. The requirements of expertise are not exactly high for entry.

2. Early detection of problems only

The standardisation process is a process with many stage-gates. It was interesting to listen to discussion where a comment would be "how did we vote last time, we can't change our mind at this point". If you plan on changing the contents or getting the standard rejected, you have to be voting against it consistently from the beginning and build a case on it not improving. You will also need allies from other countries. It was interesting to hear that "Japan and USA voted against but this still goes forward - they always vote against". And still the standard gets created unless more countries are against with severe observations marked for the review process. With 28 countries voting with the process requiring severe observations to be allowed to vote against, getting a standard through does not seem that complicated. Voting to disapprove you get to go into a hearing - that had very negative connotations in the discussion. And being passive is approval. The process is awful.

Things such as early bad quality hiding more severe problems was not visible at all. If I have to read a document avoiding gaping holes, it is highly likely that the large holes steal away my attention. Regardless, changing one's mind is not encouraged.

3. No drawback mechanism and how a standard dies

#stop29119 calls for withdrawal of the standard, and I learned that the process of standardisation really includes no such mechanism. Standards exist until they become obsolete, if they have been accepted. They become obsolete if during 5 years a new working group to update - even slightly - the standard is not formed.

The only way for a standard to become obsolete is that no one volunteers to work on it. Since volunteers are again representatives of paying organisations, those who have interests in standards existence will drive the updating. A standard seems to only die of no one is willing to contribute into it financially.  #stop29119 people buying the standard for review purposes actually contribute financially to the standard to continue to exist. Not participating, not buying are the ways to kill a standard and even then, someone isolated can quite easily keep it alive as long as there's a business to be made on its existence.

4. Standards are just guidelines, you don't have to use them if you don't declare compliance. 

The whole discussion about that the word "standard" means seems like a bad joke after the meeting. Standards are all optional, so the standardisation process itself does not include the idea of it actually being required for compliance. Compliance comes from a user of a standard requiring compliance downstream. Standards are just prepared paper piles that create work for those who keep them alive. We waste our efforts into thinking that standard would be of any value, and that it would be based on anything other than the idea of someone being fooled into using it with vague marketing talk.

5. Thinking standards show an area is worthy

It was interesting to hear remarks that Testing is now worthy area, as it finally has a standard. That areas of relevance gather more standards. If a standard does not apply, an optional other standard can be created with just tweaking the title for more specific case.

The way standards are constructed is that you don't really mention the context / application area but leave that for the users of the standard to think about. Which again underlines the idea that you must be a fool to pay for a standard and that those who consider using the standard are the real audience to talk about what is bad about a particular standard.

CONCLUSION

So, lesson learned. Don't buy the standard. Don't finance it. Don't comment on it to help improve it. It might wither away and die in 2016 if no one starts a new working group to update it. As the Finnish national board participates annually only in 10-20 % of standards ongoing, we mostly quietly vote for yes.

The change must start with the users. Other than that, we waste our times and efforts on something that is just rotten.


Thursday, November 6, 2014

Power of stories and how a one hour presentation changed the world around me

This blog post is about appreciation that I almost forgot to express, and my public thank you for Henri Karhatsu for doing something small that changed  a lot.

Last spring, I was trying to find ways of helping my team's developers be injected with new ideas. I brought in two people from the community to talk to my teams for an hour each. The other talk was technical talk about single sign-on, and the other an experience report, story on #noestimates by Henri Karhatsu.

Henri's one hour at my organization had a huge impact - it has literally changed the world around me.

For my first team, it was the trigger for moving to continuous deployment through giving up estimates, and built on that experience, it has changed the tools we use and atmosphere we work in. It served as empowerment for people to start acting outside their perceived roles, and start trying things. This team had everyone in the presentation. The day after the presentation, estimates were removed and since then, a lot of other waste too.

For my second team, the message stuck with the developers but empowerment to act on it was only found later. The team continued for several months estimations and I feel part of the delay came from the fact that the story was not shared for the whole team as the project manager had not been in the presentation. This team too is now much lighter on estimates, and with support of an external coach, is learning more about how to change things and to take the best out of what we've got.

Henri did his talk as a favor for me, and looking back, I can only wonder why did I not understand to ask him for a visit sooner. This blog post is my public appreciation for a small thing in the community that made a huge difference in our organization. Ask people to share their stories for your organization. A small, short talk based on an actual experience can change the world. You learn who has great stories by going around in the community, and people sincerely want to help. It is wonderful.

This particular story was delivered with a personalized end message:
This picture is from our company web page, stating a message "Creativity is courage / daring". Henri came with a personal story that he brought back to a message that was key to what our organization is. And with that, we found the courage that was missing, and I should have remembered to tell him sooner how much I appreciate what he did for us.

Discomfort of specifying behaviors

There's a significant difference of attitudes towards specifications that I see in developer colleagues close to me. Groups with attitudes seems to be equally strong in numbers, so this is not isolated behaviour of one individual.

The first group seems to take specifications as something given from the outside. They seem to believe in this other person thinking through the things that need to be implemented, and take their own sense of responsibility only within the context of that spec. While testing and noticing that what was implemented just makes little sense, these people easily revert to defensive. They say that not being able to do things related to the purpose of the feature is a matter of opinion and that they cannot work on the fixes before someone specifies the wanted behaviours. Occasionally, they also get very strong voices in discussion of what is a bug vs. change, being right about the idea that most bugs would be things that they never considered in scope they accepted and thus changes. Getting hung up on the definition of defect vs. change does not help, it all is just work that may need get done and fighting over definitions is time away from implementing the necessary changes.

The second group seems to treat specifications given to them as useful fiction that starts conversations. These developers seem to be at ease with discussions that result in dropping features out of scope, finding the core of what needs to be done and implementing that first. They have no problems in making suggestions: it could be like this or like this, here are the pros and cons I see of these solutions. And their approach often seems to end up with a different solution than they suggested, building on the compromises and deeper understanding of what is being built.

Talking to people I place in the first group reveals a great deal of discomfort on how I would like to define the role of a developer in relation to their definitions. While I feel I thrive with the idea of making decisions of how things end up being (until changed as we learn), these people seem to be drawn way out of their comfort zones in making a decision and thinking through the consequences.

It seems I will end up having an equal amount of both in my teams, and I'm thinking about how to make the first group willing and able to join the ranks of the latter group. People in the first group are really dependent on someone testing a great deal for them, someone specifying for them whereas the latter group is more independent and self-contained. It has a direct impact on portions of other specialists we need to add to the teams. Both of these go with "developer" title but have significantly different results how ready things end up being after them.

Pairing people up is one approach, but it seems not to be enough. The rejection of responsibility towards specifying behaviours and externalising that seems to come from an early lesson learned, that seems very hard to unlearn.

I'm curious as to if people have found ways of growing themselves out of patterns like this, and what would be the key realisation for the change to happen. Some suggest that old dogs don't learn new tricks and we might just have to compensate for lack of tricks in one with another person in the team that will do the tricks missing from the palette.

I wonder when we will learn to build teams of growing individuals instead of thinking of filling role positions. Given a chance of choosing who to work with, I always take people from the second group. But I wonder if I would then be missing out on something with lack of this diversity.