Deadly deadlines – why a deadline is a reassuring lie

When will it be finished? Will we meet the deadline? How can it take so long?

These are some of the rather impatient questions that many product development teams are facing every day. Often these questions originate from the goal of reaching an unrealistic deadline – a deadline that has never been verified by anyone participating in building the actual product. It’s like me telling a car company when they should be able to deliver a fully self-driven car. Spoiler! I know very little about cars and even less about what can make them self-driven, which is why I have no chance of making a realistic deadline for them. Moreover, as we now know, making a self-driven car is complex. Even if we are able to create the product, the infrastructure might not be ready, or safety issues might occur.

‍The Cynefin model tells us that there are different ways of perceiving things. Problems can be Clear, Complicated, Complex, Chaotic, or in Disorder. Software solutions often find themself fixing something in the complex category, which is why we are reaching for predictability and control, but often in the wrong way. In the software industry, people still tend to believe that they can get a fixed scope on a fixed deadline. The truth is that the bigger the problem you want to solve with your product, the bigger the complexity of building that product and thereby the bigger the risk of not reaching your desired deadline.

The unpredictability in software development is by now a very known attribute, yet wherever I go, the main goal always seems to be reaching a fixed scope before a very ambitious deadline. So why is this the case? What is it about deadlines that is so attractive? And if not deadlines, then what? I want to share my perspective on the reassuring lie we all know as the deadline.

Aarh, Deadline we meet again…

Time and time again, I end up in the same situation, in the same discussions about reaching a fixed scope on a fixed deadline. That discussion always seems to be in some sort of vacuum where no logic or sense of reality can survive.

This discussion often includes person A telling person B about a large number of risks which will certainly have an impact on person B’s dream of being done on a certain date. Followed by person B telling person A to just make it happen! I even, on one occasion, heard the argument I’m NOT going back to the steering committee telling them that we can’t manage to meet their deadline!

The unwelcoming burnout  

Even saying the word deadline gives us a feeling of stress – it even has the word dead in it! The feeling of deadline stress is not to be confused with a sense of urgency, which in my opinion, is two different things. A sense of urgency is a motivation factor created by a feeling of ownership and shared goals. Whereas deadline stress often is applied by someone higher in the hierarchy and provokes the same mental state as fear.

The feeling of fear is something I often see managers use when pushing for a deadline – as also shown in the example in the section above. However, the pressure coming from that feeling of stress and fear can end in teams simply burning out. Burnouts are something you can’t plan for, but they will for sure have an impact on your desired deadline as it often results in key personnel leaving the company or taking sick leave.

I see burnouts happening when a team is overburdened by a fixed scope, an applied deadline and new “urgent” work items constantly coming in. The equation simply doesn’t add up! And often, this is in a setting where failure is not an option, which makes it impossible for team members to be successful. It will at some point end up in people burning out, which is not in anyone’s interest.  

The alternative  

You might be reading this and think: If deadlines are so bad, what is the alternative?

Should we just let people do what they want in the pace that they want? No, of course not, we need structure and goals when developing a product. In fact, it is key to our success! We just need to do it in the right way and talk about product goals, not deadlines.

Even I will admit that I like the idea of setting a date which indicates a date when the product of my dreams will be launched.

It is much like looking forward to NASA sending The Artemis rocket  into space in our pursuit to reach the moon once again, knowing that it will happen on August 29, 2022…Wait… was that launch delayed multiple times due to several unforeseen risks? My point is that even if a deadline gives us a sense of predictability, it is often nothing more than a feeling. If we really want to achieve more predictability, we need to think smart about our goals and constantly refine our ambitions with product releases based on incoming risks and learnings.

We will never be able to reach a state of 100% predictability – software development is simply not that kind of product – however, we can do something to make things more predictable. Doing so might help you create more manageable product goals and maybe even a healthier work environment.  

Creating the stable environment

First, we need to understand what kind of problem we are facing. Is it a small and simple product where everything is clear? Do we know exactly what to do and when to do it? Are there no political conflicts or any questions about what kind of technology is needed? Or is it more complex, where things are rather unclear?

I can recommend using The Stacey Matrix to determine if your product is simple or complex. Remember, do not lie to yourself. Saying that your product is simple will not make it simple! Hint: If many people are involved in building the product, it is often an indication your product is complex. If your product is in fact complex using the right framework for product development can help you create a stable environment for your teams.

