The Awakening: Improved Discussions on Features

Something really interesting has happened, and I wish I knew what caused it. My team feels more courageous, more active in taking a stand about design of features and we do so much better!

This started happening around the time we started Mob Programming together, so I would attribute practical, hands-on work around fun and laughter has a lot to do with the increased courage. We also started discussing more about our values and what we'd consider our role to be, encouraging initiative, so the explicit asking for this might also be a contributing factor.

The ideas of what needs to be improved are now constant. The discussions around concerns of our designs are now shared. And it's rewarding to see how those discussions morph the features we're implementing.

There's been three very different yet similar experiences recently.

The first one is a lesson about power of mockups with business users, in understanding if we are building the right thing without building it. Things where the users have found it hard to contribute early on, we're now getting actual discussions around use cases. A user experience specialist has added some of the needed focus in that area, taking developers into the discussions too.

The second one is a lesson about power of conversations. We identified a need, and two opposing views to approach it. The first idea seemed implementation/risk-intensive, so we analyzed the second seemingly easy option to learn it was implementation/risk-intensive on a different, more under the hood way. Connecting the lessons learned from the two, a third option emerged. Something that was never on the table without my hands-on pairing session with a real customer, but something that seemed blatantly obvious after understanding how our customers use was different from our own use.

The third one is a lesson about initiation. We've found many places, most recently today, with relics of old ideas of how the software is supposed to be extended that never turned reality. Instead, they create complexities and places of errors. These come out actively, as people are working on the areas.

Where there might have been a feeling of unability to do anything about these before, now there's hope. And the hope gets stronger through the shared actions we're taking.

Experiencing the awakening from within is wonderful. I love seeing how developers take on the full potential they have in creating great products. And looking at this reminds me on how fragile this is, how the environment focused on separation of roles could again take us back to past. 

From unwilling/unable to willing/able

I've been having discussions about teaching and coaching as part of being coached and as part of mentoring that I think of as form of coaching.  With this post, I wanted to share the a model that helps me make some sense in to the world.

Situational leadership or something of that sort

Many years back, I read a post somewhere on the idea of which seems to map to a concept of situational leadership (picked up the word from googling what I remember - the dimension labels). When working with people at different places on the map, you do things differently.

For people who are unable and unwilling, the help they need is career coaching, disciplinary actions, detailed delegated tasks, well-run meetings, making decisions for them, focusing extra effort on testing as a feedback mechanism, encouraging good behavior (working code over lengthy designs, prototyping and unit testing, small stories and tasks, team shared responsibility) and playing with peer and manager pressure to get the person out of the place they're in.

When you're at the point of unable but willing, you're really in a fruitful place to learn. The help needed could be highlighting successes, identifying learning potential and steps, assisting with difficulties, and checking on status and feelings. Great things to do close to the work is helping people take tasks through delegation, giving guidance is new types of decisions, giving feedback, encouraging teaching others to learn from each other.

When you are at the point of able and unwilling, the help that is needed is attitude coaching, selling options as opportunities, and focusing on responsibilities as employee. This is a time to step back and let the person plan more, still enforcing small stories and tasks, with focus on personal accountability and deadlines.

We'd love to see people who are both willing and able, and whatever we do when they are not one or neither, is to help them get to a point where they are both. At this point, people still appreciate highlighting and rewarding successes (and being reminded that failing is learning, and when learning, that is a success!). Encouragement could be directed towards cross-training the others and continuing to learn, offering advice on decision making (but making sure the decisions are done by the people, not given from management). And even with people in this stage, there's often stuff outside the team that needs attention, be it to highlight the successes of these people as internal marketing, or removing roadblocks in cross-departmental work.

People who are unwilling are hard to work with. While unwilling and unable, these two might be connected: hard to be willing to do things you fail at doing. However, some of the trickiest problems I get to deal with are about lost motivation. When you've been put in a weird place for long enough, you start thinking the cave you're in is what the world looks like. You might not like it, but you know of nothing else.

I find that sending people outside is critical. Quoting a friend who chose to stay anonymous:

An average person at a conference is above an average worker at a company. Insight of the day.

— Maaret Pyhäjärvi (@maaretp) March 30, 2016

Go out to find a way to be willing and able. You need to see outside your cave.

Learning from a customer through strong-style pairing

We've been working on a set of features on our product we've labeled around a customer. They're features beneficial for others too, but they're existence is particularly important for one.

At some point of this, we already learned that taking down the distance between the programmer&tester and the customer was a great idea, helping us a lot in solving  the right problem. As often goes, the second hand information was distorted turning it into a feature instead of the need, and the best way to solve the need was altogether a different feature.

With the past learning of direct contact behind us, the product management had no issue with the idea that I would be trusted with getting the customer to use the product too. I was told to write a guideline, and in addition I scheduled a workshop with the customer.

Armed with the goal of knowledge transfer, I asked the customer to share his screen on Skype for me. I walked him through the login, guided him to the library his task was to fill out and made him do the work instructing with my words. I created him an experience of use, and in the end we retrospected for a while on what he learned and found complicated. While observing him as he did what I guided him to do, I learned of a missing feature he never realized to ask for as he even now did not see that was his need. And from our session, he could now do the things that were abstract. The guideline I wrote might be a helpful future reference, but much less necessary having the experience (not a demo) of use under his belt.

Later, I talked with the product manager who assumed I had "demoed the features" and seemed very pleased with the idea that the customer had been my hands on this demo saying he wouldn't have thought to do that. I labelled what I did: Strong-style pairing - for an idea from my head must go through the others hands. The label gave it a place in the ways to do things in the product manager's head, and he said he'd try that too. "Never thought of that", he said. I could feel smug about having thought of it, but the truth is I was told to think of it 1,5 years ago. I too NEVER thought of that before - that the roles in how you pair matter a lot. 

Mob Programming Conference - see you there?

There's one conference I'm going to as an attendee, not a speaker, and that is Mob Programming Conference, on May 1-2 in Boston. I wanted to invite you to join me there with this little post.

I'm from a family with six children, so being around others has been my natural state. Two of us ended up in the software industry. I became a tester and my brother became a programmer. I always thought it came from what we were good at - so very fixed mindset of me. Looking back, I remember limited access to computer at home. I remember the lan-parties for boys only. And I remember being quite happy and content not facing weirdness by trying to join anything I did not feel welcome to.

I chose to do something where I would be welcome. Where I would not stand out too much. And where I would not get special attention and help because I'm a girl, without giving up my interests. And software testing is perfect - both genders are equally loathed upon in most place.

I told myself I don't really like programming. I told myself I had (which is true!) enough to learn on other stuff. But for the other stuff (team collaboration improvement), I volunteered myself to work as a mob with my team - one computer for getting the code in and my taking my fair share.

I learned that learning this coding stuff is easier than most stuff I've dealt with under the label "testing". Stuff that programmers say are programming, I say is testing. The thinking and analyzing. The understanding the problem and solution. While my programmers may at first tell me "var" letter by letter, a moment later I know that and learn more as we go. And with my presence, we avoid many costly mistakes, have a better big picture and a voice of conscience reminding that we really did not test enough yet.

In a mob, the code isn't mine. It's ours but I can see my fingerprints all over it. I don't have to deal with the "since women don't code well, you'll need special attention on feedback that you learn this stuff". All this special attention makes me very uneasy, just like pushing myself to places I'm not welcome to. And it gives me the social aspect of work I'm craving.

I would love to see people with my type of background - and any background - at the Mob Programming Conference. With Kindness, Consideration and Respect as guidelines for the type of work in mobs, I feel safe and welcome. And welcome you to join the experience. An experience it is, with 2 workshop and reflection heavy days, only opened and closed by a talk.

How safe is your work place?

I've been thinking about safety today. Perhaps it's somehow related to talking about SAFe, the agile framework is less than admiring fashion last night, but the word has come to my mind often. Feeling safe. And in particular, lessons I've learned on what it takes to make people feel truly safe at work.

Some years back, I had a manager who believed that he needed to see me mark test cases passed / failed. He was honest enough to not try to wrap this into any methodology wrapping, but stated his true feeling: how do I know you're working if you don't do this?

We found other ways. For us, the simple thing that worked it to establish trust through the fact that our software at the time was so buggy that he knew I was working when I was logging on average 8 bugs a day over consecutive years. It took away the need of worrying, and established trust that was very important to me.

With my latest manager, the trust is extended even further. There's no cadence of me having to check in, and I've been intentionally testing the limits. With me feeling trusted and safe, I'm the natural me: excited about stuff, wanting to share, being active and figuring things out together so that he does not need me to check in, I just do. And I feel happy, I generate new ideas and act on them.

But the safety goes even further. It's a foundation of feeling nothing you do could destroy it all.

Imagine an employee who did not provide value. Or if he provided value, the value could be perceived negative. Interrupting others from creating value. Breaking things. Creating artifacts that would make further work harder. I used to believe these people should be fired. But I've also experienced now what I feel is extraordinary safety: supporting these people. Helping them over long periods of time. Thinking firing would almost be an option out of reach, even if it wasn't.

I'm realizing that action sends a message stronger than anything I've experienced before. It's safe. Safe to fail. Safe to be incomplete. Safe to try things out and learn.

