How I Turned ‘That’s Not My Job’ into ‘Let’s Get It Done Together’
5 step-by-step facilitation strategies, and tools to move your team from “that’s not my job” to “we own this together!"
It was Sprint 4 of a new product release.
Velocity looked stable. Jira looked clean. But something felt off.
Every stand-up sounded like a departmental update:
“I’m done with my backend tasks.”
“I’ll pick up frontend once Dev hands it over.”
“QA will start testing tomorrow.”
By the end of the Sprint — half the stories were half done.
In the Retrospective, I asked, “What stopped us from finishing stories end-to-end?”
A senior dev said, “We were hired for our specialisations. Why should I test or write UI code?”
That’s when I realised:
The issue wasn’t skills — it was identity.
They weren’t being difficult; they were protecting their expertise.
So instead of lecturing about “T-shaped skills,” I used these five strategies to coach collaboration without resistance.
5 Strategic Moves to Break Skill Silos
Strategy 1: Visualise the Skill Silos
Purpose:
You can’t coach what you can’t see. Most silos are invisible until you make them visible.
Action Steps:
In your next Retro or Team Reset, open a Miro/Mural board or a whiteboard.
Create a Skill Matrix Grid —
Rows = Team Members, Columns = Key Skills (Frontend, Backend, Testing, DevOps, UX, Domain Knowledge).Ask each member to fill 3 colours:
🟩 “I can do this independently.”
🟨 “I can contribute with help.”
🟥 “I’ve never done this, but I’d like to learn.”
When complete, zoom out and ask:
“What patterns do we see?”
Circle the over-reliant columns (e.g., only one QA or DevOps expert).
Ask reflective questions:
“What happens if this person is on leave?”
“Where are our opportunities to learn from each other?”
Challenge:
Expect initial resistance: “This looks like a skill audit. Are we being judged?”
How I Overcame:
I clarified right upfront:
“This isn’t for HR. It’s for us. We’re mapping risk, not rating people.”
When people realised the intent, they became curious.
Later, the team even started maintaining their own skill map in Confluence!
Strategy 2: Start Pairing, Not Forcing
Purpose:
You can’t mandate collaboration. You can only create conditions where it happens naturally.
Action Steps:
Choose one story in the next Sprint that needs both frontend and backend input.
Announce:
“Let’s experiment — two of you pair up for this one, one leads, one observes.”
Make pairing optional for the first 2 sprints.
Encourage people to rotate pairs every sprint — backend+QA, QA+DevOps, etc.
During the Retro, ask:
“What surprised you while pairing?”
Log insights under two categories — gains and frictions.
Challenge:
People often say, “Pairing takes twice the time.”
How I Overcame:
I acknowledged it:
“Yes, the first two sprints are slower. But rework drops after that.”
Then I measured rework rates before and after pairing.
Result:
🔹 3 sprints → rework dropped from 20% to 5%.
🔹 Code review turnaround time reduced by half.
When I showed that chart in the Review, leadership immediately supported continued pairing.
Strategy 3: Redefine “Done” to Require Collaboration
Purpose:
A Definition of Done (DoD) that ignores integration is just a checklist for silos.
Action Steps:
Bring your DoD into the next Retro or Sprint Planning.
Ask: “Which steps in our DoD depend on another role?”
Identify where collaboration must occur — e.g.:
Backend → QA validation
Frontend → API integration
QA → environment setup by DevOps
Add these statements to DoD:
“Work is not Done until it’s tested end-to-end.”
“Feature branches must be integrated into the main line before Sprint close.”
Create a “Done Checklist” inside Jira (as subtasks or custom fields).
Review it in each Retro to reinforce habit.
Challenge:
Pushback like — “Now it’ll take longer to close stories.”
How I Overcame:
I pulled data:
“Last Sprint, we closed 10 stories. 4 reopened in QA. That’s 40% rework.”
Then asked,
“Would you rather appear fast or actually be done?”
That one question changed everything.
Strategy 4: Introduce Skill Swarming Fridays
Purpose:
Build empathy and shared knowledge through joint problem-solving — not lectures.
Action Steps:
Pick one small but real problem (production bug, small UX fix, or low-priority backlog item).
Announce a “Swarming Hour” on Fridays — 4 PM to 5 PM.
Everyone (backend, frontend, QA, design) joins the same Zoom/room.
The rule: no handoffs. Everyone works together until done.
End with a 10-min “Learning Round.” Ask:
“What did you learn about another person’s work today?”
Document those insights on a shared Mural board titled “Friday Learnings.”
Challenge:
First 2 weeks feel messy. Too many voices, unclear ownership.
How I Overcame:
I used visual facilitation.
I drew 3 columns on a whiteboard:
🟩 What Helped Us
🟨 What Confused Us
🟥 What We’ll Try Next
We iterated the swarming format just like a product — by inspection and adaptation.
By week 4, people started volunteering to pair across roles.
Metrics:
✔️ Cross-role collaboration mentions in Retro: +300%
✔️ Cycle time reduced by 1.5 days
Strategy 5: Reward Collaboration, Not Just Completion
Purpose:
What gets celebrated, gets repeated.
Action Steps:
In every Retro, open a section titled “Shoutouts for Collaboration.”
Ask:
“Who helped you outside their usual role this Sprint?”
Capture each mention on sticky notes.
Create a “Collaboration Wall” — physical or virtual.
Share one or two shoutouts in the next Sprint Review (in front of leadership).
Once a month, pick a “Collaboration Champion” — not for delivering the most, but for helping the most.
Challenge:
Initially, awkward silence. People hesitate to self-promote or praise.
How I Overcame:
I led by example:
“I want to thank Richa, our tester, for helping with backend data — that saved us one day.”
The next Sprint, others followed.
Now, “helping outside your role” is a point of pride, not a risk.
Try This Tomorrow
In your next Daily Scrum, add one question at the end:
“Who can help someone today — even outside your task?”
Do this for a week — and you’ll feel the tone shift from “my update” to “our Sprint.”
When developers stop saying,
“That’s not my task,”
and start asking,
“What helps our Sprint Goal?”
That’s when teamwork stops being a buzzword — and becomes a habit.
Turn “That’s Not My Job” Into True Team Ownership — Practice It Live!
If you want to experience how to coach teams beyond silos and build real cross-functional collaboration, join my next Scrum Career Accelerator – Community of Practice.
We don’t just talk about teamwork — we simulate real Sprint scenarios where developers resist, testers push back, and ownership is on the line.
You’ll learn exactly how to facilitate these conversations with calm, confidence, and clarity.
🚀 Join us this Saturday. Practice real scenarios, get coached live, and build the confidence to lead your next refinement like a pro.
Master Every Interview Question on Cross-Functional Teams!
Ever been asked in an interview:
“How do you handle developers who say — ‘That’s not my job’?”
Or worse —
“How do you coach a team that’s too siloed to collaborate?”
Most candidates give safe textbook answers like, “I promote teamwork and cross-skilling.”
But when the interviewer digs deeper — “Tell me how you did that in real life?” — they freeze.
Not because they don’t know Agile, but because they’ve never lived through that tough moment where ownership stops at skill boundaries.
That’s exactly why I’ve created a Practical Interview Question Set on Cross-Functional Coaching & Collaboration — based on real scenarios I’ve coached through in teams that went from siloed to self-organising.
Inside this guide, you’ll find:
✅ 10 real interview questions on managing specialisation walls and promoting team ownership
✅ Story-style answers with real facilitation scripts, data, and emotional intelligence
This isn’t theory — it’s drawn from live coaching sessions, sprint conflicts, and transformations that actually worked.
If you’re preparing for Scrum Master, Agile Coach, or Product Owner roles, this is your go-to interview prep toolkit.
📥 Download your free Cross-Functional Coaching Q&A Set here →
Start preparing like professionals who’ve actually coached collaboration in real teams — not just talked about it in slides.
📚 From My Shelf
📘 This Week’s Book: How to Sell Your Way Through Life by Napoleon Hill
(A timeless read about influence, integrity, and self-belief.)
Napoleon Hill doesn’t talk about sales tactics.
He talks about trust, service, and the power of a definite purpose.
The kind of mindset that turns persuasion into partnership and ambition into achievement.
What influenced me most?
“The best way to sell yourself to others is first to sell the idea to yourself.”
For any Scrum Master or Product Owner who’s constantly “selling” ideas, change, and vision—this book is a masterclass in authentic influence, not manipulation.
Why Subscribe
Each week, I share battle-tested strategies, messy lessons, and practical tools that help Scrum Masters, Product Owners, and change agents like you make sense of chaos — without sugar-coating it.
If you found this useful, subscribe.
This isn’t theory. It’s real work, made a little easier — one step at a time.
“Just because I understand it, does not mean everyone understands it. And just because I do not understand it, does not mean no one understands it.”
Anand Pandey
Thanks for reading Strategy For Success! Subscribe for free to receive new posts and support my work.