Saturday, October 10, 2020

Follow the Swarm

During my holidays, I  read two fantastic books about problem solving and focusing on the important stuff. "Range" by David Epstein fascinated me in that there are plenty of examples demonstrating how people without specialized knowledge in a particular area could find solutions to problems where the best experts got stuck. The book rejects the common believe one has to start and specialize early in order to really get good at something. It lists plenty of famous people in the world having demonstrated the contrary such as Roger Federer, Vincent Van Gogh, Dave Brubeck, etc. 

Experimenting in your career, trying out different stuff broadens the skill to look at problems from different angles and find solutions that are much more difficult to identifiy if you can't get out of your box. It explains also the success story of Nintendo which once was a small company and not very attractive to high talented graduates. 

The other book "Simplicity" by Benedikt Weibel, former CEO of Swiss Railway Corporation (SBB"), goes into a similar direction with other and less detailed examples. He analyzes how the best chess players think in terms of patterns and how to focus on the essential stuff. Less is more. Weibel encourages to make more use of checklists and he also makes a heretical remark when he says that "without a great checklist, Sullenberger had not managed to bring down the Airbus on the Hudson savely" (that's not really my opinion. I think it was a mixture of all, great experience, courage, and a little bit of luck). 

Big Data is an interesting tool, but it is not solving our problems and it is not free of failure (examples in the book). I am not advertizing but simply sharing my thoughts on two great books full of valuable hints and references although I know, it will be difficult to not fall back into old habits.

Interesting related reading:

  • The Carter Racing Case Study:
  • The missing bullet:

Thursday, October 1, 2020

Tag submarines before they shoot

In the retrospective meeting it was claimed we could probably have raised some hot issues earlier. The late addressing of these items put people under pressure shortly before rolling-out. Although it was correct that we had quite some late change requests which hurt not only devs but also testers, most of the issues were not late discoveries but rather late awareness of importance.

 The tickets were raised long time back but, because of release pressure, these were parked aside in the backlog and assigned low priority. We called it the “parking-place”. At that time, a restrictive process of prioritizing tickets was needed to manage the deadlines. The limitations were accepted for a while. But over time, things changed.  What was once rated low priority for release N, all of a sudden became more important in the next release and at a bad timing. For many stakeholders including me, these tickets came out of nowhere like submarines; and of course, all at same time.

As a lessons learnt, we - as testers - have decided to get better by regularly reviewing parked tickets. This is to help everyone in the team to become aware earlier of potential new dangerous "submarines" intending to surfac on the water plane soon. There would still be enough time then to tag these before they have a chance to shoot.