There does not have to be emergencies

You do not have to have emergencies building software! I felt this was the natural state of the development world for years. I thought that “all hands-on deck call” or the infamous “war room” was business as usual. It does not have to be this way!

Thinking back, most emergencies I have experienced fell into the following 4 buckets.

1. Missing a deadline
2. Dependency not delivered or delivered incorrectly.
3. Production Deployment Failures or Rollbacks
4. Defects in production (often due to a recent deployment)

All of these can be avoided by a few simple steps.

Missing Deadlines – This one should just never result in an emergency as we should know about the risk long before we get here. Have a plan, be transparent and review your plan with stakeholders so they are aware of changes or risks to deadlines as soon as possible.

Dependency issues – Dependency issue often result from a lack of coordination or poor assumptions between teams. Include dependencies in your plan and identify their due dates. Review designs prior to starting the work and include impacted teams in your acceptance testing plan.

Deployment Failures – Failed deployments wipe out all the good your team did during development. This should be considered the most important task of any release cycle. Plan your deployment to include documenting steps, testing steps, rollbacks, and up-down-up activities.

Defects in Production – These are the hardest to mitigate. They often result from edge cases or poor understanding of use cases. The risk of these grows with the size of your deployments. Keep your deployments small, keep your work prioritized so teams can focus on the items in progress and evaluate a release for possible failure points to mitigate.

Emergencies can be avoided, primarily by planning well, staying focused on priority work and communicating with stakeholders and teams.