Tuesday, May 5, 2015

Hindsight at the office

Today my team learned a major lesson about what our product is supposed to be. I'm ecstatic, having contributed to a world-changing realisation by asking the right thing at the right time. Even if the "world" is just out little product development sandbox. The realisation leads to a major technology/architecture direction change that results from us understanding (or thinking we do - a few more tests required!) our customers actual needs better.

As the lesson sunk in, we spent a bit more time discussing it with the team in a great, open to possibilities spirit in general. I was feeding off the energy. Until someone stated it: if we had known that we need configurable reporting when we created reporting, we could have taken it into account when building it.

I find that a lot of people don't notice what is wrong with that statement: it's hindsight. If we had known - but we did not. If we could redo our decisions, there's a lot of things we'd be wiser about. Learning is wonderful. But it means that before we learned, there was really nothing else we could have done. It would be wonderful if like in games, we would have a save point and three opportunities to do-over, but we don't. That's games, not software development projects. Or life in general.

I find that hindsight is a symptom of not quite yet understanding what Agile means: embracing change. If you always wish you were smarter in the past, are you really open for change and opportunities to learn?

For me, this has been one of the difficult lessons as a tester. I've actively needed to learn to look forward, see that what we make now is the best we can make now, and it's not about my individual contribution where we end up now. But where ever we are, we can always go forward. Agile is a journey, not a destination. Product quality is not a destination either. We continuously evolve our product, with our understanding.

As a tester, this has meant that I resist my urge to say that a change shouldn't happen just before the release. The best way is forward. Make mistakes, fix what you broke and learn. The products you deliver when you don't stop the change because "software is now frozen" tends to be better. And it being better relies on people actively, in collaboration, trying to make it better.