Every company is different, but problems in software development follow surprisingly similar patterns. Read through the situations below — if you recognize yours, you know where to start.
Technical Quality and Delivery Speed
Every code change feels risky
Developers are afraid to touch certain parts of the product. Nobody knows exactly what will break. Deploying a new release is stressful, not routine. Tests either don’t exist or nobody trusts them.
Development is getting slower even though the team is growing
You’re adding people, but output isn’t increasing proportionally. New developers need weeks to get oriented. Every new feature breaks the previous one.
You’re using AI tools, but the team as a whole hasn’t sped up
Individuals write code faster with Copilot or Cursor, but code reviews take longer, technical debt is accumulating, and overall delivery speed hasn’t improved.
Code review is a bottleneck
Pull requests wait days for review. Knowledge stays with one person. Developers work in isolation and duplicate each other’s work unnecessarily.
Developers spend hours debugging and chasing bugs
Bugs aren’t caught early — they surface after deployment, or in production. Every bugfix introduces new bugs. The team spends more time fixing than building.
Deploying to production is stressful and partly manual
Builds and deployments rely on manual steps or fragile scripts. Every release requires the presence of a specific person. Continuous delivery feels far away.
Nobody in the company fully understands the system architecture
Technical decisions are hard because nobody has the full picture. New features get added without clarity on where they belong. Architecture has grown on its own.
Manual testing can’t keep up
The QAs can’t test everything being developed. Regression testing is slow and error-prone. Test automation was started but never reached a usable state.
Relevant services: Technical Coaching · TDD Training
Overload and Predictability
The team is constantly overwhelmed
Developers work overtime but the backlog doesn’t shrink. Every sprint is firefighting. Technical debt grows because there’s no time to address it. Nobody dares to say “no” to another request.
Deadlines keep slipping and nobody knows why
Estimates are consistently missed. Business is waiting for features that were supposed to be done three sprints ago. The team has no capacity for long-term planning because they’re stuck in operations.
One person knows too much
Certain problems can only be solved by one specialist. Everyone else waits for them. You’re afraid of what would happen if they left.
Business and development are pulling in opposite directions
Requirements arrive without context. Developers don’t know why they’re building what they’re building. Business doesn’t see the results of work for weeks or months. Feedback arrives too late.
Features are misunderstood or poorly specified
Developers deliver exactly what was written — but not what the business needed. Misunderstandings surface late, during testing or after deployment.
Relevant services: Relief from Overload · Specification by Example
Multi-Team Collaboration
Teams are waiting on each other
No single team can deliver a complete feature on its own — they always need something from another team. Dependencies pile up. Every release requires coordinating dozens of people.
You’re doing Scrum but it’s not working
Sprints happen, retrospectives are held, but nothing changes. Daily standup is a status report to the manager. Sprint review is theatre. Definition of Done exists on paper but not in practice.
You’ve added more process but things haven’t improved
You’ve introduced more roles, more meetings, more documentation. Coordination overhead grows faster than output. People spend more time reporting than developing.
You have component teams instead of feature teams
Team A does frontend, team B backend, team C database. No simple feature can be built without involving all three. Everyone is busy but nothing is delivered end-to-end.
You want to better understand Scrum or LeSS
You’re introducing Scrum for the first time, or you suspect you’re doing it wrong but aren’t sure where. Or you’re working across multiple teams and need a deeper understanding of how LeSS works in practice.
Relevant services: Simplifying Development Organisation · Certified LeSS Practitioner · Certified LeSS Basics
Decisions at the Top
You have nobody to think through important decisions with
You’re a director, CTO, or technical leader. The decisions you make have major impact — and few people in the company share your perspective. There isn’t a second CTO in the company. Experience from past companies only goes so far.
You’re planning a change and aren’t sure if you’re on the right path
You’re preparing an organisational change, technology decision, or strategic shift. You want feedback from someone who has seen similar situations elsewhere — before you start implementing.
As an executive, you want to better understand organisational design
You’re considering a larger reorganisation of your development teams, or LeSS has come up in your company. You want to understand the principles and implications before committing to a direction.
Relevant services: Sparring Partner · Certified LeSS for Executives
Don’t see your situation here?
Development problems come in many forms and don’t always match one of the patterns above. If you’re not sure where to start, or want to discuss your situation, get in touch.