Participating Hour of Code - a one person view

I've been thinking and preparing for quite some time, but some weeks back I got together the final details to take action. I went to http://code.org to be reminded that Hour of Code week is December 8.-14 which also serves as a nice start for the Smart Creatives Club I've been volunteering to run with my son's school as soon as we get all practicalities sorted.

Smart Creatives was a term I picked up from a presentation by Eric Schmidt at time I was trying hard to explain why I dislike the concept of "code school" that misses out a core of what makes me love work in technology.  The following picture is from the presentation.

Instead of growing programmers of the likes I meet mostly, I'd like to see my kids grow up knowing technology and programming, but putting that together with understanding of purpose (business) and creativity, and choose a corner / combination they will love the most. I really love testing, and find that out of these three, my focus is more on creativity and business expertise, but technical knowledge is there as well.

I've also grown really fond of this list that went around in twitter a while back. I don't want to teach kids to write code, I want them to learn ways of collaborating to create solutions they would find useful. I want to emphasize collaboration. 

Emphasizing collaboration makes Agile Finland ry a perfect home for the things I'm setting up. I'm really happy to be able to announce that my favorite non-profit is there for participating the code.org code week by having an open free Hour of Code for 30 kids on December 8th 18.00 - 19.30 at Leppävaara Library. And that Agile Finland is equally supportive of the private Hour of Codes I will do with two groups at kindergarten Viskuri (5-yo & pre-schooler groups) and group of 1st graders in Malmin peruskoulu. The one at Malmin peruskoulu will then continue as a monthly club, not about programming per se, but about creating together, in collaboration. So far I've decided we're going to be working on multi-media book created fully by the kids for the spring 2015, meeting once a month.

Last week I had the pleasure of meeting a 15-year old girl, who as far as I understood, did not consider computers as something she would be particularly interested in. Spending a week testing with us and being actually very very useful with the courage to speak out, I hear she is saying that testing might be fun. I've agreed to hire her for some of the work I would need done for my side business, and will invite her to join me to co-teach (being paid) the Hour of Code. She might not end up with the love of technology and testing I have, but I think this might also be infectious. Pushing code first isn't the way to keep me engaged, perhaps that could be true for others, like her, as well.  She's super smart, and it would be a loss if she missed out on the best job there is in the world - creating with computers.

I've just published a call for action for others to join for the Hour of Code in Finland, I would be happy to help out locally. There's a huge need for volunteers to show the ropes to the young ones, and I'd love to see us agree that code is just one tool yet a very powerful one.

Empowering developers to do great code

Good conversations are powerful. I made a new friend over organising Tampere Goes Agile last weekend. As he seemed curious about me presenting - something I don't get to do when I organise - he found a video of my talk in Latvia two years ago and watched that. Having watched, he pointed out that I said something horrible. At a point of the conversation I'm having with the audience, I refer to how things are at my current, back then new, place of work. I talk of large amounts of bugs and the number of people testing, and the idea that with a lot of bugs, there's a lot of fixing so adding testers might not be a smart or necessary move. And I say that developers don't care for fixing bugs.

I found that observation particularly interesting, since the answers I tend to give come out of context I work in. Back then, I was struggling with a new team that released once a month but were lost on all kinds of testing. Releasing once a month was "agile" to them. The work was very heavily lead content-wise by a product manager, who would tell the developers which bugs they could fix. The product manager would easily decide on refactoring as well, the team was very much powerless. The fact that the bugs got listed as feedback was new, and there was not an actionable mechanism of fixing that many issues all at once. It wasn't due to regression that the product was broken, it just was that way and the end users (or the product managers) wouldn't come back with that feedback unless they really had to.

Talking about that point with my friend made me realise that the world that empowered agilists live in is quite different from this one. You get a lot of say on how whatever you're implementing gets implemented and you work on making code beautiful, not getting instructions not to refactor from the product owner. You stand your ground on including what is important to include when doing the work, like (unit) tests. Refactoring is continuous, and there's not a need to go ask for a "six month project" to take time to clear the mess you've gradually created.

