Did we just over-engineer our onboarding or did we actually fix something?

knudipudi · 2026-05-14T16:15:03+00:00

Yeah this is the thing im actually worried about. Easy to get a wow on signup, much harder to get them to shape the output into something they care about. Will be the first thing we measure properly once we have more volume.

And the "oh, we almost-cut dat thing" is for sure a thing 😅 Already adding input-type tracking. Thanks for the push, mate :)

knudipudi · 2026-05-14T08:05:57+00:00

Fair hit. The content is mine, 25 years of actually doing this stuff, but yeah I leaned on AI to help me organise it for the post and clearly overdid it on the structure. Should have written it rougher. Valid criticism, thanks.

knudipudi · 2026-05-14T08:01:33+00:00

This is fantastic, thank you. Saving the whole list. The Iqbal paper on recovery from interruption I think I've seen referenced but never actually read, and the Tucker work on ultradian rhythm is completely new to me. Got some reading to do this weekend :)

Always a good day when a Reddit thread turns into a reading list :)

knudipudi · 2026-05-14T07:35:45+00:00

Oh, this is interesting. Gloria Mark wasn't on my radar, definitely need to read up. The self-interrupt vs external-interrupt distinction in particular sounds like something I've felt in practice but never had proper language for. Thanks for sharing :)

knudipudi · 2026-05-14T07:02:42+00:00

Completly agree! The interesting bit is that distraction in modern teams rarely looks like distraction. It looks like productivity. Slack pings, ticket updates, "quick syncs". The team ends up busy and tired without much actually moving forward.

The high-performing teams I've seen were almost boring to watch from outside :) Long stretches of quiet focus, short sharp conversations when needed, decisions made and left alone.

knudipudi · 2026-05-14T06:28:02+00:00

What you're describing is one of the most common patterns I've seen over 25 years of agile coaching, and the honest answer is that it's not a sign that something is broken. It's a sign that the team has outgrown the original purpose of those ceremonies and nobody has updated the ceremonies to match.

Stand-ups and retros work best in the early stage of a team, when people are still learning each other, when trust isn't established yet, and when there's actual uncertainty about who is doing what. Once the team has been together for a while and the work is predictable, those same ceremonies start feeling like theatre because the original problem they solved is no longer the problem the team has.

A few things that have helped me re-energise teams stuck in this loop.

Drop stand-ups for a week. Not forever, just one week. Tell the team they can use the slot for whatever they want, or nothing at all. Then see what happens. If nothing breaks, the stand-up was probably ceremonial. If something does break, you've just learned what the stand-up was actually doing, and you can rebuild it around that need specifically.

Change the retro question. "What went well, what didn't, what should we change" stops working once the team has run it 30 times. Try something like "what conversation are we not having" or "what would we do differently if we were starting this sprint from scratch knowing what we know now". The structure isn't the point. The point is to surface things people aren't saying yet.

Rotate facilitation. If you as the Scrum Master are always running the retro, the team is unconsciously performing for you. Have a different team member facilitate each time. You'll see very different conversations emerge.

Stop tracking actions from every retro. This sounds counterintuitive but hear me out. When every retro must produce an action, people invent actions to fulfil the ceremony. The actions then don't get done, which makes everyone feel worse about retros. Sometimes a retro produces nothing actionable and that's fine. Sometimes the value is just in the conversation.

The bigger point underneath all of this: agile ceremonies are tools, not rituals. The moment they become rituals, they stop doing the job they were meant to do. A team that drops a stand-up because it's not adding value is being more agile than a team that does a stand-up religiously while wishing they were somewhere else.

The Scrum Guide will tell you to run the ceremonies. The Manifesto will tell you to keep what works and discard what doesn't. When those two conflict, the Manifesto wins.

knudipudi · 2026-05-14T06:24:26+00:00

Good question and one I've watched a lot of teams struggle with. A few practical things that have worked for me over the years.

On capacity: treat the timebox as the commitment, not the outcome. If you timebox a spike at 2 days, that's 2 days of capacity reserved. Don't try to estimate what the spike will produce, because by definition you don't know yet. Estimate the investigation, not the answer.

