I've never been a scout, yet all of us regardless of level involvement know the scout rule: You should always leave places you visit cleaner than they were when you found it.
The rule works on code, to remind us on continuous refactoring and allowing our accrued knowledge drive us to make changes to things that were good enough with yesterday's knowledge.
While us spending time with the code is what ends up shipped and changing the life of the real users, code is far from the only thing we end up creating.
For a long time, I have been particularly fascinated with the tickets of bugs, issues, and work that we log on tools like Jira. I've been looking into them in more detail, realizing that they can sometimes be helpful, but more often they are a liability: an excuse to not deal with things, a way to externalize ideas with a significant cost and something any tester is so routinely trained to pay attention to that the change in this requires a whole rewiring of how we deal with things in teams.
I've spent significant personal energy on not writing tickets but instead having face to face discussions. I find myself still a recovering ticket addict, who very easily rather writes a ticket than risks forgetting things, even if the risk of forgetting is what changes the fixing behavior.
Today, I looked at all the tickets I have written while working at F-Secure. I learned that I have logged 748 tickets of all sorts since I started there. Overall, I have now six years of F-Secure service behind me, 3 years ten years ago and now 3 years after my absence. That is 125 tickets for a year of service. Assuming each ticket has taken me 10 minutes to create, that is 20 hours of my life a year.
However, the interesting bit today was not how much of my life I have invested into writing those, or even if that time could have been spent in a better way. Nor was it how the profile has changed since the days when I did not avoid writing Jira tickets. The interesting bit was to look at the possible leftovers I had left.
The scout rule applied to tickets would say that
Out of the 748 tickets, 53 were open today. Only a few of them are things that I actively follow through right now. Most of them were things I had written down, assigned somewhere and forgotten. The oldest issue still open and lying around, unused was dated April 8th, 2005.
Getting a realistic picture of what work is there and what has been dealt with relies on someone cleaning up. A good tester isn't one that reports the most issues, but the one that gets the relevant issues found and fixed. Leaving things messy and tickets lying around isn't serving the information goals of testing, but it is a symptom of me not carrying through my now-understood-clearer-than-in-the-past purpose.
Remembering the scout rule on tickets - my own in particular but people around me in addition, would serve my purpose better.
Comment from Ali Hill at Patreon:
This is really interesting to me too.. The 'recovering ticket addict' comment is especially true for me. I started off testing in a place where you were expected to log 5 bug tickets a day. It took me a while to move away from that mentality, but like you, I tried to have more face to face discussions about issues I'd found. I found that I had more success in getting bugs fixed there and then. I actually set myself a rule that if a bug ticket wasn't going to be fixed this sprint, or next sprint, then I wasn't going to bother raising it anymore.
I see the value in tools like Jira for teams who aren't sitting in the same office, but I've had more success using physical Kanban boards on whiteboards with my teams in the past. People are more engaged with the 'tickets' as they're right there in front of them. The problem is that management need reports, so we were essentially duplicating our task tracking.
Untidy Jira boards really annoy me, so your post has struck a chord, thanks for writing!
The rule works on code, to remind us on continuous refactoring and allowing our accrued knowledge drive us to make changes to things that were good enough with yesterday's knowledge.
While us spending time with the code is what ends up shipped and changing the life of the real users, code is far from the only thing we end up creating.
For a long time, I have been particularly fascinated with the tickets of bugs, issues, and work that we log on tools like Jira. I've been looking into them in more detail, realizing that they can sometimes be helpful, but more often they are a liability: an excuse to not deal with things, a way to externalize ideas with a significant cost and something any tester is so routinely trained to pay attention to that the change in this requires a whole rewiring of how we deal with things in teams.
I've spent significant personal energy on not writing tickets but instead having face to face discussions. I find myself still a recovering ticket addict, who very easily rather writes a ticket than risks forgetting things, even if the risk of forgetting is what changes the fixing behavior.
Today, I looked at all the tickets I have written while working at F-Secure. I learned that I have logged 748 tickets of all sorts since I started there. Overall, I have now six years of F-Secure service behind me, 3 years ten years ago and now 3 years after my absence. That is 125 tickets for a year of service. Assuming each ticket has taken me 10 minutes to create, that is 20 hours of my life a year.
However, the interesting bit today was not how much of my life I have invested into writing those, or even if that time could have been spent in a better way. Nor was it how the profile has changed since the days when I did not avoid writing Jira tickets. The interesting bit was to look at the possible leftovers I had left.
The scout rule applied to tickets would say that
- If I took the time to report, I should make sure that there is a decision or a fix on the issue I carefully crafted.
- I should clean up the trail I leave, and not leave tickets lying around.
Out of the 748 tickets, 53 were open today. Only a few of them are things that I actively follow through right now. Most of them were things I had written down, assigned somewhere and forgotten. The oldest issue still open and lying around, unused was dated April 8th, 2005.
Getting a realistic picture of what work is there and what has been dealt with relies on someone cleaning up. A good tester isn't one that reports the most issues, but the one that gets the relevant issues found and fixed. Leaving things messy and tickets lying around isn't serving the information goals of testing, but it is a symptom of me not carrying through my now-understood-clearer-than-in-the-past purpose.
Remembering the scout rule on tickets - my own in particular but people around me in addition, would serve my purpose better.
Comment from Ali Hill at Patreon:
This is really interesting to me too.. The 'recovering ticket addict' comment is especially true for me. I started off testing in a place where you were expected to log 5 bug tickets a day. It took me a while to move away from that mentality, but like you, I tried to have more face to face discussions about issues I'd found. I found that I had more success in getting bugs fixed there and then. I actually set myself a rule that if a bug ticket wasn't going to be fixed this sprint, or next sprint, then I wasn't going to bother raising it anymore.
I see the value in tools like Jira for teams who aren't sitting in the same office, but I've had more success using physical Kanban boards on whiteboards with my teams in the past. People are more engaged with the 'tickets' as they're right there in front of them. The problem is that management need reports, so we were essentially duplicating our task tracking.
Untidy Jira boards really annoy me, so your post has struck a chord, thanks for writing!
