I have been working professionally in the tech world for almost six years. The first two years of my career I was a computer technician where I maintained computer labs, resolved problems over the phone, as well as fixed resolved hardware problems with computers and printers. Early on in 2013 I migrated over to writing software, I started out as a full-stack developer working in PHP/MySQL/JavaScript, somewhere in the middle I was working with C# and MSSQL, and today I build mobile applications on Android. So far in my career I’ve learned that delays happen and they aren’t a bad thing. Deniz Altindas via Unsplash A few weeks ago while I was looking through my LinkedIn feed I saw a post that resonated with me. Sometimes flight delays are good. I don’t mind having to wait when there’s something wrong with the plane. While it’s easy to get upset at an airline for delaying a flight, I was thankful that United discovered a problem before we took off. It turns out that their communication wasn’t working, so they had to return the airplane back to the terminal. While this was happening my business partner was on a different airline, and he had a problem with his plane. The plane he was supposed to get on had a small fire in the engine. I’m grateful that the airlines discovered the problem before we were in the air. It was a long travel day but I’m happy that we’re both in New York okay and ready to meet some great people in New York City! I like this anecdote because while it talks about making sure a tube weighing 735,000 pounds can take off and land safely, it can also be applied to software. Delays are often an uncomfortable thing, no one is happy to deal with delays, but providing the delays are productive they are often the best route to take. Take The Time To Get It Right Going back to the LinkedIn post, the plane was scheduled to leave at a certain time and due to unforeseen circumstances it had to be delayed. This delay potentially avoided a catastrophe and at the end of the day everyone got to their destination safely. There is nothing wrong with breaking a commitment so long as you are using that time to make things right. Let’s take a look at an example in the video game industry, The Legend of Zelda: Breath of the Wild was originally slated for a 2015 release. The game was finally released on March 3rd, 2017 and . Were customers upset that the game was delayed for 2 years? Probably. As someone that bought the Nintendo Switch specifically for Zelda I have to say that the delay was well worth it. received rave reviews Notify Customers Of The Delay ASAP The wrong time to notify passengers that their flight is being delayed is after they were on the plane for an hour and now have to deboard. If you wait until the last minute to let your customers know that there will be a delay you are going to piss people off. On the other hand if you realize that the plane is having an issue and you notify the passengers while they are still waiting to board you’re going to have slightly less upset passengers. They are in a semi-comfortable environment where they can make alternative plans and try to stay as on track as possible. When you know a delay is going to happen, let your customers know as soon as possible. It allows them to figure out their plan B, they still won’t be happy but they probably won’t be as unhappy as they could be. Learn From The Delay A delay lets you know that something wasn’t quite right. There are a number of things that can cause a delay: too many defects, inaccurate estimation, understaffing, or over promising. If you find that you are delaying multiple features for the same reason then you are failing to learn from the delay. If the delay was from too many defects then figure out why they are happening. Are the engineers lacking experience or proper guidance? Are your engineers feeling rushed to get the feature out the door? Are the requirements specific enough, or is there too much room for interpretation? These are three possible causes for an influx of defects, there are many other reasons but I’d like for this article to be a sub-10 minute read. Was the delay from inaccurate estimation? If your team practices scrum then you might find taking extra time to do planning poker for story estimation will be well worth the time. On one project of mine which had to be delayed our team was just starting out and we were unable to give accurate estimations. Over the course of several months we invested time in making sure everyone agreed to what a 1, 2, 3, 5, and 8 point story was, and overtime we noticed that our estimations were pretty darn close. My team was consistently delivering 50 points per sprint; the number is arbitrary but the consistency is key. From there we were able to do t-shirt sizing which is a way to estimate epics (collections of stories) and we found that we were within one or two sprints for our t-shirt sizes. From what I’ve seen, inaccurate estimation is usually because there wasn’t an investment in understanding how to estimate a project in the first place, make the investment early on and it will pay dividends in the future. Over promising is the last area example I’d like to cover in a bit more detail. Over promising can stem from an engineer thinking they are doing themselves a favor by overcommitting to work (it looks good early on, it looks less good when you are working 80 hours week over week to live up to that commitment). In my experience though it is usually someone outside of the engineering team over promising, this can be product, sales, or management. In software it’s almost always better to under promise and over deliver, that way the customer get what they were expecting and aren’t upset if something has to be pushed back. Don’t Make Specific Promises Delays happen when you or someone else makes a promise to deliver something at a certain time. Flight delays happen because you were supposed to take off at one time but for one reason or another you were unable to. Software delays happen because someone committed to a deadline without properly estimating and now you are stuck having to delay a launch (or launch a buggy/half baked feature). The most ideal way to handle software development in 2017 is to release small features often. It’s much easier to commit to releasing a series of features over the course of a quarter than to release one feature three months from now. An example of this that you can see today are Steam Greenlight games. Greenlight allows customers to purchase a game while it’s in alpha or beta and are able to test the game while the developers continue to complete the features they are working on. This has the added benefit of being able to take recommendations from customers and figure out if it’s possible to bake them into your product in the future. Oh, and if you don’t make specific promises you won’t have anything specific enough to delay. If a feature bleeds into the next quarter it won’t be the end of the world because your customers can likely still get by with the small pieces of that feature you have already delivered. Good Things Come To Those Who Wait Rome wasn’t built in a day. New York didn’t solve their gun problem overnight. The United States is still trying to figure out how to do health care in a way that will make everyone happy. Nothing is built overnight and sometimes it takes more time than you expect. More often than not taking a little extra time to make sure something is done correctly will pay off in the end. This can result in needing to push back a release, but ideally if the releases happen often the delay won’t be the end of the world. On the flipside if your release cycle is similar to waterfall then a delay can be a major cause for concern, so if the problem can be broken up into smaller pieces (it almost certainly can) then you should go that route. Embrace The Delays Delays are not a bad thing. They are a learning opportunity that will help you out in the future. It’s important to understand why a delay has occurred to and to take steps to mitigate that from happening again. It probably will happen again, but hopefully it won’t be as bad as the last time. Understand that delays happen because you were unable to estimate how long a feature would take and had already committed to that feature with your customers. Realize that but delaying a release you are avoiding negative customer reviews and while some people will be upset they will ultimately be happy providing the product they received works well.
