As today’s businesses race to digitize, software development teams are under increasing pressure to deliver new features at high speed. As a result, software project delays become inevitable. It becomes a problem when these delays are treated as a “normal” part of the software development life cycle. While a single delay may not necessarily be cause for larger concern, delays that happen over and over again should be taken seriously, as they’re often a symptom of a bigger and more dangerous root cause.
Software product development is a complex, dynamic system. In a well balanced system, as new requests are added to the product backlog, at the same pace, the existing requests are turned into features available for the customer. When the pace of incoming requests is higher than the pace of outgoing features, the system gets out of balance. If we ignore it, this unbalance will further progress and eventually lead to a system failure.
Here are some common causes I often see in practice:
Planning that’s too optimistic
We’re usually too optimistic by nature and overestimate how much we can do in a certain time period. This isn’t necessarily a bad thing. However, if it happens often, it shows that meeting deadlines isn’t taken seriously. An important agile principle is that only the software developers are responsible and accountable for the effort estimation. Even more, it’s a good practice for each agile team to track the difference between the work committed to be done in a sprint and the actual work done after the sprint. The goal is to observe progress on how accurately the team makes predictions over time.
Overlooking the complexity of implementation
When planning the new sprint features, it’s easy to overlook the complexities that arise during implementation. Quite often, however, the overlooked complexity is a direct result of a complex software design. When the software has a complex structure, and there are no clear patterns on how software modules depend on each other, it’s impossible to have a good mental grasp of how the software works. This makes it impossible to plan realistically. Unfortunately, this is often not easy to solve; however, it certainly requires investigating viable ways to renovate and improve the software.
Unexpected, high-priority defects
A defect in production (a feature bug, performance or security issue) certainly has a high priority and needs to be addressed immediately. But when these kinds of issues too often get in the way of building new features, it’s an alarming sign that something needs to improve. This is a symptom of significant technical debt (i.e. code quality issues) accumulated over time. Reducing this technical debt should have a high priority; otherwise, it’s highly likely that the system behavior and the productivity of development will further seriously deteriorate.
Waiting on input from another team
Software products are usually built by multiple teams, with one team producing input required by another. The work should be distributed among teams in a way that allows for steady information flow in the system. Delays caused by waiting on other teams indicate that a better team organization is needed to minimize dependencies between them. Having a good product leader is central here, someone who oversees the progress of the whole product and sets priorities effectively.
This list is certainly not exhaustive, and there can be many other reasons for delays in software delivery. Nevertheless, frequent delays are a sign for you to slow down a bit, find the root cause of the problem, and get the system back in balance.