With my reaction of explaining more of the context I was in then, I realised two things. First of all, I realised we've gone a long way in the two years I've spent with them even though we still have a long way to go. Second, I realised I was using context at hand as an excuse for me to focus on things in my direct power. There are plenty of ways I could have focused more on empowering the developers. I could have just focused on helping them through the braveness to refactor, focusing on development skill instead of what I was into, the study of my own testing skills in whatever context I was handed.

What may be horrible for some can turn into normal for others, and my developer colleagues had been in that world of normal for such a long time that they had given up to an extent to the perceived lack of power in saying how they do things. They were lacking feedback through testing. At first when they started getting the feedback they had been asking for as I joined in, it really depressed them. The amounts of issues, the lack of time to handle any of those, that doesn't exactly turn out motivating. Dictating what was to be done from outside the team wasn't motivating. And with the lost motivation, the driving force was the perceived lack of power.

The core of my answer from two years ago still holds. I find no sense in hiring more testers, when the needed focus on a team is clearly on the side of fixing. But the idea of developers not caring to fix the bugs is an unfair statement. When pushed not to think for a long time and give in on the level of quality you would want to deliver, you may appear not to care. But often that is just a way of coping.

I know my developer colleagues a lot better now. I know they care. I know they can do things. I've had people over training them on unit testing (and refactoring while at it) and coding in general - things they did not get to do enough. And they've found their inner strength to feel empowered to do things better through teamwork and new technologies that boost their motivation as certain things (performance related) are now in the realm of possibilities.

The same team that I commented on two years ago as developers who don't care now work in smaller chunks, reacting to recent feedback instead of having to fix a pile of problems that had been left back from the lack of feedback they always requested.

I just love the power of good conversations, that leave you thinking to a point of writing a blog post in the middle of the night. This conversation in particular is a good one, the core reminder for me is that the positive thinking on what my developer colleagues do turns into a positive change over time. I should be careful implying that people who have not found the power to use their smarts would be intentionally that. Empowerment and encouragement are game-changers for the better. Timely feedback supports that. And there's more I can do to help them, faster.

Two things that bother me on #stop29119 discussions

Let me start with my stance on #stop29119 - I have signed and I think everyone in any way impacted by testing in software should sign it - customer/product organizations trying to succeed on software business in particular.

But still, in all the discussions there's two points that bother me and a lot of the critique revolves around.

• 'Standard' the word and its definition
• Available options for the contents of the standard

'Standard' the word and its definition

A few days back, I saw Lisa Crispin tweet a reply to Michael Bolton that I'm strongly paraphrasing from my memory. The reply was related to a discussion on agile testing as per Lisa's new book and pointed out that not everyone appreciates time spend on word games as they have a full-time testing job to attend to. It caught my attention, as it was pointing out a problem I feel I'm having with context-driven testing arguments, and a problem that is in the core of discussions for #stop29119.

Many people suggest strongly that there should be no standard. Standard the word strongly implies a connection with the regulations, and through that, compliance and lawsuits of non-compliance. I get that. I agree that standard is a very risky word to use if we mean 'guideline'. But I think I hear the other side on this as well.

I live in Finland and Scandinavia is quite different from USA. Really. The whole discussion about standards isn't that big of a monster in the world I live in. It becomes a monster occasionally with EU regulations and it's always been a monster with things regulated from USA. But in the little fluffy cloud I get to live in, it just doesn't matter that much. I'm sure its not equally bad to everyone in USA either. But in this particular fight for #stop29119 the definition of that word becomes a key issue.

Standard the word has many contexts. After all, we're talking of context-driven testing with testing area not having set meanings on the terminology. Words are communication between people, and for testing terminology we don't believe in set terminology but trying to understand and hear out what the other party is saying. How come the word standard is that different from all the other words we use? How come we can't accept that standard in one context is regulation and standard in another context is guideline.

The fact that this guideline ISO 29119 is totally worthless contents that make things worse is a different story. But the basic idea of attacking the word standard seems like word play I don't even care to win. The risk of compliance requirements is relevant for certain contexts.