From time to time, I find myself having to argue for teams’ ability to use Agile frameworks, such as SCRUM or Extreme Programming (XP), however for me there is no need for discussion, Agile frameworks create stability. And if you are looking for predictability, stability is your best friend. The framework itself creates a setting where teams can plan work in small and manageable iterations without interruptions.

Furthermore, it is important that you coach your stakeholders to understand that urgent work items are, in fact, scope interruptions. Use the team’s product backlog to prioritise what is the most important items for a team to work on during the upcoming iterations. But know, that placing a new item on the backlog will have an impact on your product scope and, thereby a desired timeline.

Agile frameworks embrace the change of direction, but as this article is about reaching predictability, it is important to understand and acknowledge the impact of scope interruptions. Agile frameworks invite to regularity in your software delivery. In fact, the goal is to regularly ship done software increments, which once again… yes, you guessed it, creates more predictability.

Use the fact that your teams are working in a cadence of iterations as your artifact to set goals for your product releases. Small iterations create real-time workload transparency, which can help you indicate what work items are manageable to reach in the nearest future.

More important is it to create a trusting and safe environment where it is safe to fail. If your product is in fact complex it is key to have a fail fast and learn mentality. In a complex situation you do not know everything or what is the right thing to do. Once again small iterations are your friend – try something and if it fails it only had an impact on a very small fragment of the overall development. A safe environment’s key essence is trust, which will create honesty and true transparency, which is key in the pursuit of the predictability.  

Creating the predictable team

Time and time again, I see a distance between managers and development teams. And I must admit it is quite puzzling to me. Managers are seeking predictability and a clear timeline, but they never seem to look in the most obvious place – The development teams! As earlier stated, deadlines are often applied to the teams by external parties.

Furthermore, I see managers try to find a “go to guy” to report the latest state of their product. The go-to guy is and should be the development team! We should include the development team as much as possible when discussing our desired goals. A team might not be able to give you an exact release date, however, they will share key insights and risks, which will indicate the complexity level and help set some more realistic goals for your product.

A common scenario is a steering committee asking a product owner or product manager when the product will be done. In this case, do not give in to the fear factor and create your own reassuring lie by spitting out any date that comes to mind. Be honest and clear about risks and complexity.

Another aspect is to remember that not all teams are the same or are able to execute at the same pace. A team who has been together forever will have a different dynamic than a newly established team. I sometimes experience managers forgetting that teams are people and not machines. If a deadline is in jeopardy, the go-to approach is always to just add more developers and restructure the teams.

We need to understand that stability is key for a team´s ability to deliver. Therefore, we should create a setting in which teams are able to evolve and mature without anyone constantly changing their composition. A stable composition will eventually have a positive influence on a team’s ability to deliver. Trust me!

Conclusion

Deadlines are deadly… Yes, pun indented. Deadlines seem to be our go-to artifact to seek control and a feeling of predictability. However, deadlines are in fact reassuring lies that we tell ourselves to get a sense of comfort in an unpredictable setting which is characteristic of the software industry.

In this article, I argue that deadlines are set up to fail before we even start any development. The reason for this is often the result of external parties applying a desired release date without consulting anybody involved in the actual development.

Teams are given a fixed scope, a fixed deadline and should be able to handle new urgent work items on the go. This manifest itself as an equation that does not add up. Eventually, this will result in failure – where nobody reaches their goals, people burn out, and customers still don’t get our solution to their problem.

But wait… there are alternatives. I argue that if you create a trusting environment where teams feel safe and can deliver in small iterations, progress becomes more predictable.

The key is to be close to the people creating your desired results and through them, get key insights into risks, progress, and workload ability. Acknowledge that adding urgent work items into an already fixed scope will have an impact on your desired timeline. In the search for predictability, you should welcome Agile frameworks that allow teams to work in small iterations which can help give a real-time workload-indication and stability for the development team. Workload transparency can help give a realistic forecast for your product backlog items.

Further, I argue that we need to remember that teams consist of people, NOT machines. All teams are different, and their ability to deliver varies. Like any product, a team needs time to evolve, and we should make sure that the team composition is stable to avoid any extra effort for a team to deliver value. Stability is the key factor, if you reach for the predictability. Moreover, we need to twist our minds to think about product goals and not about deadlines. Goals are great and can provide direction and motivation, but we need to create the goals in unity and constantly refine our product ambition based on incoming risks and new learnings. There are more initiatives to reach predictability in software development, but in my experience, you will come a long way by addressing the subject mentioned here.

‍

‍