Friday, November 27, 2015

One experience of teaching kids creating with computers and programming

I've been slightly struggling with time management issues this autumn, having so many things to do and so little time. Today was an end of one experiment I wanted to do, and it turned out great even if different than what I had in mind when I got started.

I wanted to try out teaching 1st graders about creating with computers and programming in a format that is different from free-time voluntarily -based approached of code schools and clubs in Finland. I wanted to start building a way of being helpful as part of classroom training, instead of adding more hobbies on the side. There's still a big challenge ahead in getting all the teachers up to speed with what they could be teaching with regards to programming when it starts in all elementary schools for all grades in less than a year. 

I contacted my girl's teacher and asked if we could do something together. With a little discussion, we came to the conclusion that we could do a few classes with the focus of story telling with the kids. So we started making pictures and voice over to become a video of an alphabet story. 

It was wonderful to see what kinds of story ideas kids came up with from the letters. I was originally hoping to put these together into a CYOA-story (Choose Your Own Adventure), but the timeframe of 2*45 and a class size of 28 students minutes soon put me to a different idea. Just the collaboration would have required more time to make that happen.

The first session had two parts:
  1. Hello Ruby book handout. Every kid in both 1st grade classes got a free copy to take home, as well as the teacher. That was 48 copies. Linda Liukas and her publisher were very nice and enabled a cheaper unit price for the batch, and my non-profit work was able to finance the books as gifts. The kids were very curious about the books and with guidance from me and the teachers, named their own copies so that they would not get lost or mixed up. 
  2. Create a story with picture, and record it. I had each kid choose a letter of alphabet and draw a picture of a story they came up with. I asked them to come to the computer for recording, and showed them around on how to tell their story as a recording. I collected the hand-drawn pictures. 
In between the sessions, I did a bit of work on the outputs of the first session. I paired with my girl at home on some of the work, and taught her video editing basics to cut out all of me to leave just the kids. We scanned the hand-written pictures and included them side by side with the stories. My girl recorded a beginning and an end with a proper microphone and got excited about the idea of singing into the microphone. With the huge number of stories, the editing was quite much work, taking me 3-4 hours. I cut out the silences, and even transformed one word answers to something that resembles a story. 

With that preparation, our second session had three parts:
  1. Creating credits image to end the video. The teacher set up a touching game to add a little randomness to the order of kids coming over to the computer to add their own name into signatures. When touched, it was their turn - and this created a positive sense of waiting for one's turn. With the projector, there was a lot of fun with this simple act: writing on the computer, getting your own name into the work and others reading what is on the screen as it emerged. Every kid wrote their own name with small (non-capital) letters, and watching that happen for a few kids, I realized there was a great intro into the programming we'd do later. I showed how with a computer I can select all 28 names and turn them into words that start with capital letters just with one function. 
  2. Watching the video together. We then watched our end result. Everyone in their turn was looking like they were feeling a mixture of embarrassment and happiness, and the whole group was very focused on seeing their own stories. We talked briefly about the fact that the video is theirs and that I will not put it in the internet nor should they - that things like that should be agreed on in advance and everyone should agree. The class teacher pointed out clarify of speech and how much easier it was to understand what great messages you have to say if you articulate, and I was just thinking I missed a bit of editing when I did not raise the quiet voices to a higher volume. 
  3. Talking and trying out programming. With the video created, we started talking about programming. We talked about someone having programmed the tool we could use to create videos, and programming as something that would allow us to create things we could imagine. We did two exercises from Hello Ruby book.
    We talked about small programs that consist of commands learning Ruby's dance moves. Then we talked about us being the computers running the dancing program and tried it with three repetitions. We ended the exercise talking about doing the moves 1000 times and how computers don't get tired of repeating things you program them to do. And we talked about the idea that we could tell also to stop when we say to stop.
    The second exercise was the debugging exercise that comes closer to my usual work. We looked at two three examples where the little instructions that computers could understand but that missed something. Like the idea that you would put your table cloth on top of your birthday cake, or that you would eat when you're full and say thank you when you are hungry. 
With a lot of laughter, sense of having created something that wasn't there without you, I ended the session. Next up would be hour of code, in just a few weeks. I like those exercises, but I find them one-sided: to become smart creatives, we need to want to create, not just solve given puzzles. I call for freedom and support in implementing one's own ideas, the thing that I remember loving but missing out in school system including the computer science studies in the university.

Creating with computers is the point for me. Programming is just a tool. Sometimes what we want to create require programming. Sometimes advanced use of existing programs. But the thing we should not have is fear. Believing computers do what you want, demystifying them is a core of what I do professionally, whether I feel like being a tester, a programmer or a product analyst - today. Most days I love being a tester too much to ever want to be anything else. 

Another experience in Mob Testing

Today, I had a visiting lecture at Aalto University of Applied Sciences. My theme was Testing in the industry, as it has been for any years in a row when they've invited me to share lessons from the trenches with the new aspiring computer science students. I love going and prioritize it high, after all it's my university. It's where I used to study, it's where I used to do research on testing and it's one of the major places on my career that has given me the space to grow with my interests in testing. 