Available options for the contents of the standard

The other point that bothers me is how many of the opponents seem to handle the critique of not being constructive as in offering real alternatives. From the friendly, yet disagreeing local discussions I've had, I've caught a strong feeling for the organisations driving these standards, there's a real need of a box they label ISO 29119 but that the contents of that box could be something other as well. It might be that I'm optimistic, but I don't like the answer we tend to give on what to put in the box: nothing. We don't do standards. We don't believe in them. I don't believe in them. But I can respect that the idea that drives my local colleagues towards a standard is a true belief in helping out the ignorant in getting good testing. That box needs contents.

I have a personal suggestion as to what to put in that box. I want to put Rapid Software Testing in that box. But to do that, we'd have to get past the idea of the word 'standard'. 

I have an option for the content of the standard. So, the ball is again on the standards organisation: if context-driven (or rapid) testing is no different from the current contents, how about changing it radically. 

Testing starting from that base of values and ideas would be much more relevant that the paper-piling approach the current contents drive towards. It would be helpful to take things forward for the world of agile and still remain relevant with the more traditional mechanisms. We can't say the same about the current contents.

Win-Win?

To get anywhere from here, we need to start making compromises. Compromises to how strongly we feel about the word standards, compromises on how serious we are about no standard-like documentation about testing can exist. The standardisation organisations need to win too, it's not exactly fair to say we want them to stop doing the business they are in. Or is this really something that can, by no means me resolved?

Disclaimer: I'm tired of being attacked for the choices of words or my opinions. This post is very much my opinion, and I'm not going to stress over my choice of words for other than my good intent. I'm happy to engage in discussion that aims at mutual exploration of what (and why) I think that changes my mind. But please, picking on semantics of words without the intent of communication - let someone else do that.   And reminding me on the fact that I'm not a native speaker is somewhat insulting. I just don't care for the exact words, I care for discussion and understanding of agreement or disagreement - communication. 

Seeking for conflicting evidence: agile & testers

One of the things that draws me to context-driven testing is the idea of scientific methods, and seeking for viewpoints that might even be opposing in search of better understanding. For me it's become clearer that whatever I believe in are beliefs, and while I'm prepared to strongly argue in favor of them, there's other people who would look at my beliefs and conclude that I must be wrong. The more of these disagreements I run into, the more I appreciate the idea of mutual respect: there are arguments where winner cannot be announced. But we can still get along, it's not personal.

Agile, testers and testing must be one of these disagreements. All in all, I personally think agile is the best thing that has happened to testing, with the emphasis on feedback (testing) and the cycles that make acting on that feedback possible to extent that wasn't there before.

There's also the downside to agile, which seems to be the constant need to defend the idea of being a tester.

Whatever you are doing in a software team and you help adding value to the product it means that you are a software developer. Period.
— Adrian Bolboaca (@adibolb) October 10, 2014

I'm a tester, I'm not a developer. I try hard being a developer and I feel miserable most of the time. I am a tester and loving every moment of it. Personally for me, it's a matter of staying in software industry. And I believe software is better off having people like me. It's how I feel, and regardless of how much you explain, you can't change that. The employers might change that, not giving me jobs unless I'm a developer. Perhaps that's the core of the argument - which belief system the employers will choose. All I can ask is to respect how I feel and not impose titles that my head refuses to accept without forcing as "no other options" - a very negative way.

It appears James Bach feels something in the same direction with a recent yet completely disconnected tweet:

@mheusser @augeva Sounds to me like another Agilist who is discouraging testers from being testers.
— James Marcus Bach (@jamesmarcusbach) October 11, 2014

