Thursday, September 20, 2018

Pairing and Mobbing are not the only ways to collaborate

A friend I enjoy connecting with on testing themes sent me a message today. They expressed they had enjoyed my pair testing article on medium, and had an idea they wanted to contribute on type of testing I had not addressed.

This was a form of collaboration where two people (a pair, you may say) worked on two computers, side-by-side on the same task. The two might be intertwined in the activity so that one looks one end, the other another end. And it is very much collaborative. They suggested this would be a model of pairing with two drivers, both with their hands on the keyboard - a separate one though.

In my article, I introduced the traditional style pair testing, where often the navigator would be making notes, deciphering what was going on with the driver who had control. Nothing says the second person couldn't be taking those notes on a computer, but what typically happens is that the notes, in comparison to strong-style pair testing, are of a private nature and don't always reflect what was going on in a manner that is shared between the pair.

Similarly, here with two computers and testing side by side, we can figure out many ways to still work in a very collaborative manner.

I find myself often testing in ways where there is two or more testers in the same space, at the same time, sharing a task while we still are not mobbing or pairing. It's more about sharing energy, and enthusiasm, giving hints of things others can pick up and run with, and continuously coming back together to understand where we are.

I tested that way today with a developer, over a teams chat. We would be calling out our progress and observations, pondering on things that did not work out quite as we thought. The chat version works when people are active in sharing. I absolutely adore this dev for the way he is transforming the team now from his position of seniority, and driving collaboration without pairing forward.

In the past, some of my most fun days have been when we work side by side with other people, testers and developers, growing ideas and solving problems. While formal pairing and mobbing are great and give a structure, the other ways of working together also beat the "alone in a corner" any day. Some tests require many computers, like the test at Finnish Parliament where they had to bring in 200 people serving with the Finnish military forces to control 200 devices, for one test to be completed.

No matter what, we should be learning and contributing. Work is so much fun, and it makes no sense to dumb or numb it down. 

Wednesday, September 19, 2018

Forgetting what Normal Looks Like

Today I reached 2 years at my current job that I still very much love. There's been mild changes to what I do by changing my title from "Lead Quality Engineer" to "Senior Manager", that shows up mostly in whole team volunteering more easily to do testing tasks and enable testability without me asking any differently than before. There are a few reasons why I love my job that I can easily point to:
  • We have team ownership of building a better product. No product owner thinks for us, but some business people, sales people and customers think with us. From an idea to implementation and release, we've seen timeframes in days which is very unusual. 
  • It's never too early or too late to test. Choosing a theme to give feedback on, we can work on that theme. With the power in us as a team, the tester in me can make a difference.
  • We can do "crazy" stuff. Like kick out a product owner. Like not use Jira when everyone else worships it. Like pair and mob. Like take time for learning. Like have a manager who closes eyes to push the stupid approve button that is supposed to mean something other than "I acknowledge you as a responsible smart individual who can think for themselves". Like get the business managers to not book a meeting but walk in the room to say hi and do magic with us. Like pull work, instead of being pushed anything. 
  • We are not alone, not stuck and generally people are just lovely even if there is always room for making us flow better together.
Living a life on the edge of "crazy" to some is fascinating when people don't all have the same past experiences. In particular, in last months we have had new people join who have brought in their past experiences from very different kinds of ways of working: with daily meetings, detailed Jira tickets, thinking for the developer, etc. 

I've been experimenting with finding a better, more fun way so long that I start forgetting what normal looks like. Today I found some appreciation for it. 

At almost two years in the job, I finally started a "Jira cleanup" about two weeks ago. I edited our team query to define what belonged to us: anything marked for the team, and anything marked for any of us that belonged in the team. All of a sudden for those few who had cared for the list based on their past experiences, realized that the list was much more significant that they had realized. About 120 items. We called for an old rule: all other work will wait until we are below 50. We didn't get to it though. Some people cleaned some of things up. Others were busy working on other things. 

