Friday, February 26, 2016

Changing conversation from bugs

Today feels like a good day to celebrate the progress we've made in my team. I'm approaching four years at this job, and while I'm regularly thinking of moving on, I just love what we do.

Four years ago, one of the hallmark moments was a day few months into me being in the company, when the product manager came to my cubicle, started shaking my hand and told me first he owes me a beer. He had thought until that point that when software comes to him, he should expect it to be broken. I changed that by providing information to my developers they needed.

At first, there was a lot of pain. Our sprints were awful and always late. I convinced the team and product management to try out daily releases and things improved a lot. We also stopped estimating efforts to implement stuff, and focused our discussions on how we can make it small and whether it is the thing to do at all. All the energy that went into looking good in estimates could now go into developing ourselves and our product.

About a year ago when writing my CV as I was looking for opportunities to work in US (still looking, but I need to find my brilliant team/organization that sponsors the H1N visa). I looked at some of my results bugs and added this: "Personally reporting and getting fixed 2261 issues over a period of 2,5 years on Granlund Designer and Granlund Manager projects". I was shocked as  that means that on average I had reported 2,5 bugs every day. I had already worked on improving the skills of the developers in developing and testing, but I felt I needed to step up the game.

A year ago, I intentionally emphasized discussion and developer learning. I started pushing my team to practice together pairing (rarely, they hate it) and mobbing (more regularly, as they learned to love the learning). And the result is that I've logged 348 issues in the last year, but that is only  1,1 on a daily average. My big (and regular) successes are the times when developers get in touch explaining a feature, and just look at me and tell me what they now know is wrong with their implementation. They hit the mark better, and our relationship has increased in quality.

We release on average twice a week, and our end users rarely see problems they would complain about. The amount of test automation is ridiculously low, but the technical quality of our code (a thing I champion for regularly) is good and improving.

I feel I've gone through an intense year of changing the conversation from bugs to value and skills, and it's been worth it. For a second year in row my collaboration review with the manager focused on how much I've helped the team to grow to empirical feedback and actionable suggestions, not on finding or missing bugs.

This is why I love long-term commitment. I now know that apart from one troublesome individual (see the previous post), my team will excel without me when I leave.

No comments:

Post a Comment