Incompatible cultures

A few weeks back, I started a talk on introducing myself as someone who is not officially responsible for anything, which makes me unofficially responsible for everything. I also talked about how with working in self-organized teams, I find myself often identifying the gaps and volunteering for things that would otherwise fall between.

I'm a big believer in self-organization, and people stepping up to the challenges. I know self-organized teams make me happy, and I wouldn't care to work in any other way.

A lot of communication is one on one, so to talk to my team, I've come to accept that the discussion can come through any of my team mates. There's no "I must be invited to a meeting", but there's "the team representation needs to be present in the meeting". We learn from each other a lot on what questions the others would like answered, and a lot of times whoever acts on the information is the best person to be in the discussion, over someone with assigned power.

I've seen what assigned responsibilities do: they create silos and bottlenecks, that I spend time bringing down. And yet, culturally some people just can't believe there is such a thing as self-organized team - there must be a responsible individual.

I run into this collision of ideas today, as I was seeking a bigger research->delivery task for my team to complete during the difficult summer period when some are here and some are away, and lack of shared responsibilities really shows its ugliest side. As I was asking, I heard that one of my team members has been "assigned responsible" for the research, and the rest of us just do tasks he assigns.

I felt the urge of fleeing. Instead, I wrote this down as a reminder for myself to work more on what I believe an efficient R&D to be: self-organized, with shared responsibilities.

I wonder if that will ever fit the idea of "career advancement" and "more assigned responsibility". Time will tell.

Minimizing the feedback loops

As summer vacations approach, I'm thinking of things I would like to see changed where I feel a recharge is needed before I can take up on those challenges. And I'm noticing a theme: I want to work on minimizing the feedback loops.

The most traditional of the feedback loops is to have the feature just implemented in the hands of the users. I keep pushing towards continuous releasing and related cultural changes in how we collaborate on making the changes that get published.

But it's not just pushing the changes for the end users to potentially suffer from. There's a lot of in-company feedback that I'd like to see improve.  I get frustrated with days like yesterday when all test automation was failing and I still fail to get introduced the changes that would stop the automation from failing from a single prerequisite outside my teams powers. People like walking on roads travelled before, when there would be opportunities for better if we seek out ways to do things differently.

The feedback loop that seems the hardest is the one of collaboration. We co-exists, in very friendly terms. But we don't pair, we don't mob and we don't share as I would like to see us share.

Maybe after the vacations, I will just push for experimenting while making others uncomfortable, in short time boxes. It's clear there are things to do that will make me uncomfortable alone as well, but the ultimate discomfort for me seems to be making others uncomfortable.

 

From avoiding tech debt to having tech assets

The question I always get when talking about mob programming is how could that be a better / more effective way of working than solo work. The query often continues with do you have research results on the effectiveness? 

As someone with a continuous empirical emphasis on my work as a tester, and someone with background in research work at university, I'm well aware that the evidence I care to provide is anecdotal. I have other things to do than research nowadays, and having done that I realize the complexities of it. And while anecdotes are research results, I can work with anecdotes.

One of the themes I like collecting and providing anecdotes on around mobbing is that to me it makes little sense to compare an individual task, but a chain of value delivery. Many times with mobbing, we end up with significantly less duplication of code, as someone in the group acts as the memory to tell that they are using something of that sort somewhere else.

Here's an anecdote I just today added to my collection: "QA person, where were you 9 hours ago when your knowledge would have saved us from all this work?". A team of programmers was mobbing, and wondering how to work on a particular technology. For everyone in the group, it seemed like there was some significant implementation work for somewhat of a scaffolding type of work, and the team set out to do that work. Later, another person became available to join the mob and with the knowledge available to them, eradicated all the work until that point, just having  the information available: an appropriate library for the scaffolding would already be available, and was used on the tests.

I've seen my own team talk around an implementation, starting with one strong idea, and ending up with the best of what the group had to offer. I've watched my team express surprise when days of work get eradicated with knowing the work has already been done elsewhere. I've watched them come to realization that whatever they would have implemented solo, would have been re-implemented to better match the ideas of architectural principles or the best use of common components.

I've also had chances of seeing a mob go through about ten solutions to a detailed technical problem just to find one with least tradeoffs between maintainability, performance and side-effect functionality.

A lot of times the best result - paying back in the long term - does not emerge ever from solo work. And that just makes the comparison of what did it take as effort to generate some value in mob vs. solo all the more difficult. It's not the task, it's not the delivery flow, but it's the delivery+maintenance flow that we need to be comparing.

Fill the Gap

About two weeks ago, business as usual, I installed a latest build to notice that clearly someone from some other team had worked on our user interface. Whatever we had done to make it nice enough had been replaced by problems I did not quite understand. Reporting the issue to offload, and focusing on other things of relevance. 

With communication through various steps on what was the status, we got the word that it would be fixed soon. Days passed, and soon wasn't soon enough. We finished another feature we needed to release, and a thing of temporary annoyance turned into release blocker. 

Friday afternoon, I decided to take a moment on the legwork to learn first that the developer making the changes left for a three weeks of vacation, and the second developer had very much partial knowledge on how the changes he would contribute made their way into the build. He also pointed out that he fixed "the issue" three hours ago and sent whatever he was doing over email to the one now on vacation. 

Asking around a little more, I learned that the thing was that was sent over email, and where it belonged - and that it was in place, yet problems still persisted. I learned to do the necessary tweaks there myself - all I needed was to know what to tweak. 

Monday started with fierce determination to get the problem over and done with. I sat down with the second developer to show him what I saw in the product, and he showed me what he saw in his component test environment. It because very obvious that the simulator he was running was not a match to the real end user environment with the problem. We narrowed down the problem into seven lines of CSS and eventually one line of CSS. 

The mystery started to unfold. The second developer would provide a piece of stylesheet that was correct. By the time it was in the product, it was incorrect. If it was as it was originally given, there would be no problem. 

Hunting down a bunch of Jenkins jobs in the pipeline, I learned the problem was on encoding a particular character that shouldn't get encoded. Speculating on the field that got encoded, we realized removing the encoding would have further effects. What came about was a funny one-hour experimenting with what could possibly work. The speculative solutions of hundreds of characters without a meaning and an argument about clear code vs. comments later, we found one that made sense and fixed it.

It all started with the idea of a bug that needed fixing. It continued to realizing that in a long chain of new and old pieces, ownership wouldn't be straightforward. And I did what we all do in our turn: identify a gap, fill the gap and collaborate on getting things forward. 

In addition to finding the gap, I sat next to people to get the gap filled. I don't need to be assigned responsible to be responsible. 

I could easily still be waiting but I'm not: I fixed the bug.