Mobbing and competing solutions

With a group of people working together on Mob Programming, there must be moments where more than one person has ideas of what would be the Right Thing to do.

With Mob Testing, I see these as ideas of where the bugs might be hidden. In training setting, I often stop people from following the ideas to keep the group together, and just park ideas actively in the mind map for future - that in training often never comes.

The rule of thumb on mobbing would be to approach competing ideas of solutions with the "do both" approach. At Mob Programming Conference this week, I had just the right opportunity to live by this rule.

In the open spaces, we were trying out mob writing an article. We were trying to describe mobbing for the inexperienced through describing the mobbing we were doing right now, and the line of thought from people who do not mob lead me to an idea of needing a metaphor.

My choice of metaphor and how it came about

After my talk at Agile Testing Days Scandinavia, a question that left me thinking (and discussing with Llewellyn Falco) was about the difference between Mob Programming and Coding Dojo. In both, we have a group. In both, we have a rotation. In  both, we work together on a problem. Mobbing grew out of Randori (coding dojo), so is there a difference?

At the conference, my response was that the difference I've seen was the style of navigation. With the rule of "an idea from my head to the computer must go through someone else's hands", the dynamics of the group changes from watching a pair (coding dojo) to group of navigators channeling stuff to the computer (mob programming).

Llewellyn was not completely happy with my answer, as mob programming as he sees it, isn't really defined by an individual mechanic such as style of pairing. He introduced  metaphors to think about the difference: Is a swimming pool just a bigger bath tub? Clearly not. Is there a difference between a first date and a long-term relationship? Clearly yes. The groups that grow together through mob programming are essentially different than groups that just start the mechanics of mob programming together. The level of trust makes it a whole different ball game.

Navigating the idea to action

Instead of explaining all this to my fellow mob writers in the session, I navigated words onto the text file we were creating. As soon as I was getting the first part of the idea out that us as first time group were more like a first date over an established mob as we were a group of strangers coming together, the others reacted strongly against this. I was not allowed to finish my sentence (so much for kindness, consideration and respect...)

Since we were writing a metaphor, another navigator offered a competing metaphor. What we were experiencing was more like already being experienced in driving a car, but needing to move into a massive truck changing from programming to writing. Being a proficient writer, I naturally disagreed with this metaphor.

Both of us raised our voices ever so slightly. Both of us started talking more about the metaphors, willing to clarify them in many more words. No text was bring written. So I remembered the rule of thumb: Do both.

I had been in half-sentence with my thought, and it was not going anywhere even if I did not finish. I stepped back and proposed to work on the eccentric to me idea, just to see how it would work as text.

The one with the idea navigated the words on paper. As he was finished with his chapter, I no longer cared about my idea - it wasn't any better in terms of clarifying. His words were there and we moved on to describing the experience of choosing what to write on by just writing and delaying the commitment.

Review for consistency & correctness

With the article done, we took upon ourselves to mob with reviewing for consistency and correctness. And in this reading, we ended up deleting also the other metaphor. It left bits around it, that we refactored into something that made more sense thinking of our audience. Those bits around were valuable sentences of ideas, ideas that would have not ended up on paper if we had fought about ideas over the implementations.

What did I learn?

I learned that

• Mob programming gives me a useful heuristic to step down on a creative disagreement: do both
• Doing 'bad ideas' generates new ideas that wouldn't emerge if we just argued
• Neither our level of trust as a team or the difference of programming vs. writing mattered for the point we wanted to be making
• I dislike long release cycles: we did not  publish the article right away, it will come out in InfoQ weeks later. So I end up writing a different view into the same experience a lot before our shared experience gets out. 

Product Owner Dysfunctions

Back in my very first agile project in a slightly larger company, we were struggling with deciding what goes into the product next. Like in so many places since, the idea of a product owner was central. I remember phrases like "single wring-able neck" to come out often and be particularly awful. We were always on the lookout for that one magical person who could make all the hard decisions under conditions of extreme uncertainty, someone who was paid enough to be responsible for her decisions. That never really worked.

I remember one time having this wonderful meeting with the five big bosses of the five different business lines on sorting out what goes into the top of the product backlog. They all had enough on their plate of needs to fill the whole development pipeline, and little interest to  give up on their own needs. It was not a collaboration, but a negotiation and it wasn't going so well.

