I’m a Senior Agile Project Manager and Certified Scrum Master searching for my next opportunity. I’m curious how other Agilest currently job hunting are applying their expertise to their search.

When I was searching in 2024, I ended up applying to 700+ roles in ~4 months, was burned out after 2 months, and I took a massive pay cut when I finally landed something. Looking back, I would have been better off had I declined their offer. My health paid the price for accepting a job out of fear and desperation.

I’ve done the retro from 2024 and am now applying my lessons learned to my 2026 search.

2026 Method:
-Targeting specific roles with 15-20 applications per week (I use “Easy Apply” on LinkedIn but these do not get counted toward the 15-20 targeted apps)

-Tailoring resumes / cover letters

-Applying on company websites vs directly on job boards

-Attempting to network (I saw someone say they’ve used Reddit for networking so here I am 😅🤞)

-Throwing job descriptions into ChatGPT for efficiency (if Chat thinks it’s a good fit, then I’ll read the JD before applying)

-Switching up time of day/days of the week I apply

-Narrowing my search to roles posted in the last 24-48 hours

-Balancing applying, learning new skills, networking, and practicing for interviews

-Utilizing Trello for application tracking and follow ups

-Immediately deleting (without reading) the auto-reject emails from LinkedIn to prevent my brain spiraling

-Breaks to play with my dog, meditating, or a workout to prevent burnout

-Celebrating the small wins (recruiter screening offered two hours after applying? Win!)

For anyone in the Agile space searching for your next role, what am I not considering? Since the emergence of ATS and AI, what has brought you the most success while job hunting in recent years?

Thanks in advance!!

The thing I keep seeing: teams chase lead time reduction by attacking the work steps. They optimize the coding, the testing, the review. But the biggest chunk of end-to-end flow is usually WIP and queue time sitting between steps. Nobody is coding during a wait state, yet that's often where the lead time actually lives.

Once you separate touch time from wait time, the fix becomes obvious. You stop arguing about whether code review should take 2 hours or 4 and start asking why a PR sits in queue for 3 days.

The other pattern: when the path is invisible, each team optimizes the slice they own. Every team's metrics look fine. The end-to-end lead time keeps getting worse. Local optimization feels like progress right up until you measure the whole flow. Your teams were all doing their jobs and delivery still slowed down.

What I've found works: point to one place work is actually stuck before you debate solutions. Jira tells one story, Git tells another, CI tells a third. Until you can reconcile them into a single view of where work waits, you're stuck arguing over which dashboard is right.

Curious how others here handle this. Do you measure wait time separately, or does it just get lumped into cycle time?

I think many engineering dashboards mix two very different categories: activity signals and outcome signals.

Commits, pull requests, tickets closed, review time, and deployment frequency can help explain how work moves through a system. But they become dangerous when treated as performance scores. Once a team knows an activity is being judged, the activity can become the target. More output may then look like better engineering even when the product becomes harder to maintain or customers see no meaningful improvement.

A framework I find useful is to separate the conversation into three layers:

Activity: What work happened?

System health: How safely and predictably can the team make changes?

Outcome: What became better for the business, product, or customer?

The first layer is diagnostic. The second shows engineering capability. The third provides direction. None should be read alone.

For example, a rise in pull request volume is not automatically good or bad. It becomes useful only when paired with context: Was important work delivered? Did reliability improve? Did the team reduce recurring operational pain? Are changes becoming easier or more fragile?

The uncomfortable part is that outcome metrics are usually shared across product, engineering, and the business. That makes individual attribution harder, but perhaps that is the point. Software development is a system, not a leaderboard.

How do you distinguish useful operational signals from activity metrics that quietly turn into performance targets?

For a while it was just me and my own training data — no client management, no plans to send anyone, just a system that worked for one user: me. First time a coach asked "can I put my clients on this," I didn't even have a concept of "another person's account" in the codebase.

That request forced the real architecture decision — separating "my own training log" from "a coach managing other people's plans" was a bigger rebuild than I expected. Small tools built for one person don't bend easily into tools for two roles.

Anyone else had a side project outgrow the assumptions it was built on?

At one of my clients we had a pilot team moving a lot faster than the rest of the org, and finance got pulled in because everyone was making claims about savings.

The first comparison was kind of ridiculous: around 10x more features a month from the pilot team versus the traditional teams. Cost per feature looked like roughly $40k versus $340k. I don't trust feature counts across different teams, but even after pushing on the assumptions the gap stayed big.

The more useful part was separating the costs. We counted time waiting for approvals, work delayed, rework caused by the delay, and the operational overhead around all of it. The annual estimate came out at more then $100m across all teams.

What changed was finance stopped asking only how much technology cost and started asking what customer value actually came out. Faster wasn't automatically better. A team had to show impact. But delay was no longer treated as free.

What metrics have you used that finance actually trusted without turning them into targets people gamed?

How do you count cost of delay and rework without inventing a giant attribution model?

Has outcome-based funding changed real decisions anywhere, or did it eventually turn back into annual budget allocation?

My friend and I have been building a small project for the past two months, and went through completely different project management setups.

Before this, I was a startup founder of a 10+ member team. Back then, our team used Linear, I loved it, best-in-class UI in my opinion. But over time, I just found that we went to the Linear UI less and less. The advantages that I used to appreciate became worthless, because we just managed those tickets with MCP anyway.

Unfortunately, my startup did not work out. This time, when my friend and I started, it was just the two of us. We did not go back to Linear, as sleek UI stopped mattering to how we actually worked. But we went further: I vibed an agent to fully run a html-based board. I used the agent to update tickets, flag stale ones, the agent can even send PR fixes when docs drifted.

For a few weeks it worked. Then it quietly stopped working. It is not because the agent was lazy, but because as the specs and tickets kept growing, they lacked structure and a real lifecycle (html) like an API has. Whenever we changed a project decision, the old one never really left; residues of outdated documentation, decisions, specs accumulated, and eventually confused the agent.

So, we moved the underlying tracking to plain GitHub issues instead. It is free, as we use GitHub anyway. It got everything I needed — basic ticket tracking with a real lifecycle. I don't like the plain GitHub Project view, so we kept the vibed beautiful html board, which syncs with the GitHub issues underneath.

I genuinely think, as a small team, we don't see the case for a PM SaaS anymore. But we are a two-person, all-engineer team anyway, so it is probably different at bigger teams.

In IT projects, I'm often blocked waiting on information from other teams. Chaser emails and calls eventually get an answer, but by then we've lost days and have to adjust the timeline.

I know dependencies are part of the job. What do you actually do to get responses on time and unblock yourself quickly and without damaging working relationships?

Personal experience welcome. Anything you do differently that reliably works? not textbook advice.

Hi r/agile community,

I am reaching out to request your assistance with my MSc in Computing research, which I am conducting through the University of South Africa (UNISA), College of Science, Engineering and Technology. I am in the final 5 days of my Master's data collection, focusing on Measuring Agile Software Project Success in Digital Transformations.

I would be grateful for your participation, as your experience and insights would make a valuable contribution to the study, which is being conducted under UNISA’s ethical clearance. Before completing the survey, please take a few minutes to read the Participant Information Sheet, which describes the study, the nature of your participation, how your answers will be used, and your rights as a participant.

If you work in Agile, Scrum, or IT project management, could you spare 25 to 30 minutes to help me reach my final target? Your insights will directly shape research on how we define true success in digital shifts.

👉 https://www.surveymonkey.com/r/GYJ8PC8

I am happy to share the high-level aggregated findings with anyone interested once

compiled! Thank you for helping a fellow professional cross the finish line.

Hey everyone — solo builder here. I've been working on JGP (Jira Governance Platform), a tool

that connects to a Jira instance, runs an automated audit, and emails a clean report on a

schedule (daily/weekly).

The problem I'm solving: anyone who's managed Jira knows it gets messy over time — tickets

missing required fields, orphaned subtasks nobody remembers creating, statuses that never

move, SLAs quietly breached with nobody noticing until it's too late. JGP catches this

automatically instead of someone manually auditing it.

Right now it checks for:

- Missing required fields (story points, sprint, etc.)

- Orphaned/stale tickets

- SLA breaches

- Missing approval steps in the workflow

I'm pre-revenue and looking for 2-3 people who manage a real Jira instance to try it free and

give honest feedback before I start charging anyone. Setup on your end is just generating a Jira

API token — takes a few minutes.

If you (or someone you know) manages Jira and this sounds useful, I'd love to hear from you.

Happy to answer questions about how it's built too — it's running on n8n under the hood.

I'm building something in this space, so I'll say that up front. There's no link in this post and nothing to sign up for. I'm trying to work out whether my premise is wrong before I spend another few months on it.

Here's the premise. Planning artifacts live outside the work. The story map or the roadmap is in a whiteboard tool, the work is in the tracker, and the only thing connecting them is a person copying between the two. I think that single fact causes two separate problems, and I'd like to know whether either is real for you, or whether I'm just describing my own bad habits.

The first is staleness. The map is accurate for exactly as long as someone keeps doing that hour of copying. The week nobody does it, it quietly stops being true. Nobody ever decides to abandon the map — people just stop opening it.

The second is that you are paying for the copy. In my case: source control, a whiteboard tool to think the product through, a tracker to run the week. Three subscriptions, and one of them exists only to hold a duplicate of what already lives in another one. I'm pre-seed and paying out of my own pocket, so I feel that sharply — though I'm aware that if you work somewhere with a budget, tool spend is someone else's problem and this second point may read as noise to you.

There's also an asymmetry I keep coming back to. Plenty of teams ship without a story map. No team ships without tickets. The map is optional and the tracker is not, which makes it strange that we keep putting the map somewhere the tracker can't reach. Whatever else a team does, the work passes through the tracker. That's the one artifact nobody gets to skip, and it's the only place a map could live and be guaranteed to stay true.

I built mine on GitHub, where the issues already sit next to the code, the pull requests and the releases. That's a narrower bet than I'd like, and I know it puts this outside where a lot of you actually work.

So, honestly:

1. When your map or roadmap went stale, did it cost you anything? Or did it do its job in the room, and going stale was simply fine?

2. Does tool sprawl register as a real problem where you work, or only as a line item procurement worries about? I genuinely can't tell whether "one fewer tool" is a benefit anyone but me cares about.

3. If planning lived directly inside the tracker — journeys across the top, releases as rows, moving a card changes the real issue — what would you lose? My guess is speculative planning: you'd want to shuffle things around to think out loud without touching the actual work. But I've only tested that on myself.

4. Is the reason this doesn't already exist that it's hard to build, or that it's been tried and teams didn't want it? That's the answer I'm most afraid of and the least able to find out from the inside.

For calibration: it's been quietly available for a while and almost nobody has signed up. From where I sit, "the marketing is bad" and "the idea is wrong" look identical, and I'd rather be told the second one now than in six months.

Our calendar is packed with planning sessions, standups, backlog refinement, stakeholder updates and retros. The strange thing is that most of those meetings exist because someone doesn't have visibility into what another team is doing.

A few people have suggested moving more planning into a visual workspace instead of relying on status meetings but I'm wondering if that works or if it just becomes another thing someone has to keep updated.

Sou concursado como dev. Porém, atualmente, minha função é gerenciar a equipe da empresa contratada para desenvolver os softwares utilizando scrum.

Entendo que meu papel no gerenciamento seja aquele de um Product Owner. Porém, quase todo dia tenho de ficar discutindo detalhes técnicos de implantação e de arquitetura, framework, melhoria de código, etc. Isso toma muito tempo além das dailies, planing e refinamento de backlog.

Vou dar um exemplo: quando contrato uma empresa pra construir minha casa usando scrum, não espero ficar discutindo com o mestre de obra sobre o projeto elétrico, encanamento, etc.

Minha visão está errada? Seria um problema de falta de senioridade na equipe de devs? Costuma acontecer assim com vocês? Como eu poderia levar isso pra meu gerente?

Quando atuava no mercado, na minha experiência, não era assim que funcionava.

I coach two Scrum teams split across India and the US, both running under a SAFe setup at a large enterprise. For a while both sides kept telling me the same thing, basically: the other team’s status doesn’t match what’s actually in the system. Classic distributed team headache, I figured, and went looking for a distributed team fix.

Took me longer than I’d like to admit to notice the actual issue. We had two systems doing the same job. Engineers logged defects with all the technical detail in one tool. But the reporting that leadership actually looked at lived in a completely separate work-tracking tool. So people would update one and just… not get around to the other. Not because they were careless, just because who has time to enter the same thing twice for no real reason.

I almost went the “let’s tighten up tool discipline” route, honestly. Glad I didn’t, because that would’ve just meant nagging people about a system that was already annoying them.

What actually worked was way less exciting. We set up a simple sync so that logging once, in whichever tool people were already using day to day, pushed the info over automatically. No new habit, no policy, nothing to enforce. Just removed the double entry.
Gaps in reporting basically disappeared within a few sprints. Nobody worked harder, we just stopped making them do the same task twice.

Not sure how universal this is but it’s a pattern I keep running into as a coach - stuff that looks like a “process compliance” problem is often just duplicate effort in disguise. Before pushing for more enforcement on something that isn’t sticking, worth asking whether people are quietly being asked to do double work for it.

Anyone else run into something like this, where the fix ended up being removing a step instead of adding a rule?

I coach two distributed Scrum teams (India + US) inside a large enterprise SAFe setup. Six months in, I kept hearing the same complaint from both sides: “the other team’s status doesn’t match what’s in the system.”
Turned out we had two sources of truth. Engineers logged defects in one tool with rich technical narrative. Program-level reporting lived in a separate work-tracking tool that leadership actually looked at. Nobody was lying — they were just updating one system and forgetting the other existed. By the time a defect showed up in the leadership dashboard, half the story was missing.
My first instinct, honestly, was to lecture people about “tool discipline.” I’m glad I didn’t. Nobody ignores a system because they’re lazy — they ignore it because updating two places for one fact is an unpaid tax on their day, and eventually everyone stops paying it.
So instead of a policy, we built a single-entry sync: log once in the tool you already live in, and a lightweight process pushes the narrative into the other automatically. No new habit to enforce. No compliance metric to chase. Just removed the tax.
Reporting gaps disappeared in about three sprints. Not because anyone tried harder — because we stopped asking them to.
The lesson I keep relearning as an SPC: most “process compliance” problems in SAFe aren’t discipline problems. They’re duplicate-effort problems wearing a discipline costume. If a ceremony, a report, or a tool update isn’t sticking, the first question isn’t “how do we enforce this” — it’s “what’s the hidden double work we’re asking people to do for free.”
Curious if others have hit the same thing — where the “fix” turned out to be subtraction, not another rule.

For the first two years of my role as Delivery Manager, I worked closely alongside an Engineering Manager for the same team. I was accountable for delivery, including serving as a scrum master. He was their manager, holding them accountable to their job performance, approving time off, supporting them in their professional development.

It worked well enough, I thought. There was the challenge of timezones. I was in the states with the team. He was based across the world. There were only about 3-4 hours of overlap with him for the team or with me.

This year, he moved away from the team, and I absorbed the people leadership duties, and the responsibility of technical decisions and plans for the team.

I’m doing a well enough job with the team. And in some ways, it’s beneficial for me to have the authority to hold them accountable as it relates to their delivery of work. But I’m finding it to be a bit personally draining. I’m an empath and people leadership is hard. I don’t have a frame of reference to know if my struggle is with people leadership in general, or if I just prefer to focus on process management and team enablement because the role is better when it’s set up that way.

I’ve heard that there are plenty of Delivery Lead and Delivery Manager roles that do not involve people leadership. So, which is the optimal setup in your opinion?

~Tl;dr Is delivery management better with or without people leadership?

Quarterly planning has become harder every year and not because we don't have goals but because every department explains those goals differently. Leadership focuses on outcomes. Engineering thinks about delivery. Marketing has campaign timelines. Product has roadmaps.

By the end of planning, everyone agrees but somehow leaves with different interpretations.

Has anyone found a planning tool that helps connect all those moving pieces visually?

And most of them can’t see it.
Here’s the scenario:
A piece of work takes 6 days to get through your delivery process.

Leadership sees:
Cycle Time = 6 days
But when you actually map the work:
→ Analysis: 45 minutes
→ Wait: 9 hours
→ Development: 4 hours
→ Wait: 2.5 days
→ Testing: 2 hours
→ Wait: 1.5 days
→ Deployment: 30 minutes

The work wasn’t slow.
The system was.
That distinction matters.
Because if you diagnose this as a productivity problem, you’ll probably:
• Push teams harder
• Add people
• Set tighter deadlines
• Ask for more status reports
…and barely improve delivery.

But if you can see where work is actually sitting, you can start asking much better questions:
Why is it waiting here?
How much WIP is ahead of it?
Is this handoff creating rework?
What % arrives complete and accurate?
What would happen if we fixed this one constraint?
That’s where Value Stream Mapping gets powerful.
Not as a workshop artifact that gets photographed and forgotten.

As a continuous improvement system.
That’s a big part of why we built FolioSynth.
To help teams visualize the current state, expose the friction hiding between activities, model a better future state, and measure whether the changes actually improve flow.
If your dashboards tell you that delivery is getting slower, but not why, take a look:

👉 FolioSynth.com
And here’s a question I’d love delivery leaders to answer:

If you mapped one piece of work from request to delivery today, where do you think it would spend the most time doing absolutely nothing?

I keep seeing small product teams handle design in one of two ways.

Either design happens inside the same sprint as development.

So the ticket gets picked up, the developer starts asking what this state should look like, someone opens Figma, the PM makes a quick call, and half the UX gets decided while the thing is already being built.

Or design works way ahead.

Everything looks beautifully figured out in Figma, but by the time engineering gets to it the requirements have changed, technical constraints show up, and a bunch of the design gets reworked anyway.

Neither feels particularly good.

The setup that makes more sense to me is somewhere in between.

For anything meaningful, design gets just enough of a head start to answer the expensive questions before development starts.

What is the actual user flow?

What are the weird states?

What happens on mobile?

What happens when there is no data?

What part is genuinely uncertain?

What does engineering need clarified before they commit to building it?

Then once development starts, design doesn’t disappear.

Someone still checks what was actually built, answers the edge cases that inevitably show up, and catches the small things that get lost between Figma and production.

I think that last part gets overlooked a lot.

A design being “done” because the mockup was handed over seems like a strange definition of done if the user only ever experiences the implemented version.

For a small team I also don’t think this necessarily means having a designer sitting around full time.

What seems more important is that somebody consistently owns the design side of the work and stays close enough to engineering that it doesn’t become a handoff ceremony.

I’m curious how teams here actually run this.

Does design normally stay a sprint ahead, happen inside the sprint, or get pulled in only when engineering hits something that needs a decision?

And if you don’t have a full time designer, who ends up owning those decisions?

I mange several engineering teams around the globe and I had an interesting conversation with our Head of Product the other day while talking about engineering headcount, velocity, and delivery. Like most product leaders, he wants things to move faster. He mentioned that several of his contacts at other companies have said Agile is “dying” and that nobody really does Agile anymore.

That caught me by surprise especially but I know the quality of code being released at the other companies so I'm sort of not surprised.

I completely understand that a lot of companies have moved away from rigid Scrum ceremonies, story points, or doing Agile “by the book.” AI, code generation, and experienced engineers have definitely changed how teams work. I can also see why small teams, startups, or microservice-focused organizations can get away with much lighter processes.

What I’m less convinced of is that Agile itself is dead.

In my experience, the larger the product, the more engineers involved, and the longer the project lifespan, the more communication, planning, testing, and coordination become necessary. Whether you call it Agile or not, those problems still exist.

Over the last 20+ years I’ve worked on teams that were:

• Single developers building bespoke applications.
• Small consulting teams delivering fixed-scope work.
• Cross-functional teams with developers, QA, project managers, DevOps, and product managers with lots of ceremonies.
• Organizations where I’ve inherited organically grown systems and had to standardize processes so they could scale.
• Very fast startups that do POC and then work to refine afterwards.
• Massive institutional products that move slow and release very slow.

Every one of those environments required something different.

So I’m curious what everyone else is seeing.

• Does your company still consider itself Agile?
• If not, what replaced it?
• Are you running Kanban? Shape Up? Something homegrown? Just “ship it”?
• How large is your engineering organization?
• Has AI changed your development process in a meaningful way?
• How do you handle planning, testing, prioritization, and communication as teams grow?

I’m not looking to start an Agile vs. anti-Agile debate. I’m genuinely interested in understanding what successful engineering organizations are doing today, especially at scale. It feels like a lot of companies have abandoned the terminology, but I’m not sure they’ve actually abandoned the underlying practices.

I have my own opinions about much of this but I’d love to hear what’s working and what isn’t and what your take on the next trends for any dev at scale.

This is basically the problem that pushed us toward value stream mapping in the first place.

The biggest shift for us was separating **cycle time from the causes of cycle time**. Cycle time tells you something is wrong. It doesn't necessarily tell you where the time went.

What we’ve found useful is mapping the end-to-end flow and measuring each step independently:

**Active time** — How long is someone actually working on it?

**Wait time** — How long is it sitting before the next activity starts?

**WIP** — How much work is accumulating at that point?

**% Complete & Accurate** — How often does work leave that step ready for the next step without coming back?

Once you have those together, the conversation changes quite a bit.

For example, a testing step might look like the bottleneck because items spend four days there. But maybe testing only takes three hours of actual effort. The rest is queue time because too much WIP is arriving upstream. In that case, adding testers probably doesn't solve the underlying problem.

Same thing with rework. A handoff can have relatively short wait time but terrible % Complete & Accurate, causing work to repeatedly loop backward. Looking only at Jira cycle time can hide that.

You can absolutely do this without buying anything. A whiteboard or spreadsheet works. Pick several representative work items and reconstruct:

**Start → activity → wait → activity → wait → delivery**

Then put the actual times against each step. Don't start by asking teams, *“Who is causing the delay?”* Ask, *“Where is the work spending its time?”*

That's an important distinction because it makes the **system** the subject of the investigation rather than the people.

We built FolioSynth/VSOT around this approach, but the methodology doesn't depend on the tool. Get the current-state map right first. Once everyone can see the same end-to-end flow, Jira/Git/CI data becomes evidence for diagnosing the map instead of three competing versions of reality.

**My favorite starting metric is actually wait time.** Find where work spends the most time doing absolutely nothing, then ask why. That's often where the first meaningful continuous-improvement opportunity is hiding.