3 Research-Backed Reasons You Can't Be Blamed for Missing the Deadline

You work in software development, and that means there's a lot to do.

Last week, a long list of tickets that absolutely have to be fixed were presented to my coworkers and me. To get through this situation, you've probably asked yourself, "Will I ever become a guru like the guy next door?". This is the wrong question.

The entire circumstance has nothing to do with you personally, but you can do something to counteract the whole thing.

1. It Is Not Your Fault

The software development environment makes use of your utilization capacity over 85%.

Working in an agile environment (Scrum, Kanban, OKR) makes every developer feel constantly fully loaded. Since everyone I know works in such a work environment, you will also have felt this negative stress already. Humans are not meant to act like robots at an assembly line.

These agile frameworks utilize 100% of the given time; humans are already overloaded with 85%.

No, It can't be your fault for not delivering on time.

Imagine digging into the complex world of source code.

An email notification pops up.

The colleague is complaining loudly.

Your product owner calls; a bug was found and wants you to fix it urgently.

In other words: if you are already crapped out on work, the first impulse to respond to such requests is not an "I'll do it right away!" but usually something much less pleasant.

If you comply with the emergency call, your normal work remains undone.

So it's better to refuse the emergency call?

That's not a good option either, because no matter how you do it, there is always some stakeholder who will not agree with the result. Think of arguing with your girlfriend - she is mad afterward, although you were right. Either it's your fault, or it's your fault.

If it is always your fault, you can sit back and do what you can, since you know how it will end obviously; better keep your time and mental health for the more important things in life.

2. Why it Does Always Happen to You

Although it is not your fault, you ask yourself immediately, "Why me!?"

It is always you.

You are the responsible developer.

You are responsible for the outcome. Yes, you are, but you are not responsible for the tasks scheduled above your head. Someone has promised something to someone else, and this was not you. In most cases, certain features that are suddenly seen as necessary are hastily adapted to the product. The sheer importance of this feature seems explicitly overloaded, but it has to be done right now - without even questioning.

3. Calm down & Communicate The Problems

Although it is not your fault, you are stuck being the lucky one dealing with it.

The ones above, you just decide what happens and when. But you are the lucky guy dealing with all this BS. Relax to invest the energy into the actual coding part.

If you do so, you will see how everything starts to work out even better. Creativity heads as you and I need space to breathe to make complex code work.

There are reasons why companies like Google or 3M explicitly plan and provide for such free spaces. They call it the 20% project.

Agile methods like Kanban, Scrum, or the Theory of Constraints (TOC) are knowingly passed over.

Too much ceremony.

Too many tickets.

The absence of a Work in Progress (WIP) Limit, and especially too many bugs are the main problem. I bet you've already experienced exceeding daily stand-ups, and you should communicate this violation. It is in your interest to gain everyone more time on development.

This ultimately means you've freed time for the team and yourself to develop the urgent bugs and fancy features; with a quiet mind comes excellent output.

Questioning the customer is time-intense.

Answering this seemingly simple query costs additional time.

This time is not available for solving problems, refactoring, or fancy features.

In 2019 my team and I worked for five weeks just for the dump. We brainstormed, planned, and implemented this one MUST-HAVE feature. Our product owner and we had believed it is vital for our customers. In the final meeting to review this feature, we got the blessing message: nobody needs or wants this feature. One call would have saved us all five weeks of development.

You aren't disturbed; you get disturbed.

It needs a certain amount of time just to pick up where you left off.

The actual gross loss of time due to a single disturbance may well amount to ten to fifteen minutes. It is not your fault; you haven't decided to get interrupted by others, have you? To close all chats and the mail program when you dive into your codebase is the best way.

To work peacefully is the greatest a creative head like you can obtain to write out quality code.

Takeaways

• You have only a certain amount of brain capacity.
• It is not your fault that the feature/bugfix was not done before the deadline - overload is the new average.
• The higher ground has buried the guidelines of helpful frameworks.
• Features are rated internally instead of asking the customer
• Emergencies interfering with already existing emergencies are the reason for a catch-22.
• Raising the alarm when something goes wrong is one way to deal with it
• Relaxing and focussing on the part you are working on is the second way to deal with it

Always remember: Done means done; not perfect.

Conclusion

Your capacity is finite.

A permanent overload is harmful.

Constant overload is the default of each agile framework.

The limit to overload is already 85 percent, even for routine activities. The exact limit always depends on the activity and your personality. For people who work creatively, the value of the planned workload should undoubtedly be lower. The same applies to jumpers who act as a quick reaction force for urgent problems.

Corporate culture is mainly the driving force of these circumstances.

I can only repeat myself: it is not your fault. Sadly, this is also the environment in which you spend a large part of your daily life. So it is in your interest & worthwhile to use every influence you can get from this article.