I agreed on being there for a visiting lecture at XP2015 conference. Since then, the teacher changed, but the agreement of me doing a visiting lecture stayed. On previous years I've shared ideas about how I do my work and what I've learned about testing in these 20 years, but this year with the new teacher we came to another idea. What if I would just briefly tell what I do and how much I love what I do, and let the students experience my joy first hand in a mob testing session! 

We had 1,5 hours (2 university lectures) and about 15 students. When they came into the room and sneaked to take their places in the back row, I invited everyone to take their chair and come to the front of the class in a semi-circle. I had no slides to show, so we started with the application to test open on the screen, Eclipse with the Java-code and a browser window with mindmup in the background. 

We talked about the roles of a practice mob testing session, and the roles I assigned were those of the driver - no thinking at the keyboard, designated navigator and other navigators, that would navigate through the designated navigator. 

I introduced the application briefly. I told it was called Dark Function Editor, and I navigated the first driver as an example to get the application to a point where we could start testing. There's a limitation I would call a bug that prevents the application from working unless you realize not only start a project, but also add an animation within that project that I did not want them to get stuck with. This time I also did not force them to log it, and as I had shown it as if it was expected, no one seemed to consider it a bug. 

We rotated on three minutes, so the group kept moving on quite a high pace and organized to do that very fluently. The first few rotations were focused on trying out some features that ended up being just randomly picked by whoever was then navigating. The first navigators were clearly unsure of what to do, and referred very nicely to the help of their mob, and the group was contributing together quite early in the process. The first rotation was challenging, none of the navigators would volunteer ideas of where to start from with a blank sheet and I reminded that in testing, it's good to remember that if you freeze because you feel overwhelmed, it's good idea to do something, anything. There's no wrong or right when all is a mystery to us. 

The group found bugs, and one of the bugs was something I had not personally noticed before, even if I have now used the same application in quite many sessions. They noticed that if you added right kind of pictures in right order, it became obvious that the preview and actual layout with the order of pictures were reversed. They just got lucky to put pictures in order different that what my list of preprepared material had guided other groups to. I introduced the concept of writing bugs to the mind map. Then they run into things they were unsure of if they were bugs, and I introduced the concept of questions. With concept of questions, I also introduced the concept of color-coding different items in your mind map. With a few rotations, we had a few questions and a few bugs, all around the center item on the mindmap. 

However, as the facilitator I sensed that they were testing without a purpose. So I inflicted a constraint, asking them to focus on creating an animation that they could export, just a basic flow. They were lured by things they'd like to try occasionally, especially the mob volunteering things more actively than could be done and sometimes the driver and designated navigator would look a little overwhelmed. I kept advising that the final call of what gets done is on the designated navigator. With a few detours and me asking what was our purpose now, we got an animation done and some additional questions noted down. 

With four things around the center node in the mind map, I introduced them by taking navigation to the idea that we can have deeper hierarchies. We decided with the mob to have Bugs and Questions as nodes, and dragged things we had built by that time underneath. I knew I'd much rather have feature areas here, and bugs and questions color-coded under the appropriate feature area, but the group was not there yet. They had not yet understood there were feature areas you could name and use for categorization. 

At this point, I gave them another charter as their constraint. I pointed to a particular feature, and asked them to list all functionalities they could find. The feature I pointed to has visibly four buttons, and I've facilitated groups where testers think that they are done having listed those. I was curious to see how this group would do. They did great. 

Because of the projector resolution issues, they couldn't first see there were four buttons, and they paid attention to only two. This lead them by accident to create a good list of things, and they came up fluently with various features related to handling the list. They were trying out single clicks, learned that double click is a rename feature, and that right click wouldn't do anything even if that would be something you'd usually expect in a functionality like this. They accepted the right click and dismissed the information. They tried drag-and-drop and started playing little with the automatic and manual naming of the list items. I sensed they were starting to feel they might be close to done. 

I took over the navigation pausing my timer for the ongoing navigator, and navigated to add more items on the list. After that was done, I asked if people noticed another feature being revealed now - a scroll bar. With this revealed, there was more they learned. They noticed that the up/down arrows would also only work when there was more items, and with those keys they also started paying attention to other keyboard shortcuts. 

At some point someone in the mob made a surprising remark asking if there was an undo functionality. The product use, adding and removing things and having to recreate your test data after someone else had decided that deletion was a good thing to test now probably inspired it. And the group found the Edit menu, with an undo-redo -functionalities that turned out to extend to the feature we were looking at on the other side of the application. I pointed out the excellence of that realization and sharing the idea with the group - it opened the mob new doors of what features there could be, as they could start thinking of connections outside user interface proximity. 

The time was running low, and I stopped the navigator to take over with a piece of advice, pointing out the two buttons they had not noticed. With starting to add those buttons, someone in the mob suggested that perhaps the mind map should be restructured again, as it was hard to make sense of it with this many features. They used the last two rotations on getting started with restructuring the mind map, introducing concepts they had learned through exploration like naming the buttons function and creating a subcategory of actions for the buttons leaving tooltips of the buttons as another dimension to the actions. 