A particularly funny experience was when we tried giving them visual tokens of how much they could contribute to decisions, it was some form of a dot vote.  Everyone voted their own, everything was equal. But then, the game balance was broken by giving one token to the person outside this decision group, and with one token she could tip the balance to choose whatever she wanted. And all of a sudden, the tone of discussions changed into trying to find more commonalities on what the needs of each business area were.

This seems to be a recurring problem for me. I hardly ever have a product owner who could actually make the decisions for the different stakeholders in a balanced way - the team ends up helping with that work and I find that it's great, adding value to that discussion. But I'm still on the lookout.

What is the best way you've found, when relying on a single source of truth is not available, to balance the needs of five major groups of stakeholders? My magic lies within making the batch size smaller and giving each a turn. We can do it all, but not just today. If you have to wait a week to get something of value, it seems to be much better than six months.

Six months into the speaking year 2016, what changed?

When you blog about your goals and ideas in public, it also serves as a foundation to realize that things did not go quite as planned. I wrote a blog post about my 2016 speaking goals in November, and six months later, it is clear it turned out different.

Give a high-profile keynote 

With me, high profile means some of the known names of testing conferences that do keynotes. I'd say it is safe to say by this time of year that I will not be keynoting in a high-profile conference this year.

Then again, I can redefine high-profile to mean some of the great opportunities I've had. I was invited to speak at Agile Testing Days Scandinavia, and the audience reactions (questions, discussions, learning - love it!) were so worth it. I did a paired talk with Llewellyn Falco in front of a large audience at Agile Serbia. And it looks like autumn will include an invited talk (even if not a keynote) in a testing conference I adore, and a keynote in a new conference.

Publish 2 talks as videos online that wouldn't happen in conferences 

I've published a couple of short videos on my own YouTube channel, and contributed three webinars in the community. I have a backlog of talks I'm not sure where I will do that just need to  get out, and webinars with the community players seem like great opportunities. I've also been toying with the idea of just doing a webinar series of my own, or starting a podcast to feed the need to learn through sharing.

Less talks at conferences, just 3 (scheduled 2 already) 

I promised myself I would go out less. I did, but not in this drastic level. From 33 sessions in 2015, I'm now committed to only 20 = 16 + 2 +2 (public + agreed + in discussion). I'm doing slightly better on not paying to speak - only four of those. But that is four more than I told myself to do. I decided to pay for speaking at Devoxx UK (time to try my developer-conference wings),  at Agile 2016 (family reasons to be there for a week), at a test conference in Latvia if they'll have me (supporting the community) and at Mob Programming Conference (long story).

Some workshops at conferences, as paid work (at least 1) 

With this goal, I'm there with the wonderful TestBash pre-training. I had so much fun. And I'm learning that breaking into this circuit is a long term game, many have already all the sessions for next year laid our already.

Coaching 2 new speakers - finish one in progress and start one new

I've coached a lot more than 2 new speakers this year. I think I'm at 7 now. The ones in progress stick with me and come back with new ideas to review and that is wonderful. And new ones emerge both through Speak Easy and directly.

I've also taken my 1st mentee who I teach testing pairing with her regularly. She can teach me automation, I can teach her exploration. It's a win-win. And the world will end up with two more awesome testers than what either of us could be individually.

NEW GOALS

I'll just say I'm changing my resolution here. I'll be going around to places where there's awesome people to connect with. Speaking is much easier for me than mingling and smalltalk without speaking, so I just need to speak to overcome my social awkwardness of assuming people might not want to talk to me unless they come to me first.

Speaking is not about status, it's about learning. There's no better way to learn than to share and invite people to help you learn more. Try it and let me know if I can help. It's always a win-win. 

It's like seeing yourself in a mirror!

There was a problem in production. A feature could be misused so that one user could change the data for the other, and the two users were taking daily turns in correcting things manually to their liking until they came to a point where they decided both to complain that the software is broken because their data only sticks for a day.

Surely, that is not what the users are intended to be doing. They just did not understand that this particular piece of data is shared - how could they, when the application tries actively not to share most of the data and doesn't make a clear distinction on this type of data is different.

