Hope Driven Development

Sunday, 29 May 2011

So shit hits the fan

So after weeks of hard work you release your work into production. The release is fine, then users start to use it and then... you inbox gets slammed with bug reports and your phone is ringing with angry people on the other end. What you released wasn't working properly and people are getting mad.  This is natural because at the end of the day they paid for it and it is not working.  You would get mad too!

What to do... what to do? Freaky out? Panick? Get angry? Have you ever dealt with customer service and they were rude or unhelpful? You probably got even more annoyed with the whole experience as a whole. What to do? Be calm and try to listen to your users. If they are swearing at you, just try to be constructive and get them to demonstrate the issue to you. Keep these interactions going for as long as you need to get all of the information on the issue, then tell them that you will look into the issue and this is going to be treated as a high priority.
  1. This will buy you some time to investigate the issue
  2. Don't forget to keep people updated of your progress
  3. Try to figure out within 30 minutes if a fix can be done quickly or a work around is possible so that the necessary paperwork or steps to rectify the problem can be initiated.
Be prudent to test more in the future to prevent this case from happening again. Even the best tech companies release things into production with bugs (ie. Apple iPhone 4's antenna issue), but it is how you deal and manage the situation that will separate you from one stupid product to a respected product. Afterall to err is human.

Why doesn't it work?

Sometimes you are in a situation where you get requirements and it is all confirmed by end users and your business analyst. You head off merrily delegating tasks and breaking this requirement into smaller chunks and work on delivering the solution.  Once done, the end users say what is this? Why does it work like this? This is a classic example of a waterfall creeping into an agile world.

Things you can do to try to safeguard yourself
  1. Get requirements early and reviewed with everyone in the team
  2. Rapid prototyping. Everything is good in theory but sometimes when you see it in front of your face it is not exactly as you imagined. This is the same for business users. Fail early, fail fast and improve upon it to come up with a better solution.
  3. Don't be afraid to show progress even if it is something small. Many small wins are better than one massive fail. If you were able to do something minor like being able to upload data, show people, this might lead to discussions of how it would be stored and data retention questions. 
  4. Review and revise requirements with everyone in the team again at each demo stage
Make sure everyone on the team who is involved with the feature is 110% sure on how it works from end to end. Any grey areas will lead to ambiguous assumptions and that usually leads to confusion and maybe even failure.