The map created turned out to be this: 

If they would have continued, they would have soon discovered that bugs and questions belong under their modeled areas. They would have visually seen more of areas of functionality they had considered from the listed features, and it would have inspired them to find more. There are still many features I've thought of in previous sessions that did not get listed. But they also had one thing they could name, but I had missed. 

We ended the session with a little retrospective. I asked people to share their observations in a round-robin style and we had little discussions about the observations, addressing e.g. Mob programming effectiveness and if anyone would do this in the industry. Many people pointed out how this mechanism enabled to build on others knowledge and get further than alone. And a few people pointed out how much fun it was. 

As an after-lecture discussion, I had a chat with the lecturer who said he will connect this experience to many of the concepts he will be teaching in the upcoming classes. He also said that mob was a very good teaching format, and I felt I have improved a lot even over the last few months on facilitating testing mobs and knowing when to step in to show a concept that will help learn more without stretching the group too far at once. We talked about an idea to take mob testing to published research articles - an idea I would want to support happening. They've done research on individual testing 10 hours vs. 5 people testing for 2 hours each, and having 5 people test 2 hours together would bring a whole new perspective into that setting. 

If you want to try teaching in this format, I would love to help you get started. And if you know of a team who would like to try this mob testing format with their own software, I'd like to collaborate to fine-tune my training approaches on this and do an experiment. 

Wednesday, November 25, 2015

Getting started with mob programming for User Interface Styles

While we've had some opportunities to try mob programming with my team, there's now an actual theme over a longer term a subgroup of my team will work on. It turns out that the subgroup consists of people who have not tried this way of working before AND that we need to do all of this in a remote setting. I'm looking forward to learning about how it works for us.

We've selected a theme: styles and the UI. There's a few reasons for this becoming a selection:
  • There's a new user interface designer in our team that has not worked with major projects on styles before. So we know there's a significant skills ramp-up needed, and I don't know of a better way to do that than hands-on with a pair/group. 
  • The current user interface programmer has not been strong on discipline. When sensing urgency in schedule, it's just easy to take a shortcut. And those shortcuts pile up. The style code looks messy and it's my personal testing nightmare: fix one thing, and many surprising places break. Cleanliness of style code would help us so much, whereas testing of styles in the extent they've been creeping to is just failure demand. So, I will test while bringing my idea of discipline to the group. 
  • No programmer other than the user interface programmer currently touches the style code. It is too complicated to understand. We want to also transfer back some knowledge of how everyone in the team could work with it and clean it up as they go, and inviting them into the mob seems to be a good starting point for that encouragement.
  • I want to try mobbing over long term and get more experiences in being the non-programmer (turning into a programmer) in a mob. And the others don't resist (at least yet), since the learning / sharing / improving the maintainability just makes sense.
Our styles, while they were CSS, used to be as clean as the rest of the code. Then we hired a user interface programmer who brought in LESS, changed all styles alone so that no others were involved and alianated everyone else by accident. It's not hard to see that touching something as wide and complicated, people do follow the instinct to flee (and leave the work for the specialized individual), even if that negatively affects our flow. I'm just glad testing isn't in this position in my team, it could be. Lesson: work together and share the work not to get there.

We had a "show-and-tell" session for the style code newbies of the team last week. We looked at our logic of structuring styles and I had two thoughts in my head: 1) now would be a great time to get that test-driven CSS lesson Llewellyn Falco could do with Agile Finland 2) reading code is separate from writing code - I know when I see a mess, while creating that mess myself would take a more focused learning effort. I made notes of four things to pay attention to:
  • Use variables instead of the magic numbers. We really would want to keep things together better to follow what goes on.
  • Simplify the overwriting chain. Minimal design over everything we could do. Less is better. And chaining makes up a mess of unpredictability.
  • Scope with views. We have mechanisms to scope the styles, but we mostly keep things global. No wonder I see side effects of changes.
  • No Important! -keyword unless absolutely have to. Use of these in chains have escalated in use of these almost everywhere, to make sure the last in chain will end up being applied. Discipline. 
Today we had our first scheduled mobbing session. It did not go quite as we'd hope. We started with 2 hours timebox and two goals in mind. We would use the new user interface designer's computer and first goal was that we would set things up that were needed for her to do the work. Second goal was styling of a tiny feature with minimalistic styles that would still fit both designer's ideas of beautiful UI (and the team's idea of maintainability, only valuable stuff added).

We only got work done on the first goal. We got the basics tried quickly, sharing voice over Skype and control of the computer over, rotating on four minutes with the idea that our "expert" would skip his driving turn if we were in middle of something where we'd just be stuck without him navigating. With Visual Studio, we soon learned the computer in question had not been set up for the solution we needed to work on. With a few clicks, that was done. So we went to find the branch with the new feature to be styled and run into our first problem. The branch was not visible on the computer in question. We tried connections, no luck. We installed git bash and gui, thinking we could perhaps bring the branches in from the command line. First time installation gave us git bash that kept crashing every time we'd start it, and after rebooting (no effect) we reinstalled. But looking at things from command line did not take us much further. We pinged in more senior developers, still no clue. So we changed computer.

