7 signs your dev team is behind (and you're the last to know)

A pilot customer asks when they can start. Or an investor asks whether the launch date still holds. You give the date. Later, you realize the only source for that answer is your vendor's last weekly update.

That update said "on track." So did the one before it. The launch date has still moved at least once, and you cannot tell whether the uneasy feeling is instinct or nerves.

You can check without reading the code. Below are 7 software development red flags, each with a question to send your team this week and a benchmark for what healthy looks like. At the end, you will find a self-check table and a 2-week plan for when 3 or more signs show up.

Why the person paying for the project is often the last to know

Bad news travels up slowly on software projects, including well-run ones. Researchers have tracked this for more than 20 years:

• Status reports lean optimistic. In a survey of 56 experienced software project managers, reports were biased 60% of the time, and the bias was twice as likely to be optimistic as pessimistic. Only 10 to 15% of the biased reports proved accurate (Snow, Keil, and Wallace, 2007).
• People keep quiet about problems. Researchers call this the mum effect: team members hold back bad news when they think it reflects on them, or when they expect it to change nothing (Smith, Keil, and Depledge, 2001).
• Bad news that does arrive often gets ignored. "Executives often ignore bad news if they receive it" is one of 5 truths about status reporting in Keil and colleagues' 2014 MIT Sloan Management Review article.

Outsourced development widens the gap. Your vendor has a commercial reason to keep the account calm, and you have fewer ways to check what you hear.

Every extra person between the developer and you adds a filter:

1. The developer tells the team lead a feature "mostly works."
2. The team lead tells the account manager it is "on track, minor risks."
3. The account manager tells you it is "on track."

No one lied. Each person rounded up a little.

Frederick Brooks described the result in The Mythical Man-Month (1975): "How does a project get to be a year late? One day at a time." Each small slip is easy to defend, so the slips add up unnoticed.

For you, this means status reports are the least reliable information you have. The 7 signs below are things you can check yourself.

7 signs your dev team is behind

A good team having a rough month can show the same early signs as a bad development team. So treat each sign as a reason to ask a question, and hold your conclusions until you see the answer.

1. Every status update is green, and has been for weeks

What it looks like. Your weekly report says "on track," same as the last 5. Nothing has ever turned yellow. Yet the launch date moved.

Why it happens. Project managers call this watermelon reporting: green on the outside, red on the inside.

The report tracks activity, like meetings held and tickets closed. The risk sits in work that has not made it onto the report. And if the last yellow week led to a tense call, the team has learned to avoid yellow.

What to ask this week.

"What is the one thing most likely to make us miss the next milestone?"

A team on top of its work answers in 1 sentence. A vague answer, or "nothing, we're on track," is the signal.

What healthy looks like. A useful weekly update covers:

• Progress, listed as done and not done items
• Risks and blockers, filled in even on good weeks
• Decisions needed from you, each with a deadline

A status that turns yellow now and then is a good sign. A project that has gone months without one is rarely reported accurately.

2. "Almost done" has been almost done for 3 sprints

What it looks like. A feature has sat at "about 90%" for weeks. Each update nudges the number up a point, and it never reaches 100.

Why it happens. Tom Cargill of Bell Labs described this in a line Jon Bentley made famous in 1985:

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

Percent-complete is a guess. The slowest work sits in that last 10%:

• connecting the feature to the rest of the product
• handling edge cases, like a failed payment or an expired login
• testing, and fixing what testing finds

A sprint is a fixed work cycle, usually 2 weeks. So 3 sprints at "90%" means about 6 weeks of work no one has listed.

What to ask this week.

"What exactly is left, as a list, and which items have you not started?"

What healthy looks like. Work is tracked as done or not done against a written definition of done. That is a short checklist every feature passes before anyone calls it finished, for example:

• code reviewed by a second developer
• automated tests written and passing
• deployed to staging, where you can try it

Once the checklist exists, percentages drop out of your updates.

3. You have not clicked through working software in weeks

What it looks like. Demos arrive as slides or screen recordings, or get pushed to "next sprint." You have seen plenty of pictures of your product and have not used it yourself.

Why it happens. Unfinished work is hard to show live. A screenshot can show a design that was never built. A recording can skip the screen that crashes.

That makes this the most reliable sign on the list, because working software is the hardest thing to fake. What to ask this week.

"Can you send me a link to the staging environment so I can try it myself?"

A staging environment is a private copy of your product where the team tests new work before release. If your team does not have one, ask why.

What healthy looks like.

• You have a staging link you can open any time.
• At the end of every sprint (usually every 2 weeks), the team runs a sprint demo: a live walkthrough of working software, where you can ask them to click anything.
• When you try it yourself, you follow the path a real customer would take: sign up, enter something wrong, go back, open it on your phone.

For reference, DORA's 2024 Accelerate State of DevOps report groups high-performing teams as releasing between daily and weekly. You do not need that pace. You do need something you can open every sprint.

4. Estimates only move in one direction, and no one explains why

What it looks like. Each re-estimate adds 2 weeks, and none comes in shorter. When you ask why, you hear "it took longer than expected."

Why it happens. Some overrun is normal. McKinsey and the University of Oxford studied more than 5,400 IT projects. Large ones (initial budgets over $15 million) ran 45% over budget and 7% over time on average, and software projects carried the highest risk of overruns.

So a software project behind schedule is common. Watch for a slip with no named cause. It usually means the team does not know the cause, or does not want to say.

When the team does dig in, the cause is usually one of these:

• new requests added along the way (scope creep)
• requirements that meant one thing to you and another to the team
• a payment provider, CRM, or older system that was harder to connect than planned

What to ask this week.

"What did we learn that changed the estimate?"

What healthy looks like. Every slip comes with a reason and a decision for you to make:

• cut scope and keep the date
• keep the scope and move the date
• add budget for more people, keeping in mind Brooks's warning that "adding manpower to a late software project makes it later"

5. Fixed bugs come back, and new features break old ones

What it looks like. You report a bug. It gets fixed. Two releases later, it is back.

Or a new feature breaks something that worked last month.

Why it happens. Usually, missing automated tests and rushed code. Automated tests are small programs that check the product still works after every change. Without them, each release is a gamble.

The team then spends more of its week fixing than building. Stripe's 2018 Developer Coefficient survey found developers spend about 17.3 hours a week on maintenance, such as debugging and refactoring. The survey covers developers in general, with no separate figure for outsourced teams.

What to ask this week.

"Do we have automated tests? Roughly what share of the code do they cover, and do they run before every release?"

What healthy looks like.

• Tests run automatically before every release.
• The team gives you a coverage number without a long pause.
• A bug that comes back gets its own test, so it cannot return a third time.

As a benchmark, DORA 2024 puts elite teams' change failure rate (the share of releases that cause a problem in production) at around 5%.

6. Your questions get jargon or silence, and you have started asking fewer

What it looks like. A simple question gets a long technical answer you cannot follow, or no answer until the next call. You have started to feel like the problem, so you ask less.

Why it happens. Jargon is often an unconscious defense. Burying a question in detail is easier than admitting bad news, which is the mum effect again.

The bigger risk sits on your side. Once you stop asking, you depend entirely on what you are told.

What to ask this week.

"Explain it to me as if I had to explain it to an investor tomorrow."

What healthy looks like. A good team explains any decision in 2 or 3 plain sentences and welcomes the question. If you still do not follow, ask 2 more:

• "What does this cost us in time or money?"
• "What happens if we choose the other option?"

7. You cannot see the work itself

What it looks like. You have no access to the code repository, the task board, or the hosting accounts. Everything reaches you as a summary.

Why it happens. Sometimes it is convenience, sometimes control. Either way, everything you know has passed through someone else's filter.

It is also a business continuity risk, and a common offshore development red flag. If the relationship ends, you may not own, or even be able to reach, what you paid for. What to ask this week.

"Please add me to the repo, the task board, and the hosting account as an owner."

What healthy looks like. From day 1, you own or co-own:

• the code repository (for example, on GitHub, GitLab, or Bitbucket)
• the cloud hosting account (AWS, Google Cloud, or Azure)
• the domain and DNS settings
• app store developer accounts, if you have a mobile app
• the task board (Jira, Linear, or Trello)
• a shared password manager for all credentials

You can see commit activity (the log of code changes) without reading any code. If the repo shows no commits for 2 weeks, ask what the team has been working on.

Quick self-check: how many of these software development red flags do you see?

Screenshot this table, or copy the "Ask this" column into a message to your vendor.

How to read your result:

• 1 sign: worth a conversation. Send the question and see what comes back.
• 2 signs in the same month: a pattern. Raise it directly and ask for the changes in the "Healthy answer" column.
• 3 or more: time to act. Start the 2-week plan below.

Behind vs. in trouble: when a delay is normal

Most software projects slip. The Standish Group's CHAOS 2020 data rates only 31% of projects successful, 50% "challenged" (late, over budget, or short on features), and 19% failed.

Researchers have questioned the CHAOS methodology (Eveleens and Verhoef, 2010), so treat those figures as directional.

What tells you more is how the delay reaches you:

A delay you hear about early is manageable. A delay you discover is the real warning.

What to do in the next 2 weeks if you see 3 or more signs

1. Do not fire anyone yet. A new team needs weeks to learn the code. If the root cause was unclear requirements or weak reporting, it follows you to the next vendor.
2. Get access first. Use the list under sign 7. A team with nothing to hide can grant it the same day.
3. Ask for a live demo on staging. Click through it yourself and write down what works and what breaks.
4. Send the 7 questions from the table in writing. Written answers give you a record and leave less room for jargon.
5. Get an independent assessment. Someone outside your vendor reviews the code and the plan, then tells you plainly where you stand.
6. Reset the reporting rhythm. Agree on a sprint demo every cycle, a risks section in every update, and a written definition of done.

For that independent look, you can schedule a team assessment with Sproutly, whether you plan to keep your current team or not.

How Sproutly helps

Sproutly works with startups and small businesses that build software with outsourced teams. Our model has 3 steps: define, assess, and monitor.

We help you define what you are building, assess your current team or find a new one, and monitor progress, so you have evidence to go on besides status reports.

Tow Ninja came to us with a partial MVP from a previous developer, a tight budget, and legal reporting requirements to meet in Harrisonburg, VA. We:

• ran a code review and cleaned up the priority issues
• added unit testing and a CI/CD pipeline, so new code is tested and released automatically
• designed and built the missing MVP features
• held weekly check-ins and helped plan customer onboarding

Tow Ninja launched its pilot, met the city's reporting requirements, and onboarded tow companies, drivers, and vehicle owners. Read how we took over a partial MVP, or browse more client stories.

"We were just kind of walking around in the dark before Sproutly came on board." Jason Wilhelm, Product Manager

You can also meet the team behind Sproutly.

If you recognized 3 or more of these signs, schedule a team assessment. You will get a plain-language read on where your project stands, from people who do not work for your vendor.

References

1. Snow, A. P., Keil, M., and Wallace, L. (2007). "The effects of optimistic and pessimistic biasing on software project status reporting." Information & Management, 44(2). Academia.edu
2. Keil, M., Smith, H. J., Iacovou, C. L., and Thompson, R. L. (2014). "The pitfalls of project status reporting." MIT Sloan Management Review, 55(3). MIT SMR
3. Smith, H. J., Keil, M., and Depledge, G. (2001). "Keeping mum as the project goes under: Toward an explanatory model." Journal of Management Information Systems, 18(2). Taylor & Francis
4. Brooks, F. P., Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
5. Bentley, J. (1985). "Programming pearls: Bumper-sticker computer science." Communications of the ACM, 28(9). Ninety-ninety rule attributed to Tom Cargill, Bell Labs. Wikipedia summary
6. DORA and Google Cloud (2024). Accelerate State of DevOps Report 2024. dora.dev
7. Bloch, M., Blumberg, S., and Laartz, J. (2012). "Delivering large-scale IT projects on time, on budget, and on value." McKinsey & Company, with the University of Oxford. McKinsey
8. Stripe (2018). The Developer Coefficient. Stripe PDF
9. The Standish Group (2020). CHAOS 2020: Beyond Infinity. Summary via OpenCommons
10. Eveleens, J. L., and Verhoef, C. (2010). "The rise and fall of the Chaos report figures." IEEE Software, 27(1).

FAQs

How do I know if my developers are doing a good job if I can't read code?

Check what you can see for yourself: working software on a staging link, fixed bugs that stay fixed, plain answers to plain questions, and owner access to your repository and hosting. Good developers make their work easy to check. If most of what you know comes from status reports, you are relying on the least reliable signal.

Is it normal for a software project to fall behind schedule?

Yes, it is common. The Standish Group's CHAOS 2020 data rates only 31% of projects successful, and McKinsey found large IT projects run 7% over time on average. The red flag is a delay you discover yourself, late, with no explanation. A delay your team flags early, with a reason and options, is manageable.

What is watermelon reporting?

Watermelon reporting is project status that looks green on the outside and is red on the inside: updates say "on track" while problems build underneath. It usually comes from optimistic bias. One study found project managers' status reports were biased 60% of the time, mostly in the optimistic direction. Sign 1 above gives you a question that cuts through it.

Should I have access to my own code repository?

Yes, from day 1, as an owner. Access lets you see commit activity without reading code, and it protects you if the relationship ends. Without it, you may not be able to retrieve the product you paid for. Owner access to the repository, hosting, domain, and credentials is a standard request, and a good vendor will grant it.

How many red flags before I should switch development teams?

Do not switch on signs alone. One sign is worth a conversation, and 2 in the same month are a pattern to raise. At 3 or more, get an independent assessment before deciding anything. Switching mid-build is expensive. If the root cause is unclear requirements or weak reporting, it will follow you to the next team.

Can I get my code reviewed without telling my current developer?

Technically, yes, if you already have access to the repository. In most cases, telling them works better. An assessment goes faster with the team's cooperation, because they can explain decisions the code alone does not show. Framing it as a routine health check, the kind an investor might ask for, also keeps the working relationship intact.