I've mentioned this when I joined four years ago. I've mentioned it and negotiated for it to change, regularly. But it took four years before it caused any trouble that would reach our ears.

As the trouble emerges, our product owner is quick to admit that things shouldn't be as they are. But that since they are, a quick fix of making the editing of that data to be only available in special settings could be done. The team looks at the quick fix, and confirms it is indeed quick.

At this point, however, someone decides it is good to include the UX designer into the discussion. She immediately sees that the quick fix isn't really improving usability, and comes up with a slightly more complicated design that would take things forward.

The quick fix of half a day turned into a week of work. The fix that was needed immediately was postponed from tomorrow to happen in a week.

The emergent decision starts to bug me, and I question the bundling, asking for delivering first the quick fix and only later the more complicated design and it's like I'm looking into a mirror: I'm faced with harsh, emotional arguments about the reason why it must be bundled. Because there is so much more other more important work to do, that without bundling it will not be done. The current me looks at the situation, and assesses that if that was the case, then it just shouldn't be done.

Situation escalates with the emotions, and I feel even more like facing a mirror of a younger version of myself. The spirited, committed fight for quality as you believe it should be: users are the key! The need to feel gatekeeper to protect them from bad, even if blocking some of the good. The despair that a better future where things will later be fixed will never come. And I respect seeing the mirror, as it points out how I've changed.

It's not that I would have given up on my bright-eyed strive for indefinitely better, but I've grown to accept that delivering something today, small batches, is the best thing we can do. The other batches will come. There needs to be a balance of improving UX, improving maintainability, and adding new features. When each is done is small batches, we can do all of them without completely stopping any. And we can also completely stop any, for having more items of another kind.

The mirror also reminded me, that when I joined as the only tester of this team, the bugs I could find generated so much work that the whole team was needed on fixing them. Many of the bugs had already been in production, and seemingly the users never cared (or rather, had not cared by that time). It took more patience than what I believed was in me to balance some of the fixing with the features product management would wish to see.

It must be just as painful to have ideas of how to fix things for user interface but not have the ability to take through those ideas yourself or in full steam as it is to report any issues (including UX) as you test but can't fix yourself.

Plans and feedback don't change the product for the better. The fixes and changes do. So yes, there is such a thing as too much feedback. Too much too soon, when you've piled up some backlog.

In four years, the simple functionality bugs have vanished. The UX bugs are under construction. And some of them, including this one really, requires changes in logic way beyond the user interface to really go for the experience we look for. In small batches of forward-driven value, flowing continuously, we'll get there. And learn some more while on route.

What does 10x look like?

On May 2nd, there was a keynote at Mob Programming Conference with a message I need to share with all of you. You know the idea of some people being 10x more productive? Here's how I did not realize to think of it.

If we're running two shops, each with overhead of $95,000 and one makes 100,000 ($5K profit) and the other one makes $145,000 ($50K profit), the latter would be 10x the prior. We do this calculation quite easily and assess the numbers intuitively. No problem there.

But when we start looking at numbers where there's interest and compound interest, we get fooled with the numbers. A $100,000 loan with 10% interest rate is $839 / month if paid in 50 years, and $2124 / month if paid in 5 years. Again, 10x.

The same $100,000 loan with 100% interest rate is $8,333.33 / month if paid in 50 years, and $8,402.31 / month is paid in 5 years. Again, there's the 10x difference.

The 10x with compound interest - like with learning and improving yourself - does not look like you get 10x more done today, but today it might actually look very much the same as if you we're not investing in learning. Compound interest hits you over time and makes the 10x difference. And instead of thinking of debt and loans, we could look at learning that makes us gradually better.

The speaker calculated that what if we spent an hour learning every day to get a 1% increase, how long would it take before the investment paid itself back? That would be 28 days.

With these numbers in mind, the quote shared from AppFolio blog on the company trying Mob Programming sounded especially funny and exemplary to his point of us not recognizing 10x when it is in front of us.

"Unsurprisingly, the team did not achieve 10x productivity. In fact, we found our productivity to be almost the same as it was before…Your mileage may vary, but as far as we’re concerned it’s a resounding no.  