The starting setup on the second computer was faster, and we got to a point of Visual Studio and starting the application at about 40 minutes into our session. We started feeling the frustration of sharing the remote computer, as the feedback sluggishness of mouse movement made doing simple clicks harder than we're used to. We stopped the running application, synched the branch and went to run the application, only to see it crash at start. With theory of and security settings, we turned off the sharing, no effect. So we decided to reboot the second computer too.

While waiting for reboot (it takes quite a while on Windows...) I asked my local colleague whose computer we tried using first if we could try one more thing - something I had suggested quite early on into the problem, something that should not be connected that was dismissed when I suggested it by the expert. We pulled latest of our integration branch and all of a sudden, the information of existing branches was available too. So by the time of reboot and reconnect, we had a working local environment.

Just before our remote expert could rejoin, we tried running the application, with the crash. We tried changing solution configurations between Development and Debug, and got a little further: login screen. But same error at login. The group was getting very amused with the luck we were having, and concluded that at least it was much nicer to be in this together than alone.

We called in yet another senior, to confirm our theory: the new feature relied on database changes that were available only in the developer's personal database. At 1,5 hours, we decided to call this session done and leave the second goal for next session, by which time we'd get the database changes in a common environment too.

A few observations of this session:
  • The first goal turned out to be more complicated than we expected. No one, be it "code newbie", "style expert" or "senior developer / architect" had an immediate answer. Trying and googling were key. 
  • If we would have tried the unlikely idea when it was presented instead of dismissing it, we would have saved 20 minutes. As a "code newbie", sometimes getting heard can be difficult. 
  • Getting stuck and unstuck together seemed more efficient. Alone we would have just left it waiting for the "senior developer / architect" to hunt down an answer he did not have when we invited him - research needed. Together, we worked through the first problem and even managed to solve it. Surely, we could have done something else in the meanwhile. Like read the news.
  • Minimizing the remoteness so that the one that must be remote is but the rest rotate locally seems a good idea with the connection sluggishness.
  • We could improve from  here: the one test that fails the continuous delivery when the application doesn't start would be great for things like this. 
  • Nothing I would pinpoint to my great tester abilities today. Perhaps next time. Next time is next week Monday. So experiment continues and everyone is still with me. 


Tuesday, November 24, 2015

Discomfort of defects

Last week, I was testing yet another new feature. And testing of it was very straighforward. First I tested to learn what the feature could do with simple data. Then I extended the data, and extended the variation I could bring in with the new feature. I made a few checklists to cover through relevant scenarios. It was about a day of work, nothing major.

I found 10 issues. That too is a very typical number. But what was atypical was that this time, probably because of business priority of the feature, all the bugs got fixed within one day.

As I was going through the fixes based on code commits and Jira notes, I noticed an interesting phenomenon. Only 1 out of the 10 issues I had raised had a comment. And the only comment was to say that I had found something that was _relevant_  - a mistake in how the code had been written.

There were 10 changes, so I would argue there were 10 items. But the developer, working towards no faults in his code, dismissed the other 9 and focused on the 1 as his personal feedback.

This again reminded me on how differently we think. For me, all 10 were relevant for the end user, and I really did not care whose fault it is that those exist. The developer worked against the idea that just-in-case he would ever need to defend himself, 9 of them were "new information he did not have when implementing the feature" and that he "had only one code defect".

We haven't classified things for anything but unfinished work for over a year, and still the culture of looking for one's own responsibility remains. There was no complaint on the other bugs, but the feeling can be seen in the comments - what gets acknowledged as "my bug" and what is just work on the list.

Saturday, November 21, 2015

Encouraging self-organization

I was on a train, going back to work from a lunch, when my phone beeped. I look at the screen, to realize someone was pinging me in Flowdoc. That's how my team, working remotely, communicates. I curiously checked what was going on.

One of my developers was asking if I'm around, and I told him where I was. Having a discussion on mobile isn't really a problem, so I asked "How can I help you?".

He mentioned the feature he was working on, that I knew just as well as he does. But what he said next surprised me. He said he has been thinking about the purpose of the feature and why users want it, and come to a conclusion that as he understands the purpose, it will be severely damaged if the end user isn't able to select multiple targets for editing in combination of what he is implementing.

This should be a normal discussion to have, but it really isn't. I can't recall that particular developer ever before reaching out to me for a discussion without me initiating it and never saying much about caring for what the user can do. It's had always been me.

With the discussion of the purpose, he introduces a change he has already implemented to the multiselect feature. It's a change where, me having sat more with product owner, the word around in priorities is that it cannot be implemented, because it would slow down the functionalities around it. His questions are more about how to make that right, not about if making that in the first place is right. I know it was outside our priorities with a strict interpretation. But it is definitely in benefit of the users.

We had a longer chat about other purposes, limitations or risks of the things he was thinking of. The reason he was discussing it with me was that there was yet another connected and very complicated feature, which he had forgotten many times in the past with me pointing out how that had been broken as a side effect. And now he wanted to work it through with me.

With the little slowness that the communication channel created, I had time to reflect what was going on in my head with the discussion. I had two conflicting views:

  1. I want to recognize the progress of initiating contact and showing caring for user needs and encourage that behavior with positive feedback
  2. I want to scold him for implementing a new major feature without discussing priorities with others before implementing. 
I'm happy to notice that I don't follow my second instinct of scolding for breaking the rules. I focus on the positive. The time is used already. We want to go forward and create value. He is creating value. So I dig into the details:

  • I'm happy that he is implementing a feature that users have expressed need for, that we have prioritized out with reasons of performance
  • I'm concerned he did not pay attention to performance in coming up with his solution, and help him work that through. 
  • I want to be helpful in making the feature work since it is apparently coming in soon, even if I did not know of it. 
We add more aspects to the feature, making it even better. With talking to me about a specific problem he was having and felt need to discuss, he also tells me he found a solution. Without me ever saying much about my concerns, he remembers to close with the idea: I only spent a day on this feature. 

I'm happy he did. And I wish we would never make our developers feel they can't take the initiative. Rules are meant to be bent. And that's a hard one for me, as a Finn (we love rules) and as a tester (yep, gatekeeper lives deep in me still). 

Thursday, November 19, 2015

My approach to being a Speak Easy Mentor

My first Speak Easy mentoring process is now over. Ru Cindrea, my mentee and my friend, has delivered her first international talk at Better Software Conference in Florida. I could not be more happy for her. She did great. She is great.

If you don't know what Speak Easy is, go look it up. It helps speakers get started with speaking through mentoring. The punch line is diversity. For me it means women. It means people who wouldn't talk otherwise regardless of gender. It means new stories and new opportunities to learn through other people's experiences. It means growing new experts locally, and sharing them with the world so that there will also be strong European voices. Mentors are people from the community, who volunteer, each for their own reasons. It's all free and voluntary.

I'm now through one mentoring process, and half-way in another, and my approach to this is starting to shape. I'm very curious how other Speak Easy mentors do this, so I thought to share my way.

It's really a process

I seem to take my mentee through steps, that turn into six Skype sessions of varying length. From my very first assigned mentee (who got lost somewhere), I learned to agree on the next step while completing the first, and to rely on Skype meetings rather than emails.

Step 1: Introductions

In the first meeting, I tell about who I am, find out who my mentee is and talk about the process my way. I commit to being available and set Skype face-to-face as the mechanism. We talk about the minimal deliverables - like you don't need your slides early on, but they DO help clearing out your abstract a lot if you work on them early.

We talk about what type of talks my mentee would find relevant. I share my bias towards personal experiences over great ideas / theory, to probe for compatibility.

We talk about conferences that are out there, and their special characteristics. I'm usually aware of submission schedules, so I can share those. We look at testing conferences, and software development conferences if those seem fit for my mentee's interests. I point my mentee to speak easy site, but also emphasize that it has just conferences that reserve a special slot for Speak Easy applicants. You can also apply directly, with others.

While I have an idea of steps forward, I introduce only the next step. I leave my mentee thinking (mind mapping) about what experiences would be worth sharing, and what lessons those would deliver.

With Ru, this step was a funny ad hoc mixture. We were in the same online space at the right time, when it was time to submit for the Speak Easy quota. We realized that while Ru has spoken locally, she hasn't internationally. So we fast-forwarded to a specific conference by chance.

Step 2: Finding your talk and places to submit

In the second meeting, we go through my mentee's ideas of what to talk about from experiences. I share my insights on what in those ideas excite me, which I like best and think would fill real needs conferences have - all from my perspective. I emphasize that if something I'm not excited about would be something my mentee is excited about, that is still the one we should go forward with. Speaker first. The conferences will make their calls on choices and my view might be very different than theirs. And there's the right place for every talk idea in the world. Some belong in international testing and software conferences. Others belong in local meetups. And they might grow up to belong to bigger arenas too.

Learning to speak locally is a great thing to do. I emphasize local speaking as an opportunity to practice. Fail (and learn) in small scale, safe environment. And you won't fail anyway, just stumble a bit occasionally.

With Ru, finding her talk was a step that happened before I became her mentor. We were traveling and talking about inspiring lessons in projects, and I was trying to understand her experience about signal detection theory. We shared amazing stories about the worst bug she has had to deal with, the intimidating "reproduce or get fired" -scenarios that sound like a bad movie and how many troubles with dealing with bug reports just made sense after taking BBST Bug Advocacy course. I knew she needed to deliver this somewhere. So the idea was there when the deadline to submit was approaching.

With my second mentee, I was very proud of her sharing five selected topics and her experiences in those. We prioritized them together. As the next step, homework was to work on the title and description.

Step 3: Creating the abstract