That's a level of safety I'd now like to aspire for. Safety in the sense that it feels the current results-oriented world has little room for. 

The destructive forces against conferences

My social justice need raises its head once more to blog as a response of what is going on in the interwebs: the Agilia Conferences rude response to a query on diversity. But the recalling of sponsors and asking speakers to take a stand starts to feel like a witch hunt. And there still are no witches!

What happened?

Agile development (and Testing) in my experience are areas of software conferences with very healthy gender ratios in general. Take Agile 2015 in US for example: lots of women.

When  there is a conference with 27 speakers on Agile, and only 2 are women, it is hard to not wonder. And I love the world where we nowadays are (mostly) encouraged to point that out, because awareness is the first step to change things.

So Agilia Conference representative had a rude response. The response refers to caring about this as feminist game, makes the choice of a he-pronoun on welcoming speakers, and and mentions engineer diversity games and not being a political party. Judgmental language, sure. They further referred to extensive screening and later even shared blog post of what that means unintentionally implying that since women don't get through their screening, they are lying more often in their conference presentations.

A step back

Surely the responses have been insensitive and unaware. But what is this campaign I see of twitter going for killing the conference? They were very clearly defensive with their first reply, and their defensiveness under the attack isn't going to change things, just make them feel the great injustice.

So, they miss out on a lot of things:

• They most likely invited some of the speakers as paid keynotes. There they had full control of choosing. When they did not choose a woman, it more often is about not being aware of great women than an intentional choice of the 2-4 absolute best speakers in the keynoting circle. The chosen men are great. There could be other chosen people who would be equally great.
• It matters if you see people like you speaking for future years for availability. Conferences that struggle with diversity keep struggling with diversity, because none of the minority speakers wants to be on stage as the token. Software is built by people for people, and we're relatively even on the gender ratios as users. Across roles in organizations (esp. non-technical agile) the ratios are not that far off balance in creation of software over its use. 
• Their call for proposals is responded by people who  have something to sell. They might pay their own travel to be there - we'll, their companies do. Looking at the Agilia commitment to extensive screening it looks like this applies to people's promises to speak there. But they are very likely to miss out on groups of people to submit that they are willing to publicly insult. 
• Insulting anyone and not being nice is always  bad. The underlying idea of not really caring for the gender of the speakers gets distorted and just oozes unwelcome.

But really, is this crime so bad that there needs to be a campaign to hurt them?? If they don't see things our way, they should go away??

Regardless of the bad expressions, I'm reading into their responses:

• They might be genuingly puzzled on what aspect is making people upset. It's not the amount of women they ended up with, it's their response to raising that issue. 
• They might not have the help to solve this. They need women to help but it is not the womenkind's responsibility to stop all their doing and jump to help (even if they seem to be thinking that). 
• They're oblivious that conference organizing is not about passively waiting for your call to be found and responded to,  but you need to actively seek. Very much the same way the extensively screen what they get for being truthful, they need to pay attention to the truthfullness of the industry they are aware of.

If you have energy for the negative action, how about targeting that energy for a little more positive? 

Things I learned while being coached

Some months ago, I felt it might be a good idea to try coaching. The idea emerged from an actual problem I felt I could use support in solving that a coach within the Agile Finland activists group picked up without directly mentioning it. And it lead to me reaching out to him, asking if he would be available to work with me.

I was curious and filled with skepticism. So a coaching relationship started, ending today. And it was great. 

My skepticism was met with a nice dose of what I would call coaching humor - making a point when using "tools" on me.  The format we used became known soon. Work on my goals. Work on working on the goals. And asking a lot of questions, leaving a lot of space.

The sessions with the coach were not my main source of takeaways. The main takeaways came with the increased introspection that tended to follow the sessions when I was trying to figure out what I wanted to do with my goals when following even a self-made plan from the sessions often felt off. 

I learned things about myself:

• I've been heavier on introspection for a long time which might be atypical. I find it core of exploratory testing to not only look at what I did but also what I felt and what I learned and how I could fool myself. Realizing that made teaching this more explicit for me.
• Sticking to plans I expected of myself is an external expectation I mirror on myself. Creating a list of things important to me and letting my plan emerge through action both increased my efficiency but in particular, helped me find balance I was seeking.

In the coaching process, the main thing I feel in retrospect I needed help with was identifying and naming my goals. With the goals in mind, progress was possible. 

I'm still work in progress and thinking of my next steps. Friends might suffice for a while, but later I need to try more of this with a different type of coach. 

A lot of the introspection during this process lead me to create another talk. I call it We're Work in Progress: Lessons on Becoming a Great Tester and I think it is going to be awesome.