Your Developers Are Busy. So Why Isn’t More Getting Delivered?
This can be one of the most frustrating situations for a business leader.
Your developers appear busy. Meetings are happening. Tickets are moving. Problems are being discussed. Everyone seems to have plenty to do.
But releases keep slipping, important features take longer than expected and the business is not seeing enough working software.
The natural conclusion is that the development team is not performing.
That may be true. But it may also be completely wrong.
Software delivery depends on much more than how hard individual developers work. Priorities, requirements, architecture, testing, technical debt, decision-making, leadership and the amount of work already in progress can all affect how quickly a team delivers.
Before changing the team, it is worth understanding the system they are working within.
Signs Your Development Team Isn’t Delivering Effectively
A single missed deadline does not mean you have a development team problem.
The concern is when poor delivery becomes a pattern.
Common warning signs include:
- Work regularly taking much longer than expected
- Commitments or sprint goals repeatedly being missed
- Features remaining “almost finished” for weeks
- Lots of activity but relatively little usable software being released
- Bugs and rework consuming increasing amounts of development time
- Estimates becoming increasingly unreliable
- Priorities changing constantly
- Developers spending much of their time dealing with urgent problems
- Limited visibility of what the team is actually working on
- The business and developers disagreeing about what was requested
- Releases becoming difficult or risky
- One or two developers becoming bottlenecks
- Management losing confidence in delivery commitments
- Developers becoming frustrated with requirements, priorities or management
Several of these happening together suggest that something in the development environment deserves closer examination.
The important question is why they are happening.
Busy Doesn’t Necessarily Mean Effective
One of the easiest mistakes is confusing activity with progress.
A development team can be extremely busy without delivering much value to the business.
Developers might be attending meetings, fixing defects, answering support questions, reviewing code, investigating production problems, responding to changing requirements and switching between projects.
Everyone can be working hard while relatively little reaches customers.
The opposite can also be true. A well-functioning team may appear less frantic because priorities are clear, work is controlled and problems are caught earlier.
Measuring developers by hours worked, lines of code written or the number of tickets closed rarely gives leadership a useful picture of performance.
A better question is:
Can the team consistently turn important business priorities into working software with reasonable predictability and quality?
If the answer is no, the next step is to understand what is preventing them from doing so.
Why Software Development Teams Struggle to Deliver
There is rarely a single cause.
Poor software delivery is often the result of several smaller problems reinforcing each other.
Unclear priorities
If everything is urgent, nothing really is.
Developers may be working hard but constantly switching between competing priorities. Work gets started but not finished, and delivery becomes increasingly difficult to predict.
Constantly changing requirements
Software requirements will change. That is normal.
Problems arise when requirements change faster than the team can deliver them or when completed work is repeatedly changed because expectations were unclear.
The result can look like poor developer productivity when the team is actually rebuilding the same functionality several times.
Too much work in progress
Starting more work can create the impression that the team is moving faster.
Usually, the opposite happens.
Developers spread their attention across multiple features, bugs and projects. Work takes longer to finish, context switching increases and bottlenecks become harder to see.
Unrealistic deadlines
Sometimes the delivery problem begins with expectations that were never realistic.
A deadline may have been set before the technical complexity was understood or without considering existing commitments, dependencies and team capacity.
Repeatedly missing an unrealistic target does not necessarily mean the team is underperforming.
Technical debt
Software becomes harder to change when shortcuts and compromises accumulate.
Eventually, seemingly simple changes start taking longer. Fixing one problem creates another. Developers become reluctant to touch certain parts of the system.
The team may be moving more slowly because the software itself has become difficult to work with.
Weak software architecture
Architecture decisions can have a significant effect on delivery.
If the system is tightly coupled, unnecessarily complex or difficult to test, developers may need to make changes across several areas just to deliver a relatively small feature.
Insufficient testing
Without effective automated and manual testing, developers can spend increasing amounts of time finding and fixing problems that should have been detected earlier.
Releases become slower and riskier, while bugs continually interrupt planned work.
Skills or experience gaps
The team may not have all the capabilities required by the software.
That does not necessarily mean people need replacing. It may mean particular expertise, mentoring or technical leadership is missing.
Insufficient capacity
Sometimes there genuinely is too much work for the available team.
Before hiring more developers, however, it is worth confirming that capacity is actually the constraint.
Adding people to a dysfunctional delivery environment can simply create a larger dysfunctional delivery environment.
Key-person dependency
If only one developer understands a critical system, architecture or deployment process, that person can become a bottleneck.
Important work then waits for their availability.
If this sounds familiar, see Too Dependent on One Developer.
Poor communication between technology and the business
Developers may believe they have delivered what was requested while the business believes it asked for something different.
When this happens repeatedly, the problem may be how requirements, priorities and decisions move between the business and technology teams.
Weak technical leadership
Development teams need more than task management.
Someone needs to provide technical direction, make difficult trade-offs, manage technical risk and ensure development decisions support the wider needs of the business.
If this appears to be the underlying issue, see Technology Leadership Problems.
Is the Development Team Really the Problem?
This is worth asking before making significant changes.
Poor delivery does not automatically mean poor developers.
The team may be working within an environment that makes effective delivery extremely difficult.
For example, developers may receive changing priorities from several managers. Requirements may arrive without enough detail. Product decisions may take weeks. Technical problems may have accumulated over years. The team may be supporting existing systems while simultaneously being expected to build new ones.
Equally, there can be genuine performance problems.
The team may lack important skills. Development practices may be weak. Quality may be poor. Estimates may have little connection to reality. A supplier may not be providing the capability the business expected.
The point is not to defend the development team or blame management.
It is to establish what is actually happening.
Only then can you decide what needs to change.
What to Do When Your Development Team Isn’t Delivering
Putting more pressure on the team is rarely the best first move.
Instead, establish a clearer picture of how work moves from an idea or business requirement through development, testing and into production.
Start with some practical questions.
What is currently being worked on?
Find out how many pieces of work are genuinely in progress.
If the team has dozens of partially completed items, reducing work in progress may improve delivery without adding anybody.
Are the priorities actually clear?
Ask different members of the team what the three most important priorities are.
If you receive very different answers, you may have found part of the problem.
What has actually been delivered?
Look beyond status reports and percentages.
What working software has been completed, tested and released?
Where does work get stuck?
Look for recurring bottlenecks.
These might involve requirements, technical decisions, code reviews, testing, deployments, external suppliers or business approvals.
How much time is spent on rework?
A team can appear productive while spending a substantial proportion of its time fixing defects or rebuilding functionality.
Understanding rework can reveal quality, requirements or technical problems.
What interrupts planned work?
Production incidents, customer support, urgent management requests and unplanned technical problems can consume significant capacity.
That work may not appear in the original development plan.
Who makes decisions?
Important questions should not sit unresolved for weeks.
Clarify who can make decisions about scope, priorities, product requirements and technical direction.
These questions help establish whether you have a people problem, a process problem, a technology problem, a leadership problem or some combination of them.
Will Adding More Developers Fix the Problem?
Sometimes.
If the team is working effectively and genuinely lacks capacity, additional developers may help.
But adding developers to a struggling team can initially slow delivery.
New people need to understand the software, business domain, architecture and development practices. Existing developers need to spend time helping them.
More developers can also create more communication, coordination and code-review work.
If the underlying problem is technical debt, unclear requirements, weak leadership or constantly changing priorities, additional developers do not remove those constraints.
Establish the cause before deciding that headcount is the answer.
Should You Replace the Development Team?
Replacing an internal team or changing software suppliers is a significant decision.
Sometimes it is justified.
But doing it before understanding the underlying problems carries a considerable risk. The replacement team may inherit exactly the same architecture, requirements, governance and leadership problems as the previous one.
You could spend months changing suppliers only to discover that delivery has not materially improved.
Before making that decision, understand:
- What is preventing delivery today
- What is working well
- Where the genuine capability gaps are
- What technical knowledge sits within the existing team
- What risks would be created by changing the team
- What needs to change regardless of who develops the software
An independent assessment can be particularly valuable before making a decision of this size.
How I Help Improve Software Delivery
When leadership has lost confidence in software delivery, I provide an independent view of what is happening and why.
I am not there to assess individual developers or find someone to blame.
The aim is to understand the development environment as a whole, identify what is preventing effective delivery and establish practical priorities for improvement.
Depending on the situation, I can review:
- Development workflow and delivery practices
- Requirements and priorities
- Software architecture and technical debt
- Testing and quality practices
- Team structure and responsibilities
- Skills and capacity
- Technical leadership
- Dependencies and bottlenecks
- Communication between technology and the business
- Supplier or outsourced development arrangements
- Delivery metrics and reporting
- Governance and decision-making
The outcome should give leadership a much clearer understanding of what is actually preventing delivery, what needs attention first and what realistic improvement looks like.
For broader delivery support, see Project Delivery.
Where the problem centres on leadership, accountability or technical direction, Technology Leadership may also be relevant.
When a Software Development Review Makes Sense
If you cannot confidently determine why delivery is struggling, a Software Development Review can provide a structured independent assessment.
It can be particularly useful when:
- Delivery has been deteriorating over time
- Estimates consistently prove unreliable
- Bugs and rework are increasing
- Management and developers disagree about the causes
- You are considering expanding or restructuring the team
- You are considering changing development suppliers
- You need to understand technical debt or architecture risk
- Significant additional investment is being requested
The purpose is not simply to produce a technical report.
It is to give leadership enough evidence to make informed decisions about the team, technology and future investment.
What Does Better Software Delivery Look Like?
Improvement does not mean forcing developers to work faster.
A healthier development environment usually becomes more predictable.
Priorities are clearer. Less work is started simultaneously. Problems are identified earlier. Releases become less stressful. Estimates become more useful. Developers and business leaders have a shared understanding of what is being built and why.
Most importantly, more work gets finished.
You may not eliminate uncertainty from software development. That is unrealistic.
But leadership should have enough visibility and confidence to understand what is being delivered, what is getting in the way and what decisions need to be made.
When the Problem Is Bigger Than the Development Team
Sometimes concerns about development performance reveal a broader business problem.
A project may be running significantly behind schedule. If so, see Software Project Running Late.
Development expenditure may be increasing without corresponding progress. See Software Costs Out of Control.
A critical system may depend heavily on one developer. See Too Dependent on One Developer.
Or the underlying issue may be a lack of technology direction, accountability and leadership. See Technology Leadership Problems.
These problems frequently overlap.
Identifying the underlying cause helps you address the right problem rather than simply treating the most visible symptom.
Get Clarity Before Making Major Changes
When software delivery is disappointing, it can be tempting to demand faster delivery, hire more developers or replace the existing team.
Those decisions may eventually be appropriate.
But first, establish why the team is struggling.
I work with Australian founders, business owners and leadership teams that need an experienced, independent view of their software development environment.
The objective is simple. Understand what is happening, identify what is getting in the way and determine what needs to change.