DEV Community: Kelly Lewandowski

Your Agile Ceremonies Weren't Designed for 10 Time Zones

Kelly Lewandowski — Tue, 10 Mar 2026 20:01:39 +0000

The Scrum Guide doesn't mention time zones. It was written for teams that could stand in a circle every morning, hash out sprint scope over a whiteboard, and grab coffee together between meetings.

That's not most teams anymore. If your engineers sit in New York, Berlin, and Bangalore, you're dealing with a 10.5-hour spread. Sprint planning at 9am Eastern is 7:30pm in India. Your "quick retro" at 4pm Berlin time hits Bangalore at 8:30pm.

The usual fix is rotating who gets the bad meeting time. That's fair, but it still treats every ceremony as a synchronous event. And that's the actual problem.

Not every ceremony needs a meeting

This is the question most teams skip: which ceremonies actually require everyone talking at the same time?

Ceremony	Needs sync?	Why
Daily standup	No	Written updates are faster to consume and don't require timezone coordination
Sprint planning	Partially	Scope negotiation needs real-time discussion, but context-sharing doesn't
Sprint review	Yes	Live stakeholder feedback is the whole point
Retrospective	Yes	Honest team conversations about dynamics need tone of voice and real-time energy
Backlog refinement	Hybrid	Async pre-read, sync for questions and estimation

The daily standup is the easiest ceremony to move async, and it frees up your overlap window for the ceremonies that actually benefit from live discussion.

The overlap window

Map out when your team members are all within working hours. For most globally distributed teams, this is 2-4 hours. Some get less.

For that NYC/Berlin/Bangalore spread, the overlap is roughly 14:00-16:00 UTC. Two hours. That's it.

Those two hours are sacred. One meeting per day, max. Everything else happens async. If you're burning your overlap window on status updates, you won't have time left for sprint planning or retros, which are the ceremonies that actually suffer without real-time discussion.

A small trick that helps: ask people to flex 30-60 minutes in either direction. A Berlin dev starting at 10am and a Bangalore dev staying until 7:30pm buys you an extra hour. Rotate who flexes so nobody's always the one adjusting.

Sprint planning without the 2-hour meeting

The async-prep-sync-decision pattern cuts planning meetings in half:

48 hours before: PO shares candidate backlog items with acceptance criteria and context. Team reads and posts questions async.
24 hours before: Team runs async estimation (planning poker works well here — everyone votes independently and you can spot disagreements before the call).
During overlap: Live session focuses only on resolving disagreements and committing to the sprint goal. 45-60 minutes instead of 2 hours.

The information transfer happens async. The negotiation happens sync. You stop wasting synchronous time on things people could have read on their own.

Why retros need to stay synchronous

I'd argue retros are the ceremony you should fight hardest to keep live. The candid, sometimes uncomfortable conversations about how the team works don't land the same way in a shared doc. Text strips out tone. Written responses feel less safe than spoken ones.

That said, you can make the sync portion shorter:

Have people add retro items to the board before the meeting. This gives everyone, especially those in less convenient time zones, equal chance to contribute.
Keep it to 60 minutes. Distributed retros lose energy faster than in-person ones.
Use anonymous voting. Power dynamics get amplified on screen.

Distributed teams need retros more than co-located ones. Miscommunication and unclear handoffs pile up silently when there are no hallway conversations to catch them. The retro is where that stuff surfaces. Skip it and the problems just compound.

The sample week

Here's what it looks like in practice with a 2-hour overlap (14:00-16:00 UTC):

Day	Overlap window	Async
Monday	Sprint planning (60 min)	Standup updates, planning pre-read
Tuesday	Open for ad-hoc sync	Standup updates, refinement pre-read
Wednesday	Refinement (45 min)	Standup updates, estimation
Thursday	Open for ad-hoc sync	Standup updates
Friday	Retro or review (60 min)	Standup updates, retro board input

One meeting per day in the overlap window. The rest of the time, people build things.

What usually goes wrong

Defaulting to HQ time. If leadership is in New York and every meeting happens during East Coast hours, your other offices are permanently accommodating. People notice and stop engaging.

Skipping documentation. Co-located teams have hallway conversations. Distributed teams don't. If you didn't write it down, it didn't happen for anyone who wasn't on the call.

Adding more meetings to compensate. The instinct when async communication feels lacking is to schedule more syncs. This makes it worse. Fix the async communication instead.

I wrote a longer version of this with concrete team agreements, sprint review strategies for multiple timezone clusters, and a deeper breakdown of the async-first approach. You can read the full post on the Kollabe blog.

If your team is already doing async standups or hybrid planning, I'd love to hear what's working. Drop a comment.

Your team ships faster with AI. Here's why you need retros more than ever 🤖

Kelly Lewandowski — Sun, 01 Mar 2026 19:27:13 +0000

70% of developers say AI coding tools make them more productive. Only 17% say those tools improve team collaboration.

That stat from Stack Overflow's 2025 survey stuck with me. We're all shipping faster individually, but nobody's talking about the team-level side effects.

The numbers that should make you uncomfortable

A few data points that changed how I think about this:

METR study: Experienced devs using AI tools took 19% longer to complete tasks, while believing they were 20% faster. A 40-point perception gap.
DORA 2024: A 25% increase in AI usage correlates with a 7.2% decrease in delivery stability.
GitClear: Code churn jumped from 3.1% to 7.9% between 2020-2024. Refactoring dropped from 25% to under 10%.

More code is shipping. Whether it's the right code is a different question.

The collaboration problem nobody's fixing

A two-year longitudinal study found that AI adoption shifts work toward individualized coding tasks and away from collaborative coordination. The collaboration problems that existed before AI (silos, communication gaps, unclear ownership) stayed completely unresolved.

AI is making individuals faster. It is not making teams better.

Where retros come in

When your team spends 90% of the sprint heads-down with an AI pair programmer, the 60 minutes in a retro might be the most important hour in the entire sprint.

The questions need updating though. For AI-assisted teams, these are the ones that matter:

AI tool effectiveness - Where did AI help? Where did it waste your time?
Knowledge distribution - Who actually understands the code that shipped?
Customer connection - Did shipping faster translate into customer value?
Code quality signals - Is churn going up? Are PRs getting rubber-stamped?
Team norms - What are your unspoken rules about AI usage?

The DORA quote that sums it up

"AI makes good teams great. And bad teams worse, faster."
-- Google DORA 2025 Report

The practices that separate good teams from bad ones (psychological safety, shared understanding, honest feedback) are exactly what retros are built around. As AI handles more of the mechanical work, the human conversations get rarer. And rarer means more valuable.

I wrote a longer piece diving into the research and practical retro questions for AI-assisted teams: Read the full post on Kollabe

User Personas That Developers Actually Care About ⛄️

Kelly Lewandowski — Wed, 25 Feb 2026 18:27:48 +0000

Most user personas end up in a slide deck that nobody opens after sprint two. They read like a casting call for a fictional character, packed with hobbies and favorite coffee orders but missing anything that would change how your team builds software.

I've been thinking about why that is, and I think the problem is that most personas are written for product managers and designers, not for the full team. Developers never see them, so they never use them. And a persona nobody uses is just creative writing.

Here's what actually works.

Keep it to one page

A persona that fits on a single page gets used. One that requires scrolling gets ignored. Here's what belongs:

Section	What to include
Demographics	Name, job title, company size, location
Goals	3-5 professional goals related to your product
Pain points	Current frustrations and blockers
Behavioral patterns	How they work, buy, and make decisions
Technical context	Devices, tools, comfort level with tech

What to leave out: favorite color, what they eat for breakfast, detailed personal backstories. If a data point wouldn't change a product decision, it doesn't belong.

A quick example

Here's a persona for a B2B project management tool:

Sarah Chen, Senior Engineering Manager, Series B SaaS company (120 people)

Goals: Ship features predictably, reduce meeting overhead, give leadership visibility into sprint progress without daily check-ins.

Pain points: Current tools don't surface blockers early enough. Sprint retros feel repetitive. Estimations are inconsistent across sub-teams.

Behavioral patterns: Prefers async communication. Reviews dashboards every morning before standup. Evaluates new tools by trying the free tier herself before involving procurement.

"I don't need another dashboard. I need my team to spend less time talking about work and more time doing it."

Every detail here connects to a product decision. Sarah's preference for async work means your product needs strong notifications and reporting. Her evaluation behavior tells you the free tier has to be self-serve and compelling.

Where personas actually get used

A persona that doesn't show up in daily work is just a character sketch. Here's where they actually get used:

During backlog refinement, ask "Which persona does this serve?" If the answer is "all of them," the story is probably too broad. If the answer is "none of them," it might not belong in the backlog.

When writing user stories, replace "As a user" with the persona's name. "As Sarah, a remote engineering manager, I want to see sprint progress without attending standup" is immediately clearer and easier to estimate.

In sprint planning, if your primary persona's top pain point isn't addressed in the upcoming sprint, that's worth flagging.

And in retros, try asking "Are we building for our personas, or have we drifted?" Two-minute gut check, surprisingly useful.

How many do you need?

Three to four. More than that and your team can't keep them straight. Fewer than two and you're probably treating a diverse user base as a monolith.

Cover these types:

Primary user - the person who uses your product daily
Buyer - the person who makes the purchase decision (often different in B2B)
Influencer - someone who recommends or blocks adoption

You might also create a detractor persona to understand who your product is not for. Knowing who to say no to is just as useful as knowing who to say yes to.

Don't wait for perfect research

Start with provisional personas based on what you know today. Pull from support tickets, sales call notes, analytics. Five to eight user interviews per segment is enough to spot patterns.

A rough persona that the team actually references beats a polished one that nobody reads. You can always refine later.

The 5-minute version

If you want to get a structured persona fast, I built a free AI User Persona Generator that creates one from a product description in seconds. It's not a replacement for real research, but it gives you something concrete to react to instead of starting from a blank page.

I wrote a more detailed version of this guide with step-by-step instructions and more examples on our blog: How to Create User Personas That Actually Improve Your Product

If your team uses planning poker or retrospectives, you might also find these useful: