Good conversations are powerful. I made a new friend over organising Tampere Goes Agile last weekend. As he seemed curious about me presenting - something I don't get to do when I organise - he found a video of my talk in Latvia two years ago and watched that. Having watched, he pointed out that I said something horrible. At a point of the conversation I'm having with the audience, I refer to how things are at my current, back then new, place of work. I talk of large amounts of bugs and the number of people testing, and the idea that with a lot of bugs, there's a lot of fixing so adding testers might not be a smart or necessary move. And I say that developers don't care for fixing bugs.
I found that observation particularly interesting, since the answers I tend to give come out of context I work in. Back then, I was struggling with a new team that released once a month but were lost on all kinds of testing. Releasing once a month was "agile" to them. The work was very heavily lead content-wise by a product manager, who would tell the developers which bugs they could fix. The product manager would easily decide on refactoring as well, the team was very much powerless. The fact that the bugs got listed as feedback was new, and there was not an actionable mechanism of fixing that many issues all at once. It wasn't due to regression that the product was broken, it just was that way and the end users (or the product managers) wouldn't come back with that feedback unless they really had to.
Talking about that point with my friend made me realise that the world that empowered agilists live in is quite different from this one. You get a lot of say on how whatever you're implementing gets implemented and you work on making code beautiful, not getting instructions not to refactor from the product owner. You stand your ground on including what is important to include when doing the work, like (unit) tests. Refactoring is continuous, and there's not a need to go ask for a "six month project" to take time to clear the mess you've gradually created.
With my reaction of explaining more of the context I was in then, I realised two things. First of all, I realised we've gone a long way in the two years I've spent with them even though we still have a long way to go. Second, I realised I was using context at hand as an excuse for me to focus on things in my direct power. There are plenty of ways I could have focused more on empowering the developers. I could have just focused on helping them through the braveness to refactor, focusing on development skill instead of what I was into, the study of my own testing skills in whatever context I was handed.
What may be horrible for some can turn into normal for others, and my developer colleagues had been in that world of normal for such a long time that they had given up to an extent to the perceived lack of power in saying how they do things. They were lacking feedback through testing. At first when they started getting the feedback they had been asking for as I joined in, it really depressed them. The amounts of issues, the lack of time to handle any of those, that doesn't exactly turn out motivating. Dictating what was to be done from outside the team wasn't motivating. And with the lost motivation, the driving force was the perceived lack of power.
The core of my answer from two years ago still holds. I find no sense in hiring more testers, when the needed focus on a team is clearly on the side of fixing. But the idea of developers not caring to fix the bugs is an unfair statement. When pushed not to think for a long time and give in on the level of quality you would want to deliver, you may appear not to care. But often that is just a way of coping.
I know my developer colleagues a lot better now. I know they care. I know they can do things. I've had people over training them on unit testing (and refactoring while at it) and coding in general - things they did not get to do enough. And they've found their inner strength to feel empowered to do things better through teamwork and new technologies that boost their motivation as certain things (performance related) are now in the realm of possibilities.
The same team that I commented on two years ago as developers who don't care now work in smaller chunks, reacting to recent feedback instead of having to fix a pile of problems that had been left back from the lack of feedback they always requested.
I just love the power of good conversations, that leave you thinking to a point of writing a blog post in the middle of the night. This conversation in particular is a good one, the core reminder for me is that the positive thinking on what my developer colleagues do turns into a positive change over time. I should be careful implying that people who have not found the power to use their smarts would be intentionally that. Empowerment and encouragement are game-changers for the better. Timely feedback supports that. And there's more I can do to help them, faster.
I found that observation particularly interesting, since the answers I tend to give come out of context I work in. Back then, I was struggling with a new team that released once a month but were lost on all kinds of testing. Releasing once a month was "agile" to them. The work was very heavily lead content-wise by a product manager, who would tell the developers which bugs they could fix. The product manager would easily decide on refactoring as well, the team was very much powerless. The fact that the bugs got listed as feedback was new, and there was not an actionable mechanism of fixing that many issues all at once. It wasn't due to regression that the product was broken, it just was that way and the end users (or the product managers) wouldn't come back with that feedback unless they really had to.
Talking about that point with my friend made me realise that the world that empowered agilists live in is quite different from this one. You get a lot of say on how whatever you're implementing gets implemented and you work on making code beautiful, not getting instructions not to refactor from the product owner. You stand your ground on including what is important to include when doing the work, like (unit) tests. Refactoring is continuous, and there's not a need to go ask for a "six month project" to take time to clear the mess you've gradually created.
With my reaction of explaining more of the context I was in then, I realised two things. First of all, I realised we've gone a long way in the two years I've spent with them even though we still have a long way to go. Second, I realised I was using context at hand as an excuse for me to focus on things in my direct power. There are plenty of ways I could have focused more on empowering the developers. I could have just focused on helping them through the braveness to refactor, focusing on development skill instead of what I was into, the study of my own testing skills in whatever context I was handed.
What may be horrible for some can turn into normal for others, and my developer colleagues had been in that world of normal for such a long time that they had given up to an extent to the perceived lack of power in saying how they do things. They were lacking feedback through testing. At first when they started getting the feedback they had been asking for as I joined in, it really depressed them. The amounts of issues, the lack of time to handle any of those, that doesn't exactly turn out motivating. Dictating what was to be done from outside the team wasn't motivating. And with the lost motivation, the driving force was the perceived lack of power.
The core of my answer from two years ago still holds. I find no sense in hiring more testers, when the needed focus on a team is clearly on the side of fixing. But the idea of developers not caring to fix the bugs is an unfair statement. When pushed not to think for a long time and give in on the level of quality you would want to deliver, you may appear not to care. But often that is just a way of coping.
I know my developer colleagues a lot better now. I know they care. I know they can do things. I've had people over training them on unit testing (and refactoring while at it) and coding in general - things they did not get to do enough. And they've found their inner strength to feel empowered to do things better through teamwork and new technologies that boost their motivation as certain things (performance related) are now in the realm of possibilities.
The same team that I commented on two years ago as developers who don't care now work in smaller chunks, reacting to recent feedback instead of having to fix a pile of problems that had been left back from the lack of feedback they always requested.
I just love the power of good conversations, that leave you thinking to a point of writing a blog post in the middle of the night. This conversation in particular is a good one, the core reminder for me is that the positive thinking on what my developer colleagues do turns into a positive change over time. I should be careful implying that people who have not found the power to use their smarts would be intentionally that. Empowerment and encouragement are game-changers for the better. Timely feedback supports that. And there's more I can do to help them, faster.