Instead of one on one clearing of the personal lists, we called a workshop to share the pain of cleaning the lists. I had no idea what I might be learning with the workshop. 

I learned that half of the people had not used Jira beyond the "look at this individual ticket" use case. Seeing what was on the whole team list - a new experience. Seeing that you can drag-and-drop stuff like post-its - a new experience.  Marking a case into a state or assigning it to a person - a new experience. 

Even with the Jira avoidance I advocate for (fix and forget immediately, track themes on a physical whiteboard) I had not come to understand that I might have missed sharing a basic set of skills for a group of people coming to us from elsewhere, with other expectations of what it would mean.

A healthy lesson of remembering that what is obvious to me may not be such to others. And that building complex things on lessons that are not shared might make less sense to those with less experimentation experiences under their belt. 

Saturday, September 15, 2018

Attribution for Work Performed in a Mob

In 2017, I delivered a keynote at StarWest, talking about Making Teams Awesome. One of the main themes I talked about back then was a theme I had put a lot of effort into thinking: attribution. There's many things I have problems with around this:

  • Women's contributions get disproportionately dismissed - not just ideas, but also the work they do - and attributed in memories to other people. 
  • Group work is different from individual work, and my needs of attribution can get in the way. 
  • Ideas are not worth more than execution, especially in software development
  • Attribution should not be a blocker for communication of ideas, a new form of apology language required disproportionately from women. 

In June, I used a phrase "invitation to explore" in a conference talk as one of *my points*. In speaking, I mentioned a colleague I respect as someone who uses that phrase. Meanwhile, he took offense on me using those words without writing his name down. My conclusion: fuck the language police, I will never again even mention him with this phrase. The words are free and I live that idea on a daily basis.

Caring for Credit

We all care for credit, I would claim. All of us. And some of us, like myself, care deeply for the credit of others too. Yet, credit is a messy and complicated theme.

We all know the name Albert Einstein. The fellow who pretty much created the foundation for modern physics. The guy whose picture posted on a slide everyone recognizes, even though the pictures are from very early days of photography. The man has been dead for a while, and yet we know him. Probably for generations to come.

But we don't know who is Mileva Marić Einstein. We can deduce a lot from the last name, and recognize that there is a relationship there. She was a physicist who, due to her gender, had trouble getting the education in physics but went through it anyway, and contributed significantly to Albert Einstein's groundbreaking science. History forgot her, partially for the rules of society that required removing her name from scientific articles she worked on intended for publication.

Then again, we know Marie Curie. Another brilliant scientist of that time. Someone who had a partner who refused to let her credit stay out of the limelight. So credit is something to pay attention to. It defines history. It matters.

It matters to people so much that for a long time, we had to wonder why there are no baby dinosaurs? They were misidentified as other species for reasons of credit. 5/12 dinosaur species identified were not new discoveries, but juvenile versions of ones found earlier.

Credit in a mob

With personal history of protecting my credit heavily as a necessary self-preservation mechanism, this was a difficult one for me when I started working with mobs. I would see my contribution, and see it be forgotten in a retro less than an hour later! With the feeling of safety, I could bring out my own contributions in the retros, have them discussed and get back to recognized. I could write about them in my blog while everyone else dismissed them. But in many relevant ways, I had to learn that
The Best Ideas Win When You Care about the Work over the Credit. 
I needed to let go. But so did everyone else.

When a group of people works together, it becomes difficult to identify what was the contribution of each of the members. Like with baking a cake, you cannot identify if it is the flour, the sugar, the eggs or the vanilla sugar that makes the recipe just right and perfect. People inspire one another, build on one another and create together things they would not create alone.

Also, mobs had visitors. It was a living organism where people would come and go. It wasn't as simple as that. There would be credit for being there when it all started. There would be credit of visiting, short- or long-term. How do we credit things that are done collaboratively?

Visiting isn't infecting other people's contributions as "they are now all someone else's". We need to care and be fair.

The Mob Programming Guidebook

In 2016, I acquired a book name from LeanPub: Mob Programming Guidebook. I set up a GitHub project to write it. The first rough version of it was scheduled to be available for a conference session I was invited to do.

For all of this, I paired with Llewellyn Falco. We wrote in strong-style. We argued over words, and ideas. Our collaboration worked while it worked, and then the book was in hibernation for a while, because we couldn't work together. We couldn't work together to a point where it became evident we would never again work together.

With a book 30% written we needed to go our separate ways. In the split, both of us get to keep the results of the collaboration but neither of us can block the other from taking it forward. Claiming equal authorship for work we are not doing equally makes no sense. So I added 25 % more text to match my vision to a still unfinished book, initiated all the work I had been postponing on making it a full book it was intended to be and moved Llewellyn away from second author to a contributor to reflect his role to the book. The book is still not done. There's significant work ahead of me, including refactoring a lot of the paired text to vision I aspire for.

Books can have many authors even if one wrote most of the text. But that would mean that I would believe that the book wouldn't exist without their support and contributions, and looking into how I feel I honestly cannot say that. The book wouldn't exist without meeting Woody Zuill. The book wouldn't exist without me. But the book would exist without Llewellyn Falco, and does exist without him.

His role to the Mob Programming Guidebook is only a little more than his role to all Mob Programming books. Mob Programming grew out of his ideas around strong-style pairing. He has the choice of writing the full book that describes his ideas but I suspect he will not.

I want to acknowledge that for the 30% book, we inspired one another to create what is there. The foundation is co-created. But the book I work on forward, alone, is not the foundation. It is more. It's founded on all the experiences of leading and participating mob programming sessions, and my discussions with people who care for that activity just as much as I do.

The book is more than the text - because he has the text too should he choose to fork it as suggested. It's the site. It's the promotion.  And it is the text that is still to be written by its authors. The text that I am writing on top of the text I had been writing. I acknowledge the collaboration, but refuse to minimize my role to the past text, leaving a project I started in an unfinished state.

So when Llewellyn calls for help with a tweet
he is missing a big chunk of the picture. He is missing the fact that he is asking to be an equal author of a book that isn't yet written because he was once part of collaboration of writing some parts of early versions. He is asking his visit would infect the rest of the contributions. And that is not how attribution in a mob should work.

When someone sympathetic to Llewellyn then responds:
I disagree. I did not make this discussion more difficult. I made it clearer. Visitors don't get to claim rights to future work. Attribution of realistic contribution is necessary. Forking the text we wrote together is acceptable. Asking others in the mob to start over a fresh because you visited isn't fair.

My sense of justice says I do the right thing.

The book has 1008 readers, out of which 281 have paid for it and 1 has claimed their money back (book was not finished). We have received $1,240.24 in royalties. Since Aug 18th, I have received all royalties because that was when the book forked. The money does not come from writing the book but from promoting the book. From this "huge" financial gain, 80 % has gone to Llewellyn before to first pay back an investment we chose to make on printing early versions of the book.

I have explored my options. I chose not to remove him completely. I mention him, as it is fair. But he is not a second author of the book. I sympathize to his need to be, but he isn't.

Attribution for work performed in a mob is hard, because we want to be remembered and appreciated. I appreciate Llewellyn's contributions while sticking to the fact that my contributions are far greater and handing also my future contributions to him just because he wants to be an author is not a fair thing to ask.

Authorship is not born when you start a project. Ideas without implementation are not where attribution should be born. Authorship is born when you work on a project and finish it. If you want to say that you created X, be more than a visitor in that mob. Make space to stick around to completion. And even when you don't, they'll appreciate your visit. Because the end result is better through that visiting collaboration.

Looking forward to other visitors in finishing the book.

Wednesday, September 12, 2018

Devs Leading the Testing I Do

Dear lovely developer colleague,

I can see what you are trying to do. You try to care about testing. And I appreciate it. I really do. But when you try to care about something you don't really yet understand well, it creates these weird discussions we had today.

First I see you creating a pull request casually mentioning how you fixed randomly failing unit tests. That is lovely. But the second half of the sentence made no sense to me. While you were fixing  the randomly failing unit tests, you came to the conclusion that rewriting (not refactoring, but rewriting) a piece of logic that interfaces with the system in a way unit tests would never cover was a good idea. I appreciate how you think ahead, and care for technical quality. But did you at least  test the feature in the system context or just rely on your design working after the rewrite, based on the unit tests?

Then I initiate a constructive discussion on how our system test automation does not cover that functionality you rewrote. I'm delighted with another developer colleague pitching in, volunteering to add that to test automation right away. For a few hours, I'm walking on happy clouds for the initiative. And then I talk to you again: you tell me that while the colleague already started, you felt the need of writing them a Jira ticket of it. And because there was a Jira ticket, I no longer should pay attention to the fact that your changes are in the release candidate we are thinking of giving to customers any moment now, as soon as testing of them is done. I appreciate that you think tracking it will help make it happen. But have you paid attention on how often tracking with Jira means excuse of not doing it for now in our team? And how you assigning work to others means that fewer and fewer of us volunteer to do the things because you keep filling our task lists identifying all sorts of things everyone else could be doing and assigning them around?

The day continues, and I find two features I want to personally spend some time testing. The first one I pick up is created by yet another lovely developer. They didn't tell me it was done either, but my superpowers in spying folks pull requests reveal the right timing for the test. This is created by someone new, so I do more communication than I would do normally. And I do it visibly. Only to have you, dear lovely developer colleague again telling me how I should test it. Or rather, not test it. How there is someone else somewhere that will test it. Obviously I follow up to check that someone else has promised to do, and they haven't. Or they have promised to do something different. Like 1/10 of what needs doing. So I walk over your great plans of leading the testing I do, only to find out that the feature I tested don't work at all. So we talk about it, and you seem to agree with me that this could have been level of testing that takes places in our team. It would, in fact, be testing  that takes place not only in our team, but by the developer introducing the feature. Missing it once is fine. But not making it a habit through feedback is better. I introduce some ideas of exploratory testing on how I will make it fail, once I will first get it to pass once. You show me thumbs up, as if I needed you to approve the testing I do. I love how you care. But I wonder do you realize I care too?

So I move on to the second feature I found, and confirmed that it will not be fully tested elsewhere. And you keep coming back to correct me on what I should be doing.

Could you please stop assigning me Jira tickets that isolate testing from the pull request or the request of implementation you've worked on? Could you let me design my own work and trust that I know what I'm doing, without trying to micromanage me?

I appreciate you care, but we all care. We all have our say in this. Stop leading the testing I do, and start sharing information you have, not assigning me tasks.

I already think you're lovely. Imagine how awesome we'd be if you started believing I can do this? That we all can do this, and that you are not alone in this. That you don't need to track us, but work with us.

The Right Time for Testing

There is one significant challenge working as tester with my current team: self-allocating work to fit the right priorities. With 12 people in the team, significant responsibilities of both owning our components test automation & other testing as well as accepting work into the system we are responsible for releasing in our internal open source community, there's a lot of moving parts.

In times before agile, a common complaint from testers was that we were not allowed to join the efforts early. But now we are always there. Yet yesterday someone mentioned not getting to be in the new feature effort early enough. With many things going on, being on time is a choice one has to make personally, to let go of some of the other work and trust other people in the team (developers) can test too.

With incremental delivery, you can't really say what is "early" and what is "late". Joining today means you have a chance of influencing anything and everything over the course of improving it. There is no "it was all decided before the efforts started". That's an illusion. We know of some of the requirements. We're discovering more of them. And testers play a key role in discovering requirements.

