A lot of people like surprises: parties, finding that 20 dollar bill in your jacket you forgot about, or finding out some really good news. Yet there are some that 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 on a daily basis, and for the most part they don’t end up being any fun.
No matter how much planning is done 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 use. The old adage “hope for the best, plan for the worst” is something that I use at anytime 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 plan for earthquakes because they are very rare. 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.
So the best thing anyone can do is plan for the most probable things to happen with a few not so probable. 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 they will be mitigated or handled if they occur.
The best two stories that I have for surprises where 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 needed to me passed 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 to to. Well about a week before we were going to deploy the third party decided to tell us that the information that was being sent was incorrect and was always incorrect. This not only put the project in jeopardy it potentially put an entire release, with about 4 other projects, at risk of not going in. After some discussions and investigation it was found that a requirement was not detailed enough, 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.