This tweet was a reply to sharing a post with an insight that it appears that most people would really not seem to yet get what agile + testing is about (http://mysoftwarequality.wordpress.com/2014/10/10/testing-the-big-agile-misunderstanding/)

But it also reminded me on the idea that other than wanting to call testers developers (or get everyone to code), there's a lot of things I've learned working with agile. Including the idea that having a tester in the team can be harmful and that some teams actually are very successful - really - without a tester. And that the stories of the latter will continue to inspire the recruiting managers to the extent that they are not hiring non-programmers to some organisations.

Tester role can be harmful

I work with an agile-aspiring team as a tester. The idea of shared responsibility for testing in the team wasn't a hard one, as there's so much to test that we need to share the work. I took upon me the ideas of not being a tester (only), but a testing coach for the team - and a coach of all sorts of things that could help us be better together. The developers I work with don't seem to excel in testing, judging from the numbers of problems we need to catch - on average 4 issues / day every day of the year for one tester. But looking at things openly I have a few observations that conflict my own conclusions of tester importance.

1. Developers turn into pretty good testers just by sitting next to them
2. Removing me after I have been there improves quality
3. Testerless teams have delivered really good software

It would seem to me that a big part of why testers are needed is that we allow current developers to rely on externalizing this responsibility. Externalizing the responsibility is a way to make sure testers are needed. And since I sincerely want the best for my organization, I need to think if having a tester around is really that, regardless of this being a core thing for my personal happiness.

Agile teams rely on feedback. The feedback could come from end users, by improving the relationship we have with the real users so that more of them tell about their negative perceptions, regularly. The feedback could come from logs that allow us to see the troubles of the end users, even when they choose not to share their experiences. And we make choices to change the dynamics by investing into systems that allow us to release software to subgroups of end users risking different users to the impact of software that does not work. Small incremental changes are a game-changer. And it has impact on what testing our organizations are willing to invest on. Developers can test too. They can learn to test if they can't test now. And with the continuous feedback, they might actually get really good at testing.

Of course there's a but...

There are teams - plenty of them - that are quite like my team's developers. They're lacking feedback since aspiring to be agile is not enough, you really need to work hard on building the ways of getting the feedback. If your product managers comes and tells that "I did not know it was possible it could work when I start using it", the expectation of quality that team could deliver is very low. If they don't know to expect more, the feedback on the lack of quality is almost too kind to be changing anything with respect to how the team works. If your end users call after a week of your system not working for them at all on a relevant area saying "I thought it might just start working in a few days without me doing anything on it", you're not really talking with your end users to get feedback, but you've trained them to accept almost anything.

There will  be junior developers, who have not learned yet to program, let alone test their own programs. Focusing on all these skills at once is overwhelming. There will be junior testers, who will never become the great testing coaches we would need, since they will not have enough time to think of testing - they're required to grow to be developers. And developers will need testing coaches, exemplary testers to catch ideas from.

Being a junior developer isn't just about years in development. Some people can write code with the copy-paste method after 20 years of practice and that type of code tends to break in real use and be very hard to fix as there's no copy-paste solution. And some organisations will have to settle for now with these developers, as finding better ones isn't possible. So they find one of these, and compensate for the lack of skills by having a tester around.

As much as being a tester is relevant for my happiness, I've met developers who find that not thinking about the end user too much is essential to their happiness. Details of code are beautiful, and the people stuff (people using the software) are just not so interesting. Luckily, there's others who feel the other way around, and together we can be happy and do great stuff.

It seems to me we are discouraging testers from being testers. We encourage them to be test coaches. Use a little less time on testing and more time making sure everyone learns. Share. Use the special superpowers to enable others. And we just really don't need as many test coaches as we needed testers. Which also means we have to realistically say that the tester / test coach jobs will be harder to get. Employees won't be in the lookout for testers in masses. Too many good experiences of not doing so. Including cases where testers were completely left out and new generations of developer-testers emerged.

Confession from a bully for a tester

About three years ago, something happened that shook my life and shattered my self-image for a while, something that I've talked about only to very few people. Thanks to recent events and the realizations they have led me, I finally feel that the burden has lifted so that I can write about this. And forgive myself, others have forgiven me long before.

About three years ago, I was told I had bullied my colleagues. I got to learn this through an email to the whole organization by a personnel representative, who I think was one of the people that I had bullied. But there were also others that never identified themselves. They never came to talk to me. Not before or after the public accusation. I felt shattered. I ended up meeting a psychologist regularly, trying to understand what had happened or how I could cope with the situation. I was struggling for my mental health. 

I looked up texts about what is bullying. That it would usually be about an individual being bullied, someone bullying and others accepting quietly. But the accusation was that I had bullied several people. With all that I read, I ended up with the conclusion that this was a move in the nasty politics played in that particular organization.

I knew what I had done: I had played a part in removing the personnel representative from a multi-million project's project manager position by showing that he could not keep up with the work. That was not personal, really. It was about the success of that project under appropriate leadership and while I had played a part, the part was more about showing pieces that were missing. With this in the background, I was convinced that instead of me being a bully, I was being bullied.

I was different from everyone else - recognized for deeper skills in software development that most colleagues in that customer organization. Unlike my colleagues, I had worked with multi-contractor settings before and there were different things to learn for me than for the rest of the crowd. As I knew more to  begin with, people could use my help on various things and I felt bogged with work, there was just too many things I was needed for. So I started selecting my battles. I could not be available for everyone, and to be frank, I wasn't really interested in working with the ones furthest away in skills as I would get frustrated. I don't recall being mean to anyone. I would choose to not volunteer to help on some things, as I was busy with other stuff. I would check with my boss if I would need to be in some meetings I was invited to. And I would avoid getting into hallway discussions that would divert me from the selected goals. Prioritization, that's all - at least how I saw it until last weekend.

Last Saturday I realized that being a bully isn't about intentionally being a bully, it's about how your well-meaning actions are perceived by those being bullied. It's not only about what I do, it's also about what I choose not to do. And with that realization, I would like to apologize to people I've bullied. Bullying in my case comes from a sense of being better (I work hard on my skills) and how that manifests in my presence. I have authority and power, and I can be intimidating. I also see myself as a people person, always have, which was the reason for shaking mental health in re-seeking my identity after the incident.

Last Saturday was a turning point for what happened. On Friday evening, I tweeted about being a tester by identity not by role - which was a thought from working with agile team on whole-team ownership on testing. James Bach wanted to understand what I mean by I role - a challenge to debate / clarify as he often does and I failed to answer promptly. With the style of questioning, I also turned to ask for a friendlier way of challenging as I felt afraid with him expressing he was upset and expecting more of me. I had to take a pause for groceries and was ready to respond to the challenge with an article I was writing. All was well, I thought and went to sleep.

On Saturday morning, I saw an interesting tweet about #stop29119 James Bach had tweeted, and pressed the retweet button to share it - business as usual. I couldn't. I tried again and couldn't. So I tweeted my surprise out:

"You have been blocked from retweeting this user's Tweets at their request." Twitter, please have a bug and this not be true.
— Maaret Pyhäjärvi (@maaretp) September 27, 2014

I looked around to learn James had blocked me in twitter. All of a sudden I had turned from a good person worth following to someone worth blocking. Since I blurted my surprise out with a few more tweets, I got a fair number of contacts, both public and private, with explanations of why he might do such a thing, even suggesting I could try seeing it as a compliment. For most of Saturday, I was just offended until I realized that this type of behavior was very close to the bullying incident I had been accused of: a general pattern of behavior from one person towards many people.

So with this incident that I still don't understand, I now understand this about bullying. It's about how the other person feels about your actions, not the hurtful intent in your actions. And it's about continuing those actions towards many people, regardless of the fact that many people express being hurt by those actions. Sometimes they express that in words, sometimes by shying away from actions with you. Like with James, I feel liberated with the idea that he would no longer see my tweets. While others question (and questioning is welcome), the feeling of intimidation and urgency is rare with anyone else. It's about how I feel - not equal, but underpowered; not seeking understanding, but to be proven wrong. It most likely isn't the intention.

I wasn't a bully because I wanted to be a bully. I did not know another way then on how to cope with the workload I had and the skill imbalance and other people felt, justifiably, bullied. No one, including the psychologist I was seeing, helped me then. I hope people close to me will help me see if I do that again and help me find better ways of responding, because the feelings I went through on Saturday being blocked by the community leader I respect a lot are feelings that I hope people would never again have to go through because of my actions. I can't promise I'm better, but I can promise I will actively work on it. Because software development is a team sports, and feeling matter. People matter.

On agile, blocks of stone and building cathedrals

This morning, our team's flowdoc channel had a picture of a user interface with a question directed to the project manager, asking if this was ok. The trigger for the picture and question was an issue I had reported saying the previous version of that particular user interface was not ok, outlining why.

I was delighted on the cultural change that the question was done over the channel so that I could see it. Two weeks ago, I would expect to be involved either by accident (overhearing if I spend enough time not concentrating on whatever I'm doing - which I did actually reserve time for) or by testing the resolved issue. With the new picture, I could immediately see that while the changes resolve the specific issue I had raised, it created another issue about consistency. I had mentioned the need for consistency when reporting the issue as a side note. We discussed and fixed the consistency issue by changing the other user interface so that the new idea we were fixing would fit the overall feel of the product.

With the little success of teamwork, I was left thinking about successes and lack of thereof. In this case, I would like to think that I cannot be the only person in my team to think about the overall product experience. But very often what still seems to go on is that while I feel I work with a purpose in mind, we often see symptoms of being very task-oriented and not thinking outside the first perceived box. Ari summed my feeling of the attitude nicely: 

@maaretp "I just work here"
— Ari Tanninen (@aritanninen) September 29, 2014

If we want agile to work, we need to somehow change these kinds of attitudes. We could change it by introducing someone like me, who actively suggests other perspectives - that could be any role, it's more of a personality thing. But the puzzle is how to coach people into really thinking about the overall product and user experience. Can't change the others, but can try to change the system that makes them behave in certain way.

With agile, we rely on active and skilled people in the teams that together do things well. But it might be really easy to end up with emergent roles where mine in this case would be one that reminds on thinking over the limits of the task at hand. And the team can easily be trained to rely on me instead of thinking for themselves.

There will always be people who just work here and don't feel they serve a purpose. I'm the kind of person that would think of building a cathedral even if I was creating blocks of stone. I think I'm that by personality. Am I expecting too much from systemic conditions if I hope that we'd encourage everyone see their work as part of a bigger perspective? 

Tester as a quality coach: enabler that leads with example

I could not make it to Test Assembly 2014 yesterday but luckily there's twitter and all the ideas people share. And as usual, one thing in particular stuck with me: it's very clear the tester role is under heavy discussion whenever Agile gets mentioned in the theme.

There were mentions of programmers being the only ones who provide value, and that message seems to come out strong again today with Reaktor Dev Day ongoing. While it is ridiculous to see "agile" organizations with as many managers as developers+testers (hands-on people), the discussions of elevating developers above the rest of us working hard on a common goal still seems unfair. Writing the code is important. But the most expensive mistake is to write the wrong code and working on that doesn't need writing of the code - we can share the work amongst a group without being in silos with mutual respect.

There seems to be two directions offered to people with my aspirations in agile. I could spend time learning to program better and furthermore, I could learn to like it. There's a lot of job ads out there for a test developer but finding one that can actually deliver the results isn't that easy. Or I could see myself as a quality coach.

@larelekman has a nice checklist at #TAhelsinki : pic.twitter.com/KXoN0qyr60
— James Coplien (@jcoplien) September 25, 2014

The checklist presented seems useful reminder of helpful and enabling attitudes for a tester working in close collaboration with the team.

In my team, I work hard not to be the gatekeeper even though I'm the only testing specialist. Developers take their own testing seriously. But still the amount and style of bugs sometimes leaves me wondering if they really even touched the product after the change.

When we've coached developers to really take full responsibility of the user experience and taught them the skills to deliver on that promise, we might not need testers separately. There's more than running the software though. There's the questioning mindset as well that doesn't just apply on the software but also on the business decisions, user needs and designs we have on satisfying those.

It's a bright spot in the automation centric agile world to see someone talk about the other route: being an enabler that leads with example.

**That bug on the picture: one extra dot in the code. I keep being amazed how small things appear big and the other way around.