In third meeting, we work on the abstract. I have the idea that it could be that I review the abstract and give feedback. But more often it is about finding the essence and motivation of the talk so that we can together get that on paper.

To find the essence, it's either about mindmapping or about discussing around slide outline, without yet focus on the slide specifics.

I'm learning to pair better with the abstracts. My second mentee made me particularly happy asking to create the abstract together in the session, instead of resolving to the write-review cycle. Perhaps she is a particularly good agile tester, and that shows in her collaboration skills.

There's still a bad habit I have on me joining the writing, writing options and contributing my ideas that way. There's still too much magic in the thinking that happens when my fingers touch the keyboard. The magic vanishes sometimes when I pair. Pairing is a skill.

The ideal case is that the third session happens before the submission process. But it could also be that the third session is, like with my second mentee, after being accepted to deliver the talk in an international conference, with the expectation that the abstract needs to be improved.

Step 4: Creating the slides

In fourth meeting, we usually work on the slides. There's a lot of homework for the mentee before this. Most often the skeleton of the slides starts to form clearly by this time. But how the message is structured might be very ripe. Typically we talk about making the talk more lively with stories. We talk about splitting the messages so that they can be digested better by the listeners. We talk about storyline, contents of each slide and the number of slides in relation to the idea of style of delivery.

With Ru, she just pinged me when she had draft slides available and I read them, knowing her story already and filling the blanks. I left comments, and we talked a bit over Skype. And later she pinged me again having changed them completely without my comments, and again we discussed feedback.

Step 5: Deliver the talk to me

In fifth meeting, I volunteer to listen to the talk. While I have been speak easy mentor for only a while, I've offered similar services to people before. Talk, deliver, I listen and give feedback. Real audiences tend to be polite and avoid negative feedback, I will speak about that too and work through ways of improving.

We talk about feeling, perceptions and take-aways. It's safe. It's just me. And we both now it's not ready, it's not what you're measured against. It's just practice, it's for improving.

With Ru, she delivered the talk to me and her colleagues at Altom simultaneously. We had great reflective feedback of what we liked and what could still be improved. None of it was absolute. Feeling, observations, ideas. Use what you find useful. Discuss, reflect and find your way.

With other people, I've had sometimes several deliveries. Seeing the talk grow through feedback has been very rewarding. It was always there. It just needed to be revealed. And I could help with that.

I advice people to practice with others too. I push my mentees to local user groups. I had one set up in Helsinki for Ru, but scheduled turned out to not match, so other people (including myself) used the session for practice of international talks. With these sessions, there's usually more time for discussion, and you can actively invite people to give you feedback. Or you can just look at how engaged you feel they are during your session. Or both.

And then there's the ultimate practice: delivering the talk. I wish I could be there. But I might just be around twitter, following what people say and bring out as their lessons. I admire Huib Schoots for showing up to see his mentees perform. He had a few of them at TinyTestBash. That's presence and support.

Step 6: Post-conference mentoring feedback

When it's all done, I want to still close with a bit of reflection. How did we do and what did we learn? Mentoring is always a learning experience for me too.

With Ru, I learned that some conferences focus on word count and style - and that there are guidelines that no one mentions when submitting, but when you miss them, the feedback can be harsh and hits both of us.

With my second mentee, I've already learned that being available with deadlines of submission and me volunteering does not always work out. And when the "improve" email comes, it hits both of us. I hope it softens the blow for my mentee. And I've learned we should really focus on doing, not talking - pairing is great.

Other reflections

Now that I wrote out my process, I also notice there is another difference. I find my mentees from twitter and I register with them for Speak Easy. Others seem to find their mentees through Speak Easy, they have a matchmaking service. I enjoy working with people I've met and believe will deliver great sessions as we'd had a chance to chat before. So I tend to not let Speak Easy know of my availability, it's always subject to inspiration. If you would want me to mentor you, a good advice is to ask me directly. I will if my bandwidth allows.

In this picture, I prefer the outer route. With end points, I've now had one of both. One using the Speak Easy Quota, one using regular conference submissions. 

Speak Easy is great. Thank you Fiona Charles and Anne-Marie Charrett for setting it up! 

Obsessing on facts

I've learned to feel strongly about facts. Sometimes, even obsessing about facts. What is true and what is not? When the relative rule applies - true to someone - and when that difference matters?

Facts are important enough for me that I've driven friends crazy discussing for nights in a row if the stories we tell in conference talks need to be factual as much as the storyteller can, or if the storyteller can change details as long as they stay true to the story. That is still a mystery to me. I'm getting closer to the acceptance that our memories will tarnish the facts anyway. So it ends up as set of questions of ethics, that are not so straightforward. The relative rule applies again.

Facts and perspectives into facts is something I work with as a tester. I'm a big fan of Laurent Bossavit for the leprechaun hunt he does on software engineering, dispelling common myths. I would love to learn not to distribute myths or create ones.

Some days ago I saw a retweet in my tweet stream:

This is so fucking important. It should be retweeted and shared 10000 times
I needed to click the picture open and read the text. I had plenty of opportunity to stop and think before retweeting. And I did. I realized it could be an urban legend. But I decided to retweet anyway, because in between the lines the message I wanted to retweet was not the facts written down, but the underlying story - unfair boxing of people with labels.

Soon after, I got a response from a fellow tester I appreciated: 
I came back to think about this, because people still days after the fact keep retweeting my retweet, and twitter is kind enough to tell me about it. Where is my responsibility with the added information I have now over the time of sharing it?

This is how leprechauns are born. So I'm thinking: which leprechauns matter? How did I end up obsessing over facts with software project stories on stage when I cared so little with facts here?

Perhaps obsessing over facts is a learned trait, and I just need to work on my heuristics on when that might be appropriate. 

Wednesday, November 18, 2015

Technically Speaking and Public Speaking Goals 2016

Technically Speaking -newsletter included a challenge: share your public speaking goals for 2016.  Looking at the examples like this, I decided to do mine following the format.

Technically speaking is one year old. I think that is about the same age as Speak Easy, my favorite diversity program. I love both initiatives. Technically speaking seems to grow newsletter first (useful stuff!), and Speak Easy seems to grow coaching first (amazing new speakers created within such a short timeframe!).

My Public Speaking Goals for 2016

  • Give a high-profile keynote
  • Publish 2 talks as videos online that wouldn't happen in conferences 
  • Less talks at conferences, just 3 (scheduled 2 already)
  • Some workshops at conferences, as paid work (at least 1)
  • Coaching 2 new speakers - finish one in progress and start one new

I want to transform my focus to being a paid speaker - a professional speaker that does invited keynotes and paid workshops. I realize I will not be able to resist temptation to be somewhere just for the fun of it though.

Some of my 2015 Public Speaking Highlights

This was my "year of international conferences". Adding all that I did this year to Lanyrd, I learned this:

And that is not all. That is conferences. Although, that includes some events from the past, so only 13 events and 7 countries in 2015. 

Some numbers collected inspired by the example: 
  • 33 delivered sessions 
  • 2 keynotes and 2 opening presentations on a single-track conference! 
  • 13 different conferences in 7 different countries, 2 continents
  • Breakdown for conferences: 7 CfP / 6 invited; 2 conferences were #PayToSpeak (did not cover travel+stay and was not local)
  • 6 talks in meetups
  • 1 peer conference with talk, and 3 open space conferences with a session (not counted on list)
  • 1 webinar
  • 6 training courses (public & private) 
  • Coached 1 new speaker through SpeakEasy to deliver her first talk and she did great! 
I also organized quite many sessions and let others speak. My organizing theme of the year was #TechExcellence - Agile Technical Practices, in addition to the usual #Testing -community organizing I do. 

And in case anyone was wondering, I did all of this on the side of my job. My employer let's me be out of office for trainings 10 days a year. So my typical conference experience is double shift to get the work done and weekends to compensate lost hours. Not a recommended practice. 

My lesson learned: doing this long enough creates some level of fluency. It's time to take it to the next level and learn to "Talk like TED". 

Sunday, November 8, 2015

Teaching in a mob format

Our #TestBashNY workshop was Collaborative Exploratory and Unit Testing and we had a great time with our mob of 20+ participants. I feel that every time I teach in this format, I learn more and wanted to share a few of the insights that run through my mind.

I *see* you

For years, I've been running similar courses with individual and paired exercises. Comparing experience with those to the experience of running similar contents as mobs (one computer, one driver, group navigation through a designated navigator in strong-style), my chances of helping the participants advance in their skills are amplified.

In pairs, you learn from your pair. I, as the instructor, can't see you. I can see your results if I ask for a debrief. But I can't see you test. In a mob, I see the clarity of your thinking and your insightful approaches. I see the understanding of your purpose. I see if you have the structure and the focus. And I can jump in to give you experiences you wouldn't get without this. 

Seeing more people test is giving me new motivation to find even better ways of teaching what I've learned through practice. It has brought me to ideas of teaching different level groups differently, leveling knowledge over time. 


When there's a new concept to introduce, I can take over the navigation. I'm still playing with the ideas of when this is appropriate. 

On the workshop day, Llewellyn took over navigation for finding the right place in code our insights from exploration were guiding us to add unit tests on, and creating appropriate seam to get into it. The participants took turns in driving, and supported his navigation as from the mob. This was a natural selection, when so many of participants did not identify as programmers. 

In our previous version of the workshop, I took navigation while exploring by joining the mob while given constraints on what I was allowed to do: clean up the mind map and document things others had seen but missed, or what was still there hidden to be revealed to a tester eye. Showing the example to a group of non-testers changed how the others in the mob did the work. Examples of good work are powerful, and going through someone else's hands, the pace of going through them is more appropriate than in a demo. 

Handling surprises 

