We always apply our best efforts to complete our work.
We do not make excuses. —from the 8th Light Principles of Steadily Adding Value

Everyone misses a deadline at some point. What separates professionals from others is how they handle themselves when they realize a deadline will be missed. This principle is not about us being perfect. Instead it is about what we do when we know we are going to miss a deadline.

What Happens When We Make Mistakes

A little over a year ago, I was on a project that got off to a rocky start. Due in part to a bad transition of team members onto the project, and in part to incorrectly thinking we were going to be working on a greenfield project, we finished zero points in our first iteration. The project ended up being a new application in an existing ecosystem of applications, complete with legacy database. This incorrect assumption caused us to vastly underestimate stories and take a lot longer to get an understanding of the project. I had just finished reading Clean Coder[1], which covers what to do when your project isn't going well, so I was able to immediately put what I learned into practice.

The experience taught me that if a story is not going to be completed on time, people want to know as soon as possible. When things start to go wrong, people want to know why, but they don't want excuses. While the client was certainly not happy that the work wasn't going to be finished on time, they were happy with our level of communication and transparency.

No doubt we made mistakes during this project, and there were several ways we could have improved the project. One simple one would have been to reestimate all of the stories after gaining more knowledge about the existing ecosystem, but given that all the estimates would be going up, the customer was expectedly pushing back. However, the mistakes made weren't the important part of story. What was important in this story is how we conducted ourselves once we realized that our work was not going to be completed, which was often days before the actual deadline.

This principle is about being professional.

How We Conduct Ourselves When We Come Up Short

1. We take responsibility.

   When one starts pointing fingers at other people, reasons start to sound like excuses. When we know we won't complete a story ahead of the deadline, we own up to it. In cases where other people's actions affected our work, we mention that in addition to our own mistakes. We also avoid calling people out by name unless it's absolutely warranted or necessary. If the person we are providing information to wants to know who else was at fault, they will just ask.

2. We communicate issues as soon as they arise.

   If we know we won't complete a story, we have a responsibility to the customer to let them know. Otherwise, if we continue to try as hard as we can to complete the story, knowing full well that it will be incomplete at the deadline, we are just lying to both ourselves and our customer. Our project managers and customer rely on us for complete and accurate information to accurately plan the next iterations.

3. We communicate issues in person, if possible.

   Bad news is always best delivered in person. If that doesn't work, then over the phone is the next best choice. The main reason is that there are less likely to be misunderstandings. It is easier to answer questions immediately and give clarifications. Another reason is that the sooner an issue is brought forward, the sooner a solution or workaround can be found. Often we hit a roadblock that the person we are talking to can immediately help get around.

4. We offer solutions.

   One of the best ways to follow up bad news is by proposing an idea of how to work around the problem or solve it.

   A common example would be if a story were to drastically grow in scope, which can happen due to incorrect assumptions or unknown technical issues, among other things. In this case, we would propose an idea of how to split the story or propose an alternate solution to the same issue the first story way trying to solve.

5. We learn from our mistakes

   This is probably the most important thing we do when we miss a deadline. Everyone makes mistakes, and making one is usually not something to feel ashamed about. However, continually making the same mistake over and over again is never something to be proud of.

   Retrospectives are a good way we learn from our mistakes. They provide an opportunity to evaluate the team as a whole and allow team members to build ideas off of each other. As mentioned before, the focus during a retrospective is not finding blame but on improving areas where the team has struggled. Besides identifying weaknesses, the team reflects on ways it has done well. To make sure that retrospectives aren't filled with all negative points, we have them regularly, instead of as a response to bad events.

Setting Ourselves Up For Success

One of the best ways we prevent making excuses about incomplete work is to complete every story on schedule. To that end, we employ certain practices designed to minimize the number of times we fail to meet our commitments.

1. We treat estimates as commitments

   For many of our clients, our billing is directly tied to how we estimate stories. Therefore, it is Very Bad for us to not complete stories. This puts pressure on us, the developers, to complete stories, so we spend a great deal of effort making sure our estimates are accurate. Some critics of this billing strategy point out the pressure it also puts on the developer to complete a story at all costs or even to push for acceptance of the story when he knows it isn't done. This, however, brings me to the next practice.

2. We clarify requirements

   Before estimating stories, we make sure we know exactly what the customer expects when we deliver it. Without properly setting expectations, it is nearly impossible to meet them. Without spending the time to go over the details, the customer may say one thing, but we interpret it as something entirely different. The customer may also make unspoken assumptions about how to implement the story, so this helps to make sure the story is actually done when we say it is done. Specifying the requirements in detail is in the interest of both the customer and the developer, because it prevents the awkward situation where we genuinely think a story is done and the customer does not.

3. We limit scope

   We schedule weekly iterations and split work into small stories.

   This allows us to commit to smaller amounts of work at a time and makes it easier to estimate how long a story will take. In turn, this makes it more likely that we will complete the work on schedule. Weekly iterations also enable us to make sure we are working on what the customer actually needs. Splitting a story up also has the benefit of making it easier to flesh out all the details.

4. We have daily standups

   Daily standups also provide accountability for getting work done. At some point, we've all been on a team with a developer who doesn't get work done. During standups, their contribution is full of wishy-washy statements and excuses. It is painfully obvious that they are getting no work done.

   Standups also provide quick feedback. It's is a time when the customer has committed to being available, so this is when we mention any issues we have encountered, and the likelihood of completing our story or iteration.

Communication Is The Key

What most of these practices have in common is communication. It is extremely important that we communicate openly and honestly with our customers. This include both difficulties and solutions with an eye towards continuous improvement. Constantly working with our clients to help them solve their problems is the core of being a software crafter.

We at 8th Light are principled; and this is one of the principles we follow.

[1] If advice on how to conduct yourself as a professional interests you, along with more stories of making missing deadlines and other mistakes, I highly recommend reading Clean Coder. In fact, I recommend it to anyone making a living writing software.