How to meet deadlines with feature teams?

Ensuring that we meet deadlines is probably one of the most contentious topics in software development. Ever since the advent of the Agile movement, there have been endless misunderstandings, oversimplifications, and especially resentments from teams and Agile people towards management regarding this topic. The most targeted group has probably been the project and product managers, since they are usually tasked with ensuring deadlines are met.

I definitely don’t want to keep repeating the same arguments yet another time. “In Agile, the scope is flexible instead of fixed, blablabla.”

Instead, let me explain the dynamic of deadlines in the context of many teams, specifically feature teams that share the same customer-centric backlog, in a typical larger organization.

First, it is important to distinguish between the real deadlines and the harmful ones. Recognizing the difference is not really easy.

The following ones are types of real deadlines. The list is definitely not complete:

1. First-mover advantage or playing catch-up: We must launch a sufficiently complete product well before Christmas this year and ahead of competitors.  
2. Regulatory requirements: Missing the timeline could cause the company to lose its operating license.  
3. Dependency on an external product: A new car with autonomous driving is expected before May 2026; if delayed, the vehicle will ship without that feature, reducing its value.  
4. Contract renewal: Failing to finish the replacement system before the current agreement ends would require renewing with an external vendor for three more years at substantial cost.  
5. Client business targets: The goal is a 50 percent increase in customers by year’s end, which requires market entry by June with these capabilities.

Then we have questionable deadlines:

1. HIPPO (Highest In Pay Person Opinion) deadline: a senior figure expects delivery by a specific date. The rationale may be questionable, yet no one challenges the HIPPO.  
2. An important stakeholder’s individual objective—and related bonus—relies on timely completion. This aim might matter, but how does it weigh against the goals of others who may suffer from meeting it?

And the dysfunctional contract game deadlines. In other words, fake deadlines:

1. Stakeholders set deadlines because they feel teams are lazy by nature and should be under deadline pressure to perform. Reducing the scope is, in this case, obviously not an option.
2. Similar to the previous one is when stakeholders ask engineering teams how much time something will take, just to set the deadline with that information and constantly challenge why it is not met, while also changing requirements along the way. The thinking behind this is from the cost-saving perspective and assumption that negotiation is always a good thing to do. “It keeps everyone sharp.” If you are an experienced enough engineer, you know who usually wins that game in the end— nobody.
3. Multiple stakeholders competing against each other over fixed resources (one or multiple teams with a fixed number of people), by inventing plausible reasons for having specific deadlines. This problem is easy to recognize in the product backlog of the teams. Most items have a deadline. Real prioritization is dead in this case.

So, that was about different types of deadlines. We will ignore the last group (contract game ones) since trying to meet those deadlines is futile, or at least very wasteful. I’ve seen countless teams endlessly suffer from these.

And now the actual answer to the question: How to meet real deadlines with feature teams?

De-prioritize other things

The focus is often on the deadline itself and its objective and trying to make it happen. But the focus should be first on other objectives or work that might need to be postponed so that (more) teams can focus on the real deadlines. In the case of feature teams and a shared backlog, this is relatively easy since there is high transparency and a holistic picture of all objectives, and teams are by design capable of working on the most important work since they are not overspecialized. If teams have their own explicit or implicit backlogs, then you lose this ability.

If teams become overspecialized (only work on specific components/features/streams), then de-prioritizing things becomes painful. There is too much to learn for other teams to help out effectively, while the deadline clock is ticking. When teams are already familiar with the context/domain at the very least, then it becomes noticeably easier.

Reduce Waste

When carefully observing how work is done, one should notice a huge amount of waste. Some waste cannot be (easily) removed, but a lot of it can.

Information scatter and hand-offs are very common. A Product Manager has one meeting with stakeholders or SMEs to get requirements, writes those down in PRD, then another meeting with the tech lead to discuss these, then maybe another one with the designer. Tech leads have another one to discuss tasks with developers, etc. That sequential hand-off with many meetings and delays in between is actually not the major part of the waste. The real waste is rework that happens due to the telephone game problem. I notice often how individuals experience high individual efficiency, but somehow don’t see all the rework due to misunderstandings as a waste. It is often labelled as “requirements changed”, as if it is the fault of stakeholders. In reality, requirements rarely change, but are rather uncovered or understood better later. A more toxic manifestation is when tech leads or product managers complain about developers not understanding things properly; not realizing how much of the context developers are missing and need to assume or guess. All this creates stress and wastes everyone’s time, and therefore increases risk of missing deadlines. 

Dependencies between teams are also a really common problem and have significant negative effects on deadlines. These dependencies should not exist with feature teams since the definition of a feature team is a team that can fully solve a customer problem without hand-off or dependency on another team. At the same time, not all feature teams are created equal. Also, being a feature team is not a black-and-white thing. There are almost always components that a feature team is unable to change themselves. Harmfulness depends on frequency of changes.

Avoid working individually

One of the most ironic ones is working individually on tasks because that seems most efficient, especially given a deadline. The problem, though, is that deadlines are not missed because individuals are inefficient. It is a rather late discovery that integration and validation failed. One discovers very late that something doesn’t work properly or it is a wrong thing to build. The later this discovery happens, the higher the chance of not meeting a deadline. How does it relate to working individually? Well, the whole point of continuous collaboration is to integrate different parts individuals work on sooner rather than later. If you want to meet a deadline, work more together to integrate more frequently. In this way, teams discover what they have missed much sooner, which makes those issues cheaper, and increases the chance of meeting a deadline. A common way to recognize this individualistic working style is the percentage of work that carries over from one sprint to another. Or, much more harmful, integration and validation (e.g., end-to-end testing) is placed outside of the “normal” delivery cycle individual developers or testers do.

Fully finish things continuously

Agile or iterative development can also be explained as risk-driven development. The sooner we truly finish something small, the sooner we uncover unknowns and discover real progress. This enables us to meet deadlines sooner.

Ironically, I see so-called Scrum and Agile teams everywhere who have iterations or sprints, but don’t actually finish things in those sprints. Not finishing something that is started in the same iteration is missing the whole point of iterative and incremental development. The software industry has almost normalized this behavior with all the consequences (late surprises and missing deadlines). It is especially important that validations happen within the iterations. What “validations” mean is contextual. It could be user reviews, different kinds of testing, measurements, etc.

Choose the simplest solution

Over-engineering is a well-intentioned, widespread sickness. Too many developers are trying to anticipate future requirements as if they know what those will be. In this process, they try to create reusable (read: more complex and it takes more time) solutions. But, in the words of Grady Booch: “Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change.” Hence, we prefer the simpler solutions since the cost of change is then lower. Deadlines are met by trying to do as little as possible with the simplest solutions, but still with the highest quality.

Assumption about fixed scope

A very common situation is when we think the scope is really fixed: “We need to replace the old one, and the new one has to have the same capability as the old one.” This should trigger the question on why we are replacing the old if the new one is the same. Don’t we want something better, maybe simpler, more suited for the current needs? And, even if it would be really fixed, then each capability can be implemented in many ways. The real harmfulness of fixed scope thinking is a non-thinking execution mode (“just deliver fast”) for the sake of the efficiency of meeting a deadline. But the very reason to avoid fixed scope thinking is to open the possibility for finding simpler solutions, which lead to a higher chance of meeting a deadline.

Also, I noticed that fixed scope thinking is also caused by being blind to the distinction between assumptions and factual information. People who are perceived by others as very knowledgeable about requirements that need to be implemented tend to be pushed into a position of acting as being knowledgeable, even if some of that knowledge is often more assumptions or, in the best cases, educated guesses.

Once a deadline is not met, it is also unfortunately rare that a group reflects and learns how much they built something that is not correct, not needed, or not used.