Since on this workshop we're turning insights of exploration into unit tests, there's a relevant element of randomness to what insights the group ends up producing in exploration. We ended up looking at automatic naming of elements in a list this time, and it was code we had not had to work on before. Thus we got to search the codebase for the right concepts, try out debugging to see if we indeed were where we wanted to be, go through series of refactoring to find the functional logic from the mess around it to get it under tests. I find the experience quite powerful, and the lesson relevant: after the half-an-hour of digging the functionality out, adding more tests was easy. The first takes most work, and enables them building variation on top of it. 

Teaching more

This style of teaching made me want to teach more. It made me think how well this would adjust to company-specific trainings where we could explore your own application, finding problems, getting them under unit tests and fixed. If you might want to experiment on these with me and Llewellyn, please get in touch.  

Sunday, November 1, 2015

Mob Programming the Halloween Game Hackathon Experience

I spent my weekend in all-women Halloween Game Hackathon. For 2,5 days, close to 30 women got together for a coding event to form group with friends and strangers to build Halloween-themed games. The results are available on the event site.

This post is about my experience into all this. It's an experience colored by the fact that for 2,5 days, I was a developer.

When I created my name tag, this is what I said to talk to me about:

I actively avoided mentioning how little I enjoy programming in my every day work. I avoided talking lovingly about testing. I just did not actively volunteer info about what I do at work. I did not want to volunteer my labels. I wanted to be a developer amongst other developers. And that I did.

The organizers had placed us in teams based on our applications. Each team had a mix of experiences in programming. I did not know any of the three ladies I was assigned to work with, and was looking forward to it. Like I had written to my little name tag pumpkin, I was eager to work in mob format to really create together. It wasn't that easy though. The one of us that represented herself as the most experienced developer was strong on her opinions about what the game would be about (violence) and that she wouldn't want to work in a mob format. After deciding the basic directions on Friday evening, I was already preparing to just pay 30 euros (no-show fee) and leave - I would not be spending my weekend bossed around or left on the sidelines when there was such opportunities to learn from each other. Money was not the relevant investment - this cost me two nights away from my kids -time, as the days were long and they couldn't come home for the nights at all.

The never-before-programmer in my team encouraged me to not give up yet, but just go with it on Saturday morning. On mobbing I got back to the piece of advice I was given before: mob with the part of your team that wants to do that, and with that advice the three of us that were on site early on on Saturday went with mob programming, regardless of initial hesitation. I talked about how much more important it was to me that our never-before-programmer would feel she is an equal contributor in writing the code, than getting as much of it done as we could if learning for all of us wasn't the main goal. And the two ladies went with my request on "let's try it then" promise.

With 4 minute rotations on who was on the keyboard, we quickly picked the rhythm of just continuing where the previous driver left off. We used a javascript game engine that none of us had used before, and the mob format was particularly powerful in agreeing what we wanted to do and learning how that could be done. We solved our problems together, and the three of us owned every line of the code together.

There were moments that I was particularly delighted about as I find them insightful experiences:

  • We needed to find a way to do our game timer. We were working on an idea of needing quite many lines, when our never-before-programmer said as a joke: "Why can't there just be getTimer that gives us that". The others picked up on this: "Let's create a function for that" - and the unclear many lines transformed into very purposeful transformation of our intent into doing just what we needed.
  • We run into a particularly tricky problem with the game engine, and I was ready to give up and move to another feature. The persistence of the experienced developer in the mob kept us all on task, bringing in ideas on how to approach this. And bringing in yet another developer, we got the ideas to get away from our blocking problem with an actual solution - not the code we were missing, but the idea of how to work with limitations of the engine. 
  • The fourth group member came in later, and suggested to break down the mob and get everyone developing on their own. By this time, the trio said no, because we had experienced  how much more powerful we were together. 
  • By Sunday morning, our never-before-programmer was very skillfully navigating for implementing new (similar) features while I was driving and our third developer was taking a break.  
  • Throughout the weekend, our software was release-ready feature by feature, and we did really well on finding the next step that made sense to implement. We were about to go into planning the features, but managed with just outlining things in a mind map, to find more pressing features while getting some of the game done. 
  • The fourth group member (most senior developer) ended up contributing just graphics and a bug fix. Understanding what the game engine code logic was without the shared experience the mob had was difficult in the limited time. The individual contributor also used a lot of our time in waiting for her resolving merge conflicts and asking us not to check in while she needed to get the stuff in git. We would have gotten more done just as a mob. And her expertise could have been useful in solving the biggest and trickiest problems we needed to solve if she volunteered to join us over doing own things by herself. 
  • We failed with communicating between the mob and the individual contributor. The graphics brought in were not in synch with the idea we had had about what the game was, and the rest of us were left out on deciding what they would be about. But we adapted - to create less value than we could have, if the communication would have worked.
  • I made it through the weekend without ever mentioning how little I code, and was really contributing equally for the solutions. For the first time, I was an active navigator and not just filling in an insight here and there. That is because every line of code was created together. 
It was a fun experience, that taught me a lot again. It gave me yet another perspective into how great mob programming is and how well it actually dwells into the problems of team formation without specifically targeting those. 

The biggest takeaway for me was very personal: I learned I know a lot more on programming than I give myself credit for.