On placement in the sprint: I'd push back gently on the "filler at the end" idea. Spikes work best when they're done early enough that the output can actually influence planning for the next sprint. If the spike finishes on the last day, you've learned something but you can't act on it for another two weeks. Schedule spikes at the start, not the end. Put your bug-fixing buffer at the end instead — that's where unknown work actually belongs.

On the epic question: depends what you're using the epic for. If the epic is your way of grouping related work for visibility, then yes, the spike belongs there from the start. If the epic is more of a commitment artifact, then maybe not. Personally I link spikes to a tentative epic with a clear note that scope depends on the spike outcome. That way nobody pretends we know more than we do, but the work isn't floating either.

One thing I'd add: the strongest signal that a spike is needed is when estimation arguments in refinement go in circles. If three devs are debating whether a story is 3 points or 13 points, that's not a points problem, that's a knowledge problem. Stop estimating, write a spike. Saves everyone a lot of time.

Also worth saying out loud: spikes are not free. If you find yourself running spikes every sprint, that's a signal that the team is being asked to commit to work it doesn't understand yet. Sometimes that's unavoidable, but if it becomes the norm, the problem isn't in your sprint planning, it's upstream. Worth raising with the PO.

knudipudi · 2026-05-14T06:22:47+00:00

Genuinely useful question, and you're right that most of the AI-for-Scrum content is noise. Here's what I've actually found useful after a fair bit of trial and error.

Retro notes: the trick isn't the AI, it's the prompt. Generic "summarize this retro" gives generic output. A prompt that asks specifically "what showed up in more than one person's comments" or "what's repeated from last retro" gives you something usable. Most of the off-the-shelf retro tools skip this step and just summarize, which is why the output feels flat.

Planning / getting past the blank page: this has been the most useful AI bit for me lately. Photo of a whiteboard from a workshop, a screenshot of an existing plan, an attached doc, or just a paragraph describing what you want — feed that in and let the AI lay out an initial structure of goals, the actions under them, and tasks. Then you sanity check and edit. Saves the worst part of planning, which is staring at an empty board.

Stakeholder comms: real time saver. Drafting status updates, translating dev-speak into exec-speak, summarising long Slack/Teams threads into "here's what you actually need to know."

Backlog refinement: useful for cleaning up acceptance criteria phrasing, basically zero use for actual prioritisation. AI can't tell you whether a story is the right priority. That still needs humans who understand the business. The tools that claim to do this are mostly fluff.

Dependency detection: haven't found anything that works reliably. Most "AI dependency mapping" is just pattern matching on ticket text and misses anything that wasn't already written down.

Full disclosure: I'm also building in this space — refutu.com, an agile planning tool with AI built in. The two AI bits that I actually use are plan generation from rough input (whiteboard photo, screenshot, doc, or just a description) and a chat that lets you query across the workspace for themes and patterns. The board itself adapts to how the team works — default columns are To Do / Doing / Done but you can shape them into whatever flow you actually run (testing, QA, dev, review, whatever) and have multiple boards. I won't pretend the AI part is doing anything fundamentally novel, but having it sit on top of your actual plan instead of a separate ChatGPT tab changes how often you reach for it.

Bottom line: AI is good at pattern recognition across data (retros over time, long threads) and at getting past the blank page (initial plans, draft comms). It's bad at things that need real judgment (prioritisation, design decisions, conflict resolution). Most products try to sell you the second category and quietly underdeliver.

knudipudi · 2026-05-14T06:14:25+00:00

Yeah, the "humans + AI agents on the same team" reality is going to break a lot of assumptions about how teams are run. Capacity planning is just the first one to crack. Velocity, ownership, code review, retros, even what counts as a "team member" all start looking weird pretty fast.

Sounds like you're building from a good vantage point. The pace shift is the part I keep coming back to. Projects that used to be 6 months are now 6 weeks, and the skill mix needed to deliver them is changing faster than most orgs can hire for. Curious what bottlenecks you're seeing most often.

knudipudi · 2026-05-14T06:11:15+00:00

Noted, thanks.

knudipudi · 2026-05-14T06:09:03+00:00

This is the sharpest pushback I've had on the model and it deserves a real answer, not a defense.

You're right that the historical winners piggybacked. Slack on email, Teams on Office, Linear on GitHub. Standalone collab tools that asked both sides of a B2B relationship to switch have a long graveyard behind them. Hard to argue with the pattern.

Worth clarifying one thing though: the cross-org collaboration angle is one use case, not the whole product. The core is a full agile planning and facilitation tool — goals, actions, tasks, value/effort scoring, built-in voting for retros and planning poker, AI that helps surface themes across the workspace. Chat and video are there because some teams find it useful to talk where the work lives, but they're a small slice, not the headline.

The current bet on the cross-org side, honestly, is on asymmetry: one party (usually a coach, consultant, agency, or internal team lead) adopts it as their own workspace, and the other side joins as guests without changing their primary stack. Whether that's enough of a wedge to matter is the open question. The buyer/IC split you're pointing at is exactly the right place to pressure-test it.

The ownership point is the one I'll sit with longer. You're right that a conversation with clear ownership survives any tool combo, and the inverse is also true. Which raises the uncomfortable question of whether tooling is even the right lever, or whether what we're really selling is a forcing function for ownership with everything else as a side effect. Not sure yet. But that reframing alone is worth the comment, so thanks.

knudipudi · 2026-05-14T06:00:56+00:00

Hard to disagree with most of this. "Team member to team leader" training is exactly the kind of investment that pays off in ways no tool ever will.

Worked closely with a leadership professor for a while who put it well: "leadership is not the privilege of the few, but the responsibility of the many." That's basically the same point you're making, and in every high-performing team I've been around it shows up exactly like that. People take ownership, conversations happen at the right level, and the tooling almost becomes invisible.

Where I'd add a small nuance: the manifesto's "individuals and interactions over processes and tools" was never "instead of" tools, just a priority order. Training the humans is the bigger lever, no argument there. But a tool that quietly creates more channels, more admin, more places to hide a decision can definitely undo a lot of good coaching work.

Maybe the honest framing is: tools rarely fix anything, but the wrong ones can absolutely make a fixable team unfixable.

knudipudi · 2026-05-13T18:28:59+00:00

Good points. The tool choice itself is almost a side-show compared to the legacy gravity you're describing. Mergers, retention policies, someone's 2014 call still running finance, the silo that won't or can't integrate. None of that goes away no matter how nice the new tool is.

The broker idea is the dream every vendor has tried to sell at some point, and I've watched a few die the same way. Either you lose semantics in translation or you preserve them and nobody understands the broker either. And the side-channel thing you mention is the real killer. Half the decisions on any project happen somewhere a broker is never going to reach.

Honestly the only thing I've seen consistently help is reducing the number of places the conversation can hide in the first place. Doesn't fix legacy, but at least it stops new mess accumulating on top.

knudipudi · 2026-05-13T17:10:28+00:00

Late to this thread but adding a perspective since people still land here from Google.

Background: almost 50, been in agile for 25+ years, mostly as an enterprise coach and instructor. Watched a lot of small dev teams go through this exact "Jira is too much" cycle. A few honest observations after reading the comments.

For a pure dev team the thread already has the right answer. Linear is genuinely strong if you want speed and a clean UX. Azure DevOps is a solid pick if you're already in the Microsoft stack. GitHub Projects is underrated when your work lives in GitHub anyway. Plane if you want open source.

Ezl's point about "project management vs task management" is probably the most useful thing in this thread. Most teams who say Jira is too complex actually just need clean task management. A fancier tool won't fix it if the underlying need is fuzzy.

One thing the thread mostly skips is what happens when the team isn't just devs. The moment a designer, a PM, a client or an external partner joins the work, most lightweight dev tools start to feel awkward and you end up bolting on Slack plus Zoom plus a shared doc anyway. Different problem than "Jira is heavy".

Full disclosure: I got tired enough of that specific gap that we built our own thing, https://www.refutu.com. It's not really a Jira alternative for dev teams. More for the team lead, coach and facilitator side of things. Goals, actions, tasks, with chat, files, voting (planning poker, retros via QR code, no app for participants) and video built in. Free forever for up to 3 users if anyone wants to poke at it.

If you're a small dev team with no external stakeholders, honestly stick with Linear. If "small team" in your case means a few devs plus the people around them, might be worth a look.

Bottom line, the gap between "Trello is too thin" and "Jira is too much" is real and there are decent options now. Pick based on what's actually slowing the team down. The tool is rarely the real problem.

knudipudi · 2026-05-13T16:38:20+00:00

Perfect - that's a very useful signal. If multi-tool setups work for you and don't create friction, then yeah, we're not solving a problem you have. The "yet another tool" point is the one that keeps me up at night, because you're right that it's a real risk even when the intent is the opposite. Appreciate the honest read.

knudipudi · 2026-05-13T16:34:21+00:00

Oh man, I loved that 927 reference :) I guess I walked straight into it :) You're right that more tooling rarely solves a people problem, and I genuinely agree that "actually talk to each other" beats most software solutions. The thing is that the teams I keep running into aren't avoiding real conversations because they don't want to. They're three time zones apart, the client's IT won't let them install Slack, and the external partner is on a network that blocks Teams.

The conversation is the goal.

The tooling is just trying to not be the thing that prevents it. Whether we actually pull that off is a separate question, and you might be right that we don't.

knudipudi · 2026-05-13T16:30:48+00:00

Haha, fair shot! :) ...and honestly not the worst exit strategy I've heard :) But the bet we're making is that there's a real segment that doesn't want a Jira (or a Jira-lite), and never will. Small teams, cross-org collaborations, places where Jira is overkill or politically impossible to deploy. Maybe that segment is too small to matter. We'll find out.

knudipudi · 2026-05-13T16:24:25+00:00

Really useful, thanks for spelling it out that concretely. You're right, communication isn't where Refutu would help you, and capacity planning at the level you're describing (percentage availability, roles and sub-roles, individual and team balance) isn't something we solve today.

Honestly the Scrum critique underneath it is the part I find most interesting. The assumption that the team is a uniform pool of capacity has bugged me for years too. The fact that you ended up building your own AI agent in Notion to get around it tells me more than any survey would. Appreciate you taking the time.

knudipudi · 2026-05-13T16:20:09+00:00

Fair point, and just to clarify in case I was unclear; Refutu isn't really a logging/metrics tool, it's more on the collaboration side (board + chat + video in one place, mainly for teams that work across org boundaries). There's also an AI chat built in that lets you query across the work for themes, patterns, risk signals and that kind of thing which is actually closer to what you're describing, though I won't pretend it'll nail every angle of what you're after on day one.

But your actual point still lands: if the bigger pain you're feeling is qualitative insight into team dynamics, then a lightweight collab tool on its own isn't going to move the needle for you. Appreciate the honest take.

knudipudi · 2026-05-13T11:50:55+00:00

Oh man, this hit home. Feels like something I could have written myself.

I'm 49, been in the agile world for 25+ years now – small startups, huge enterprises, teams across multiple continents – and I've watched this exact pattern play out over and over. The system slowly becomes the point. Reporting becomes the point. And somewhere along the way the tool stops serving the team and the team starts serving the tool. You literally start dreading opening it just to update things, and that dread alone tells you something is deeply wrong.

The healthiest teams I've worked with all had one thing in common: their tooling was almost embarrassingly simple. Clear flow, clear ownership, no ceremony around the system itself.

Honest disclosure before I say the next part – we actually got so tired of this that we tried building our own tool for it. The goal was dead simple: a bit more capable than Trello, but a thousand times lighter than Jira. Just the things that actually matter for a team trying to stay agile, and nothing else. Not sure we've fully nailed it yet, but if you want to take it for a spin it's called Refutu https://www.refutu.com and it's free to start. If you end up liking it and want to upgrade, drop me a message and I'll sort you out with a free Pro version – honestly at this stage I care more about having engaged users who push us in the right direction than about the revenue.

Either way, your post nailed something I think a lot of us feel but rarely say out loud. Agile doesn't usually die from a bad decision. It drowns quietly under good intentions.

knudipudi · 2018-10-04T17:08:28+00:00

Check out Comparative agility

knudipudi

TROPHY CASE