As the world of software is right now and size of the industry doubling every five years, half of us are with less than five years of experience. This is a major revelation for me, reminding that some - many - of the experiences I've lived though over the 20 years might not even be real for the newer professionals. There's (lucky) individuals that have never experienced a project that was not agile and look at us talking about the change funnily, without being able to relate. With this idea in particular, I've come to realise that courses like ISTQB teaching testing folklore (of really old times!) is getting increasingly ridiculous and more of baggage (e.g. on what developers can and cannot do) than useful history.
There's an experience in the old times, that newcomers don't relate to in the same way: wait times. Still so much dysfunctional agile that this appears, but the emphasis is going down.
Some examples:
There's an experience in the old times, that newcomers don't relate to in the same way: wait times. Still so much dysfunctional agile that this appears, but the emphasis is going down.
Some examples:
- Your developers are working on a feature and you can participate in designing, think through your strategies and tactics while waiting but there's a feeling of waiting until developer feels tester contribution is warranted. The smaller we learn to make the changes, the less this is an issue.
- Your test environment is broken. While you could test, you could only report on the fact that the older web server version really isn't compatible with your software after the decision to support a newer infrastructure. Or the other project's feature just broke what you were supposed to focus on because the environment is shared.
- Your build is broken, something went wrong with integrating the pieces together. Most likely it's not one of the pieces since pieces have owners, but whatever is in between the pieces and stops them from communicating, you work hard to find someone who even starts to look. After all, it could be somebody else's problem.
- You've found so many bugs that your head is buzzing, and you can't focus in trying to find some more before some fixes arrive.
I remember waiting a lot of the years. Waiting for the software. Waiting for the environment. Waiting for the fixes.
In times before agile, I waited more and longer. The longer wait times were natural times to go study and learn some new skills. They were natural times to stop to think about what I'd like to improve in testing, and how I could make the change happen. They were natural times to wonder around the office, talk to other (testers) waiting and build on each other's ideas.
When agile first happened to me, for a while I lost the improvement focus. Retrospectives were a ritual and timing wise short, so only the most pressing issues were addressed. As features to test were arriving continuously, I found myself to be continuously in hurry to deliver the fast feedback, and there were no natural times to stop to think and improve for days. I needed to learn to schedule for improvement.
Why am I writing about this? Why now? I was reminded by a discussion this week, that the courage to plan tasks of significant time on becoming better may not feel easy for those who are new. Those who don't have the comparison point of what it was like when you naturally had slack without organising for it.
Nothing stops us from organising for slack. As thinking professionals, it might even be our responsibility. Improving and getting better as individuals, teams and organisations is part of our work. For each and evert one of us.
