Surprise

A lot of people like surprises: parties, finding that 20 dollar bill in your jacket you forgot about, or finding out some excellent news. Yet some don’t like getting scared at a haunted house at the amusement park or getting a flat tire. We live in a world where there is always something that will give you that quick initial reaction of joy or fear. In testing, at any level, there are surprises daily, and for the most part, they don’t end up being any fun.

No matter how much planning executed from the start, there will always be that one or two things that could cause things to go off the rails. Risk analysis and mitigation is something everyone should be doing when going through any initiative, regardless of the methodology used. The adage “hope for the best, plan for the worst” is something that I use at any time. I am thinking about how to go about things. Now there are limits to how much someone should plan for the worst. Like if I plan a family trip, I don’t prepare for earthquakes because they are infrequent. Just like in a software delivery project, you don’t plan for a potential flood or power outage; the probability for those to happen are low, one would hope.

The best thing anyone can do is plan for the most probable things to happen, with a few not so likely. That is the best thing one can do, and the use of a risk analysis process is something that would help identify what issues could come up and how to mitigate or handled if they occur.

The best two stories that I have for surprises were at two different stages in my career and helped me understand the best way to handle them. One was from a previous post about taking ownership of your actions. A simple keystroke can do a lot of damage :).

The other story is when I was working on a project with a third party where information flowed back and forth. During a two-month execution process of sending files, we were about to consider the project closed and ready for deployment. I think you can see where this is going. Well, about a week before we were going to deploy the third party decided to tell us that the information sent was incorrect and was always wrong. Not only put the project in jeopardy, it potentially put an entire release, with about four other projects, at risk of not going in. After some discussions and investigation, the main culprit was a requirement with insufficient detail, yet both sides signed off on the expectations. Luckily it was a quick fix and a full day of validation and risk assessments to ensure the release was ok to go.

Now that surprise wasn’t one of the fun ones and could have been avoided. Asking the right questions, pushing back on requirements, or getting consensus on every detail. Regardless, in the end, it is how someone deals with a surprise that will determine success. A person can be one of the ones that can be seen on Youtube completely freaking out over everything of it could be a person that is calm and works through the issue to get things right. It may not have to be a perfect plan on the spot, as long as something is thought through and collaborated with others within the team to get things done.