We've been working on a major improvement theme since June. Personally, I was there to start the effort. Testing was there first. We're discussing timing, as I'm handing the "my kind of testing" responsibility to another senior, who is still practicing some of the related skills. They join later than I joined. But the right  time for all of testing is always today: never too early, never too late.

Yesterday I was looking into helping them getting into the two new areas I do regularly that they are getting started on: requirements in incremental delivery, and unit tests within current delivery. 
I made a choice by the end of the day. I will choose unit tests and fixing a new developer. The other will choose requirements and fixing future iterations.

To succeed in either, we cannot be manual testing robots doing things automation could do for us. We're in this for a greater discovery that includes identifying things worth repeating. Exploratory testing feeds all other ways of testing and developing.

The right time for testing is today. Make good choices on what you use that time on. There's plenty of choices available, and you're the one making them even when choosing to do what others suggested or commanded.

Tuesday, September 11, 2018

Tests Surviving Maintenance

As we create tests to our automation suites, we put some care and effort into the stuff we are creating. As part of the care and effort, we create a visualization on a radiator on how this test is doing. The blue (sometimes yellow/red) boxes provide a structure around which we discuss making a release with the meaning of basic things still working.

When something turns not blue and the person who created the piece of code is around, they usually go tweak it, exercising some more care and effort on top of the already sunk cost. But a repeating pattern seems to be that if the person who created the piece of code is not around, the secondary maintainer fixes things through the method of deletion.

I had a favorite test that I did not create. But I originated the need of it, and it was relevant enough that I convinced one of my favorite developers (they're all my favorite, to be honest) to create it for me. It was the first step to have a script doing something a colleague was doing over long term, just opening the application and seeing if it was still alive.

I cared for that test. So I tested what would happen if the machine died by letting the machine die. 
The test, like so many other tests, did not survive maintenance. Instead of bringing back the machine it was watching, the watcher vanished.

As I mentioned this on twitter, someone mentioned that perhaps the test was missing clarity of intent. However, I think the intent was clear enough, but debugging for a vanished machine was harder than deleting the test. Lazy won. The problem might have been lack of shared intent, where people have the tendency of maintaining other people's stuff through deletion. The only mechanism I've seen really work on shared intent is mobbing, and it has significantly improved in previous cases the chances of other people's tests surviving maintenance.

Lazy wins so easily. Failing tests that could prevent deploys - for the reason of them showing the version should not be deployed - get deleted in maintenance. It's a people issue, not a code issue.

We need blue to deploy. Are we true to ourselves in getting our tests to keep us honest? Or do we let tests die in maintenance more often than not?

Friday, September 7, 2018

Three Kinds Of Testing

This week brought me a couple of reminders of a past I wish I had left behind, but one that is still very much day to day to some other testers. This is a past of writing test cases. And when I say writing test cases, I mean the non-automated kind. The documents that help drive testing. The idea that if only we wrote them well enough, anyone could pitch in to any of the testing.

There are organizations that put careful thought into their test case documentation. I'm lucky to be in an organization that puts careful thought into their test execution with emphasis on learning.

Some weeks ago I tweeted that I donated think we need to use both automated and exploratory testing because these are not the same. With this weeks realizations, I think there is three kinds of testing.

There's the kind of testing I work with. I would call that exploratory testing. It engulfs smart use of tools, programming and even regression test automation in a frame of learning.

There's the kind of testing that test case folks work with. I would call that manual testing. It includes creation of manual procedures for testing, with emphasis on planning ahead of time not so much on learning.

And then there's the kind of testing that all too many test automation folks do. They take a manual test idea, turn it to automation so that whatever is hard is left out. They take their "designs for tests" from somewhere outside their own work.

The first kind is really the only kind. And people doing that kind of testing may identify as testers, test automation specialists, or software developers. It's not about the role, but about the mindset of learning through empirical evidence that seeks to disprove to build a stronger case for the idea that things might work after all.