Is the product higher quality? Is there better test coverage? Is the code idiomatic and does it follow best practices? Are the chances of a bug crawling into the product minimized? From our experience this is the most emphatic yes of all the concerns listed above. Not only does having everyone together increase accountability and awareness, but mistakes that may be made by more junior developers are more likely to be caught. Furthermore, when our QA engineer was in the mob, he gained a much better sense of how to go about testing the feature as thoroughly as possible."

The latter chapter is what 10x productivity looks like in software development. Hitting the mark better. Catching the  bugs better. Working together better. We've been notoriously good in this industry at declaring done early, and separating the finalization task from the original creating an attribution error.

How would you count bug reports you never get?

There's recently been a significant transformation on a piece of software we work on with my team. In the last month, we've done more releases of that piece than we managed to do in the year before it. There's a clear feeling of progress. And the progress has included the amount of code for the piece dropping to a quarter of where we started off with the transformation. The final frontier of siloed development has joined team ownership and our drive to clean up things to be understood.

Looking at this piece of software, I'm observing an interesting aura of mysticism on how users approach it. It's like I'm moving into the past where I four years ago surprised our product manager with the idea that software can work when he tries it out - something that should be close to obvious in my books.

I started to think about this seeing a tweet:

"We only had one or two bugs in production in 4 years of mob programming." @WoodyZuill. https://t.co/sKrEsC1VI3

— Cucumber (@cucumberbdd) April 26, 2016

The worst piece of code my team delivered probably had also just one or two bugs in production over the last year. But for us, the reason was that the users would seek workarounds rather than ask for fixes, or that the bugs just did not bug the users enough for them to speak up.

Since we moved the piece of software into the frequent release cycles, we've fixed a LOT of bugs users never complained about. A lot that users had not even run into. Looking at the  bugs we've fixed, I find it nearly impossible to believe that they could have been using the software all this time. But they did, they found their ways around everything that bugs us (and slows them down).

When you get little to none in bug reports from production, do you assume all is well? My sample says I shouldn't. Even asking the users directly might not give you a realistic picture.

And on the other areas where feedback is more frequent: if it bugs a user, it's a bug. And we have loads of things that bug the user, that we rather frame as feature requests, some of which we have no intention of acting upon. Counting them seems more of counterproductive. We could count how often we get interrupted with a quick request to change something in production that reorders our immediate priorities? But most of those wouldn't count as bugs in any traditional sense.

Emotions and trigger words in exploring

This post is inspired from two sessions of mob exploratory testing. I did one in Agile Serbia -conference on Saturday, and Llewellyn Falco did one on pre-Craftconf meetup in Hungary reusing my session description.

In discussing his experience of facilitating exploratory testing mob without me, it was interesting to notice what he had chosen to use from me and what he seemed to do differently. Here's what I learned:

• We both emphasize the private role of the mindmaps created while exploring. It's not a final deliverable and an external document, it's something intended to help you (your mob) while you're testing. 
• He emphasizes more the tracking of concepts on the mindmap than me. It seems I treat the product as my external imagination so that the mindmap is more of a secondary tool for me, whereas he treats the mindmap as a necessary model that needs to be built right from the start. I speculate that the different role we're seeing is related to me primarily thinking of all testing as performance (practice before making pretty much any documents) and he still has the strong developer background that might be driving him towards testing as artifact creation. More discussion on the differences in belief systems clearly needed to understand this.
• We both emphasize paying attention to the emotions while you test, but there is a clear difference in how we try to communicate that. He taught his group to pay attention to trigger words revealing negative emotions: "This is confusing", "I wasn't expecting that". Basically any negative sentiment, frustration and confusing being the most common ones. Trigger words should, as he explained, lead to making a note that drives a discussion about a possible bug with the developers. When I lead a teaching mob, I alert the groups on emotions in general. We both note that there's a lot of uncertainty around on what to speak up about among testers, leading teams to lose information they could have readily available. The encouragement to speak up through feelings is necessary.

I find Llewellyn makes an excellent case for developers picking up the thinking patterns around exploring. Learning from various mob exploratory sessions with testers around the world is probably the quickest way to get practical ideas from people's heads. You should try it too. Let me know if I can help!