01
Starting point
A product and delivery team was working in an agile setup. There were occasional disagreements between business and development, but these were rare, professional and usually resolved quickly.
Case study · Human behavior
When collaboration breaks down
A short anonymised case study about how leadership behaviour, information bottlenecks and weakened feedback loops can damage delivery even when the team itself has the knowledge to solve the work.
In short
The problem was not one conflict. It was a pattern that changed how the team worked.
Before the change there had only been occasional, manageable professional friction. After the new leadership behaviour appeared, information, decisions and communication increasingly started to concentrate around one person.
02
What changed
A new lead entered the setup without practical PO / BA or agile delivery experience, but with a strong hierarchical leadership style and a need to centralise communication.
03
Delivery impact
User stories became weaker, meetings became more conflict-heavy, knowledge stopped flowing naturally, and sprint capacity was repeatedly spent on corrections instead of new value.
Context
An agile team needs more than roles on paper.
The situation started in a team where business, testing, analysis and product responsibilities were closely connected to development. The previous operation was not perfect, but it had enough trust and routine for professional disagreements to be discussed and resolved.
The change was not caused by a single bad meeting. It came from a repeated pattern: decisions were pulled into one channel, information was not shared back with the full team, and professional feedback was increasingly treated as personal opposition.
In software development, knowledge must move through the team. If one person tries to become the only gate, delivery quality starts to suffer.
Diagnosis
Three areas where the collaboration broke down.
The case is less about personality and more about how a leadership pattern can damage delivery when it blocks feedback, transparency and shared ownership.
Information flow
Communication that had previously been shared with the relevant roles started to narrow. Questions and answers increasingly went through one person, while the rest of the business side lost context.
Broken workflow
- emails and questions were often handled by one person instead of the full relevant group;
- answers were collected from others but sent back without sharing the knowledge trail;
- business-side roles were left out of conversations that affected their own work;
- knowledge became concentrated instead of distributed.
Why this was a problem
- the team no longer worked from the same information base;
- decisions were harder to understand or challenge;
- people lost visibility of context they needed for analysis, testing and product decisions;
- the setup made one person look indispensable while weakening the rest of the team.
Recommendation
- define communication rules for who must be included in which topics;
- document decisions in a shared place instead of private channels;
- make it clear when a response is individual and when it represents the team;
- avoid single-person knowledge gates for product and delivery information.
Meetings and team dynamics
Agile ceremonies were meant to support transparency and learning, but they increasingly became places where professional disagreement turned personal.
Broken workflow
- standups, refinements and retrospectives could turn into personal arguments;
- the business side was not consistently represented or protected by its own lead;
- feedback was often received as criticism instead of input to improve delivery;
- team members started to invest energy in defence instead of problem solving.
Why this was a problem
- psychological safety decreased;
- the team had less room to ask questions or challenge weak assumptions;
- conflicts became repetitive instead of being resolved at the process level;
- meetings became less effective and more emotionally costly.
Recommendation
- bring in a neutral external facilitator or agile / delivery coach;
- set explicit working agreements for ceremonies;
- separate professional feedback from personal judgement;
- review conflict patterns, not only individual incidents.
User stories and backlog quality
The leadership issue also became visible in the backlog. Stories were written without enough learning, review or shared clarification.
Broken workflow
- user stories were often incomplete or unclear;
- experienced PO / BA colleagues were not asked early enough for input;
- refinement feedback did not consistently improve future story quality;
- correction work reappeared sprint after sprint.
Why this was a problem
- development capacity was spent on rework instead of new value;
- developers had to implement against unstable or incomplete understanding;
- business stakeholders received slower and less predictable delivery;
- morale suffered because the team repeatedly fixed preventable issues.
Recommendation
- introduce PO onboarding for people new to IT delivery;
- use a shared story review practice and acceptance criteria standard;
- define what makes a story ready for development;
- treat feedback as part of quality assurance, not as a personal attack.
Impact
The team did not lose capability. It lost a healthy operating space.
The issue was not that people were unwilling to work. The problem was that information and decision-making were pulled away from the shared team space. That made delivery slower, less predictable and more emotionally exhausting.
1
Knowledge bottleneck
Too many questions and answers started to flow through one person.
↓
Story quality
Incomplete stories created repeated clarification and rework.
↑
Meeting tension
Professional disagreements became more personal and harder to resolve.
lost
Focus
Energy moved from delivery to conflict handling and correction work.
Lesson learned
Software development is not built around a single opinion.
A leader can be useful in software delivery, but not by becoming the only source of truth. Development quality comes from different roles seeing the same problem from different angles: business, analysis, product, development and testing.
Agile collaboration does not fail because leadership exists. It fails when leadership stops facilitating professional dialogue and starts owning information, decisions and visibility alone.