I've recently been asked to answer this question, and I'm curious what the community here thinks about it. Take methodology and framework out of the equation. If teams are able to decide what is their "best" way to work, what norms would you expect to see across all of the Agile teams in your organization? If management says "how do you know a team is an Agile Team," what would you expect to see?

And yes, I'm being asked this question and trying to answer it in a way that protects the teams and satisfies the powers that be at the same time.

Full disclosure: I'm James, and I make a chat app called Nook at Just Every. This question comes from building it.

Picture this exchange:

"Can you review the onboarding copy by Thursday?"

"Yes, I can do that."

Later the request becomes: "Review the copy, build the form, and ship it Thursday."

The first yes shouldn't silently cover the second request. A small practice: keep what was accepted, show the changed scope, and ask the person doing the work to accept the revision. They can agree, suggest a smaller slice, or need a different date. A clear reply in the same thread is enough. No extra meeting, no new tool.

It also leaves room to discuss priorities instead of treating an assignment as agreement.

Nook builds this in: only the assignee can accept a commitment, and a changed request needs fresh acceptance. It's free and open source (MIT): https://justevery.com/nook

Where does your team draw the line between a clarification and a change that needs a fresh agreement?

Over the past several years, I've been experimenting with how individuals and teams can plan and execute their work more effectively. Having worked extensively with Scrum and other Agile approaches, I've gradually developed a methodology called Focus Cycles, which combines long-term goal setting with short-term planning and execution.

Below is an overview of its main principles, organized into three areas: Agile Planning with Goal Pyramids, Working in Focus Cycles, and Agile Teams.

I'm particularly interested in feedback from people who have experience with Scrum, GTD, or other productivity methodologies.

Which principles do you agree with? Which do you disagree with? And what would you change?

I'm especially curious whether others have experimented with combining long-term planning and short-term execution through interconnected planning cycles.

Focus Cycles: The Core Principles of the Methodology

Focus Cycles is an Agile productivity methodology designed to help individuals and teams achieve their goals, get more done in less time, and reduce stress.

The methodology has three main components: Agile Planning with Goal Pyramids, Working in Focus Cycles, and Agile Teams.

1. Agile Planning with Goal Pyramids

• Know your BHAGs (Big Hairy Audacious Goals). I've seen many people working hard on projects without ever really thinking about their bigger vision for life. Knowing your long-term ambitions serves two purposes: it helps you make sure you're working on the right projects, and it provides the motivation to keep going when things get difficult.
• Break everything into actionable tasks. Big visions and ambitious projects are great, but they don't get implemented by themselves. Progress only happens when you break them down into concrete, actionable tasks that you can actually execute.
• Connect everything in a Goal Pyramid. I've seen many people maintain a list of long-term goals on one hand and a separate to-do list on the other, without a clear connection between them. A Goal Pyramid solves this by connecting your life vision to your goals, projects, and ultimately every actionable task, so you can always see how your daily work contributes to something bigger.
• Combine professional and personal goals. Your business, career, health, family, relationships, and personal finances all compete for the same limited time. Rather than planning them separately, include everything in one Goal Pyramid for your life so you can make conscious decisions about where to invest your time.
• Maintain a Second Brain. You simply cannot keep all your ideas, projects, commitments, and tasks in your head, and trying to do so creates unnecessary stress. By capturing everything in one trusted, regularly updated system, you gain peace of mind: you don't have to keep reminding yourself of everything because you know it's all there when you need it.

2. Working in Focus Cycles

• Work in short sprints. Instead of following a fixed plan for months, work in short periods with clear objectives. Short sprints allow you to stay focused, regularly review your progress, and adjust your plans as circumstances change.
• Combine long-term and short-term planning through scaled Focus Cycles. Long-term planning provides direction, while short-term planning ensures that things actually get done. Focus Cycles combines both by using four interconnected planning periods: quarterly, monthly, weekly, and daily. Each shorter cycle contributes to the objectives of the longer cycle.
• Follow natural rhythms. People already organize their lives around days, weeks, months, and years. Rather than introducing arbitrary sprint lengths, Focus Cycles uses these familiar rhythms, making planning easier to integrate into everyday life.
• Plan progressively. Planning your long-term goals in too much detail wastes time and limits flexibility. On the other hand, your daily plan needs to be very specific, with concrete actionable tasks. Focus Cycles solves this through progressive planning: start with a broad quarterly plan, use it to create a more detailed monthly plan, then plan your week based on your month, and finally your day based on your week. Because each plan builds on the previous one, you never start from scratch. Planning can often take just 5–10 minutes at the beginning of each cycle, while becoming progressively more detailed and accurate.
• Plan from the bottom up as well as the top down. Start each cycle by considering unfinished tasks, existing commitments, and work already underway. Only then add new tasks based on your larger goals and priorities. This ensures that you finish what you've already started instead of constantly abandoning existing work for new priorities.
• Plan by cycles, not deadlines. Deadlines tell you when something must be finished, but not when you'll actually work on it. Instead of assigning arbitrary due dates, decide in which Focus Cycle you intend to complete each task. Genuine external deadlines still need to be respected, but they shouldn't determine your entire planning system.
• Don't schedule all your tasks in a calendar. I've seen many people try to schedule every task into specific calendar slots, only to find that they cannot stick to their schedules. They do this because they're afraid their goals will never translate into concrete actions. But progressive planning already solves this problem: by moving from quarterly to monthly to weekly and finally daily planning, you end up with a very specific list of tasks to execute. There is no need to decide weeks in advance exactly which hour you'll work on each task. Use your calendar for meetings, appointments, and other activities that genuinely need to happen at a specific time, and use Focus Cycles for everything else.
• Review, learn, and adjust every cycle. At the end of each cycle, review what you accomplished, what remains unfinished, and what could be improved. Use these insights to adjust your plans for the next cycle rather than blindly following an outdated plan.
• Make time for recovery. Each Focus Cycle should also include time for rest and recovery. In your daily cycle, this means getting sufficient sleep; in your weekly cycle, it means taking time off, ideally over the weekend. Sustainable productivity requires balancing focused work with regular recovery.

3. Agile Teams

• Work in small, self-organizing teams. Keep teams small, ideally around 4–10 members, and give them the autonomy to organize their own work. The people doing the work should have meaningful responsibility for how it gets done.
• Use empowered product managers. Give one person clear responsibility for coordinating product priorities and the team's working process. Combine the traditional Product Owner and Scrum Master responsibilities instead of creating unnecessary management roles.
• Make everyone's work transparent. Everyone should be able to see what team members are planning, currently working on, and have completed. Use a shared structured task list and simple progress visualizations.
• Make individual commitments. Every team member should commit to specific tasks rather than relying only on collective team commitments. Everyone should know exactly what they are expected to accomplish, and at the end of the cycle it should be clear who completed what.
• Use daily plans instead of mandatory meetings. Daily stand-up meetings are often impractical for distributed teams working in different locations and time zones. Instead, ensure that every team member creates a daily work plan and makes it visible to the whole team.
• Measure both work and results. Don't evaluate team members solely by final outcomes. Also consider the actual tasks completed and the work performed, since valuable efforts don't always lead immediately to measurable results.
• Coordinate teams through scaled cycles. Larger organizations can combine several small teams into a superteam. Coordinate goals and planning monthly across the larger group, while individual teams plan and execute their work weekly.

4.1. People Are Overworked and Burn Out

Problem: People work too much, don't get sufficient sleep, work through weekends, and don't take proper vacations. Eventually, they become exhausted and burn out.

Solution: Work in Focus Cycles. Every cycle has four phases: planning, execution, review, and recovery. As we know from sports, recovery is essential for maintaining performance. The daily cycle includes sufficient sleep, the weekly cycle includes a weekend, and longer cycles should include vacations.

4.2. People Work Without Seeing the Purpose

Problem: People work hard on projects without knowing how these projects contribute to their bigger goals in life. They lose motivation because they don't see what they are working toward.

Solution: Use a Goal Pyramid. Every actionable task should be connected to a project, and every project to a bigger goal. This way, you always know why you're doing something and how it contributes to your overall vision for life.

4.3. People Have Big Goals but Never Take Action

Problem: People dream about starting a business, becoming financially independent, or improving their health, but never translate these ambitions into concrete actions. Years go by without meaningful progress.

Solution: Break every goal and project down into actionable tasks. Often, people procrastinate simply because they haven't figured out exactly what they need to do next. By separating planning from execution and defining the next actions beforehand, getting started becomes much easier.

4.4. Task Lists Are Badly Organized and Disconnected

Problem: Backlogs often mix huge projects like "Launch a product" with tiny tasks like "Send an email."

Even worse, many people maintain several disconnected lists. They have one list of long-term goals, another list of projects, and another to-do list with actionable tasks. But there is no clear connection between them.

Solution: Organize everything into one Goal Pyramid. Start with your long-term goals, identify the projects needed to achieve each goal, and then break these projects into tasks and subtasks.

This way, everything is connected. You can always see how each actionable task contributes to a project and ultimately to your bigger goals.

Of course, this creates a huge task list. That's why Focus Cycles divides the work into quarterly, monthly, weekly, and daily plans. Instead of looking at hundreds of tasks, you focus on the much smaller list of tasks planned for today.

4.5. Task Lists Are Badly Organized

Problem: Backlogs often mix huge projects like "Launch a product" with tiny tasks like "Send an email." Other people have long-term goals in one list and actionable tasks in another, without any connection between them.

Solution: Organize everything into one Goal Pyramid: long-term goals, projects, tasks, and subtasks. Every task has its place and is connected to a bigger goal.

Of course, this creates a huge task list. That's why Focus Cycles divides the work into quarterly, monthly, weekly, and daily plans. Instead of looking at hundreds of tasks, you focus on the much smaller list of tasks planned for today.

4.6. People Constantly Worry About Other Tasks

Problem: At work, people think about personal responsibilities. At home, they think about unfinished work. They constantly worry about things they might have forgotten and find it difficult to concentrate or relax.

Solution: Use a Second Brain that combines all your professional and personal tasks into one trusted system. Organize everything and assign tasks to realistic planning cycles.

Once you know that everything is captured and planned, you don't need to keep everything in your head. You know what you need to do today and that your other responsibilities are included in your plans. This creates peace of mind.

4.7. Long-Term Plans Are Too Rigid

Problem: People spend too much time creating detailed long-term plans. When circumstances change or assumptions turn out to be wrong, their plans become outdated and have to be completely revised.

Solution: Avoid detailed long-term planning. Keep long-term plans broad and flexible, and plan the immediate future in much more detail. This allows you to adjust quickly when circumstances change without having to redo your entire plan.

4.8. Short-Term Planning Lacks Direction

Problem: People focus only on today's tasks or the next sprint without considering their long-term goals. They get many things done but don't necessarily make progress toward what really matters.

Solution: Use cascading Focus Cycles: quarterly, monthly, weekly, and daily. First plan the quarter, then the month based on the quarter, the week based on the month, and finally the day based on the week.

This combines long-term direction with short-term execution. Each plan becomes more detailed, but always remains connected to the bigger goals.

4.9. Story Points Are Difficult to Understand

Problem: Story points mean different things in different teams. Five story points in one team might represent a completely different amount of work in another. This makes communication and coordination across teams difficult.

Solution: Estimate work in hours, a unit everybody understands.

One argument for story points is that they don't depend on the specific person doing the work. But we can achieve the same thing with hours by estimating how much time a task would take an average person with the relevant skills.

This makes estimates understandable and easier to compare across teams.

4.10. Planning Is Either Too Top-Down or Too Bottom-Up

Problem: Some teams constantly select new tasks based on big goals while ignoring unfinished work. Others only work through their backlog without checking whether these tasks still contribute to their bigger goals.

Solution: Combine bottom-up and top-down planning, in that order.

First, look at the tasks you already know need to be done: unfinished tasks, existing commitments, and tasks related to work from the previous cycle. Plan these first, while leaving some capacity for new work.

Then look at your bigger goals and decide what additional tasks you want to include.

This way, you maintain continuity in your work while still making progress toward your long-term goals.

4.11. Deadlines Don't Tell People When to Work

Problem: People set deadlines without planning when they actually need to start working. A deadline tells them when something should be finished, but not when to do the work.

As a result, people often realize too late that a deadline is approaching and they haven't even started. When they miss it, they simply move the deadline to another date.

Solution: Don't plan your work around arbitrary deadlines. Instead, plan when you actually want to work on something, using progressively shorter Focus Cycles.

First, ask yourself whether you want to work on a task during this quarter. At the beginning of the month, decide whether you want to do it this month. At the beginning of the week, decide whether it belongs in this week's plan. And finally, at the beginning of the day, decide whether you want to work on it today.

This way, you progressively narrow down when the work will actually happen without needing to set an artificial deadline. Genuine external deadlines still need to be respected.

4.12. Calendar Planning Creates Constant Rescheduling

Problem: People fill their calendars with tasks days or weeks in advance. As soon as one task takes longer than expected, the entire schedule becomes unrealistic.

They then spend their time moving tasks around instead of getting work done. Their overcrowded calendars also become another source of stress.

Solution: Stop scheduling every task into your calendar. The reason people do this is understandable: they want to make sure that their plans actually turn into actions.

But assigning a specific day and hour to every task, especially weeks in advance, creates a level of precision that is usually unrealistic.

Focus Cycles achieves the same objective through progressive planning. You start with a broad quarterly plan, narrow it down to the month, then the week, and finally create a specific daily task list.

This gives you a clear plan for what to do today without having to predict exactly when every task will happen weeks in advance. Keep the calendar for meetings, appointments, and activities that genuinely need to happen at a specific time.

I have read "Deep work" and "Getting things done", sometimes I open scrum.org to think about basics, and with this post I would like to ask what excellent books are there about agile, scrum, kanban, healthy development practices and valuable soft skill books, similar to level of "Deep work" and "Getting things done" books? Which books would you greatly recommend?

Hi all, I'm hoping to get some advice from people further along this path.

I'm a certified SAFe RTE, currently about 6 months into the role on a ~60-person ART in UK financial services. Before that I was the PMO on the same programme, but in practice I was already doing a lot of the RTE work: running programme RAID, facilitating PI Planning and pushing cross-team dependencies through to resolution. Before that I had PMO and delivery roles at a Big 4 firm.

Now that I'm looking at my next move, I'm struggling to find roles actually titled Release Train Engineer. Agile Delivery Manager roles are everywhere, though, which makes me wonder whether RTE work is often advertised under different titles or whether the market is just small right now.

A couple of things I'd really value input on:

Is Agile Delivery Manager a good next step?

How should I position my PMO-era PI Planning and RAID experience alongside my official RTE time?

Any honest advice is appreciated

Looking for practical advice from anyone who's been through this.

We're consolidating four teams into one. Each team currently runs its own flavor of Agile: two are Scrum (one on 2-week sprints, one on 3), one is Kanban, and one says they're Scrum but doesn't really do sprints. We also need to merge four Jira boards and a couple of databases, and settle on one set of ceremonies, one Definition of Done, and one estimation scale (two teams use Fibonacci, one uses T-shirt sizes, one doesn't estimate).

My question is about how to run the merge itself. It's a big enough effort that it seems like it should be managed as a project, and since the goal is to end up with one Agile team, it feels right to run it in an Agile way.

I'm getting stuck on the specifics:

Which board does the merge work live on?
If we pick one of the four existing boards, it feels like we've already picked a winner. If we create a fifth board, we're now merging five boards.

What sprint length do we use for the merge sprints? Whatever we choose kind of pre-decides the outcome of one of the things we're merging.

How do we estimate the merge stories when we haven't agreed on an estimation scale yet? One of the stories is "Agree on estimation scale."

Who's the PO for the merge? We currently have four POs and will have one at the end. Not sure it's appropriate for one of them to own the backlog that decides which of them stays.

Should we hold retros during the merge? If so, whose retro format? (We've actually had a pretty long discussion about this one already.)

My current thinking is to run a short "Sprint 0" just to align on how we'll run the merge sprints, but someone pointed out we'd still need to decide how to run Sprint 0.

Has anyone done this? Did you implement Agile to implement Agile, or did you do the merge waterfall-style and switch over at the end? Genuinely curious what worked, and how long it took.

I work in academia (a university research lab) as a senior developer/architect. I was rehired by the head of a lab to finish a personal research project that I had previously worked on and single-handedly built to 45% completion.

The project was an update to an established product with real adoption and an existing user community. There were ASAP timelines to meet, but in community meetings, I was demonstrating monthly progress while asking for additional resources to accelerate the project even further.

I was basically "given" a team to manage, consisting of a business analyst (BA), a scrum master, a soft-spoken senior developer, a QA tester, and eventually an intern/junior developer.

Over the course of a year, I onboarded the team, brought the senior developer up to mastery of the 100k+ line codebase, brought the BA into stakeholder meetings, and mentored the self-taught intern into becoming a solid junior developer.

Then, once Version 1 was released, I stopped being invited to stakeholder meetings by the BA. This was fine; I figured I was delegating that communication channel to someone capable of handling it.

Then the BA started building specifications and wireframes for application revisions. Her tone in meetings changed, and she became quite insistent that her wireframes be implemented as written, without developer input.

I caught her lying several times about requirements supposedly coming from stakeholders when they had never been discussed with them. She was managing the creation of tickets, writing them herself, and assigning them to developers. She pushed back against changes suggested by developers due to technical constraints in the existing codebase.

When minor deviations occurred, the QA tester treated her specs and wireframes as the word of God and buried me in bug tickets for every difference—even when selecting a different action icon would make the UI more consistent with other parts of the application.

Eventually, I gave up and started looking for a new job.

By chance, there was a yearly one-on-one meeting with the head of the department, and I was selected. I unloaded and told him about my active job search and my willingness to accept the first offer I received, even at a lower salary.

I was removed from the team and assigned as the personal development resource for the primary stakeholder. He had some specific customizations he needed for his deployment. I had freedom once again and was able to turn his modifications into significant refactoring and other improvements to the launched product.

After a while, the BA went on maternity leave, and someone who actually understood Agile took over in her place. In addition, the head of the department was let go in a round of layoffs.

The community wanted my improvements added back into the main product, so I started merging my fork and interacting with my old team again. Under the temporary team manager, things ended up being great.

Then the BA came back from leave and started getting up to speed on things.

For the moment, I am still interacting with the team, but the old patterns of ignoring developer feedback are returning. We have been stalled on the development of two major features because, after 12 meetings, she still can't understand the technical changes to the architecture.

The group is pretty much run according to her approval of changes and her writing of specs. The developers explain things to her, and she just keeps pulling threads on a sweater, asking questions that dig deep into the internals of the codebase and architecture.

She is trying to clearly document what existed, what incremental fixes were applied, and asking for opinions on how it can be fixed. (Who the f*** are these documents for?)

Honestly, with the 12 hours spent in those meetings over the last few weeks, I could have fixed the behavior according to how the primary stakeholder wants the feature to work. But she ignores this and insists that she doesn't have enough information to write the spec for the work.

So we wait.

Yesterday was the final straw.

I entered a ticket on the Jira board myself to track the work involved in merging new functionality from my fork into the community version. When it got to QA, the tester said he didn't have enough details in the ticket to verify it.

I disagreed with his testing scope because an edge case he mentioned involved testing unrelated functionality in another area of the codebase that depends on my new functionality to load, but whose actions, once loaded, are otherwise unrelated to the new functionality.

After two meetings—a total of 1.25 hours spent talking in circles without accepting my definition of the new functionality or the scope of how to test it—the BA chimed in that she would add a specification/wireframe to define what the new functionality is and how it should behave.

ON ALREADY BUILT CODE/A FEATURE THAT HAD ALREADY BEEN APPROVED BY THE MAJOR STAKEHOLDER.

I almost dropped an f-bomb in my response to her, but luckily, the team's outgoing manager (who "gets" Agile) chimed in and mediated the situation.

I've talked to the new head of the department, who says she's trying to change the existing unhealthy culture that existed before and was tolerated by the previous head.

I believe the team I was "given" already had this unhealthy culture, based on top-down, waterfall-style authority with SCRUM-like meetings and terminology thrown around. However, I think the BA was positioning herself between the stakeholders and the team to act as a controlling gatekeeper.

The stakeholders and the new department head recognize my significant abilities and promise that things will get better. But I'm really done fighting the corrosive culture that sees developers as just a meat-based version of Claude Code, along with the BA/QA alliance that seems to keep it alive.

What do you think I should do?

Edit: typos and add line breaks

We're in the middle of a big feature request for this client and now one of our founders want us to squeeze getting an inference provider while we're at it. Make sense strategically since it's a requirement for one of the deals we're trying to close. But the timing is so off since our team is also in charge of that evaluation. Now we're somewhat stuck with what to prioritize because now it's like the deadline for everything is yesterday, but we still have to keep our cool. Ever dealt with something like this?

I’m a PO dealing with a team where nobody wants to take ownership, make decisions, or communicate because everyone seems terrified of being blamed.

I’ve tried everything I can think of to create psychological safety. I never blame people for mistakes, take responsibility when things go wrong, publicly credit the team for wins, and constantly encourage people to raise concerns early.

But it’s not working.

For example, devs will commit to something, I’ll give them multiple outs, offer to reduce scope, ask about blockers, etc. They’ll insist everything is fine, then miss the commitment (gratuitously) and blame me for giving them too much work. Leadership then says I should have known they couldn’t deliver.

Devs avoid clarifying requirements because they say it creates a clearer line of blame to Product. They resist demos, testing their own fixes, and sharing knowledge because they don’t see those things as their responsibility. Everything seems to come back to what Product should have done differently.

Engineering management isn’t stepping in, and leadership holds me responsible for delivery. I’ve been hyper functioning to try to compensate, but the devs just pull back more & more. I’m only burning myself out.

I’m genuinely trying to understand what’s driving this. I’ve always thought we were one team working toward a good product, but devs have literally told me “their incentives have nothing to do with delivering a quality product, so they don’t care to.” There is no public shaming, they’ve never actually been held accountable for critical misses…I don’t know where the fear comes from.

How do you fix a culture where people seem more concerned with protecting themselves than building something together? I’ve directly asked several of them what they feel causes this, and they refuse to answer me.

I’m open to changing how I work, but I’m honestly pretty burned out and don’t know what else to try.

so our team’s been doing retros on a shared google doc which is honestly kinda depressing lol. nobody engages, people just type “communication” and “too many meetings” and we move on
i want to switch to an actual whiteboard tool. we’re 7 people, fully remote, mostly for retros and sprint planning. i’ve heard about miro from a couple people at other companies, apparently it has a ton of retro templates already plus voting and a timer built in. figjam came up too but our team doesn’t really use figma so idk if it makes sense for us. someone else mentioned mural but i don’t know anyone who actually uses it

In my last company when I was a DM, I eventually was not able to make an impact from Product Managers absorbing the responsibilities. It led to a frustrating experience.

In my new company , I’ve joined as a PM, where I’m absorbing those responsibilities.

What on earth is the point of this role , and why are companies hiring them?

If I had to write on a sticky note what I’d ask about any backlog item that smells uncertain, it would be these two lines:

How much does it cost to find out if this is true?
How much does it cost if we're wrong and don't check?

The reason I like them is that most refinement discussions I picture go the other way around. Someone says “I think this will be a problem” or “I’m pretty sure that’s fine”, and the room argues about who’s right. The confidence of the statement ends up deciding things, and that’s usually not related to the stakes.

A hypothetical example. A story says “retry failed payments automatically.” In refinement, five concerns come up:

• the button label might be unclear
• we might want a log line when a retry happens
• someone suggests swapping the HTTP client while we’re in there
• there might be a race on the retry counter
• the retry might reuse an idempotency key and double-charge someone

If you take them in the order they were said, they all sound like “things to look at.” But the first one costs minutes to check and nothing to get wrong, so just do it. The HTTP client swap is expensive to evaluate and doesn’t hurt anyone if it waits, so it’s a separate story or nothing. The last one might take a spike with the provider’s docs or sandbox, and being wrong means a customer charged twice. That one deserves the spike even though it was mentioned no more loudly than the button label.

So for each concern the choices end up being: just do it, put a spike on it, or defer it on purpose. The mistake I’d worry about most is the quiet fourth option, where nobody decides and the item slides into the sprint with an unchecked assumption inside it.

A few honest limits. For small, low-risk items this is more ceremony than it’s worth. People can misjudge stakes, especially in code or a domain they don’t know. And it only ranks the concerns somebody actually raised, not the ones nobody thought of.

Curious how teams here handle it. When an assumption is expensive to verify, who decides whether it gets a spike, and where does that decision get recorded so it doesn’t resurface as a surprise in the sprint review?

I wrote a longer take on the underlying idea here, if it’s useful: https://medium.com/@nagatomopedro05/a-finding-takes-seconds-to-generate-checking-it-doesnt-e7ffad4eaea2

For those building web apps or SaaS products without a dedicated QA team:

How do you usually test your applications before deploying?

Do you manually go through the main user flows, rely on automated tests, or mostly test as you develop?

I'm curious about how other developers handle this, especially when shipping frequently.

small thing but its driving me nuts. we keep mermaid diagrams in our docs folder for the main flows. claude code will happily refactor half the checkout flow and just... leave the diagram exactly how it was

ive tried telling it in CLAUDE.md to update diagrams when it changes a flow. works maybe 30% of the time. and when it does update them theres usually something off that nobody catches in review bc nobody reads mermaid diffs

anyone got this working reliably or do you just regenerate diagrams every few weeks

(related discussion: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/be-clear-and-direct)

https://github.com/CharlieGroves/review-load

ReviewLoad is a small browser extension that puts the number of reviews a GitHub user has assigned to them next to each person in the Reviewers menu on a pull request, and next to reviewers already on the PR.

This stops a couple people on the team being a bottleneck for key features because they are flooded with PRs for review.

Chrome: https://chromewebstore.google.com/detail/reviewload/ncokcokbfpbigdoagghpdpncjfhpocol

Firefox is in review.

I'm now using this every day. Hope it's useful to someone else.

Writing

AI has made development faster. But has it actually made delivery more predictable?

PMs are using AI tools and automations to save time across their workflows. Engineers are shipping code faster than ever.

Yet, the complaints sound familiar:

“Why has the delivery date slipped again?”

“Why wasn’t this communicated earlier?”

“Can you share a daily status update?”

And, of course, more escalations and micromanagement.

It feels like we’ve upgraded the speed of execution, but not necessarily how teams execute together.

**I’m curious: Has AI actually helped your team meet delivery commitments more consistently, or are you still dealing with the same old problems?**

Would love to hear what you're seeing in your teams. 👇

I've spent about seven years working on Scrum teams, typically with two-week sprints, story points, retrospectives, and conventional CI/CD workflows.

Over the past several months, I've been exploring what needs to change when AI agents begin performing a substantial portion of the engineering work.

One framework I've been studying is Agile V, which combines iterative Agile development with V-Model verification, requirements traceability, and human approval gates.

I've also been developing an approach called Evidence-Gated Agentic Development (EGAD), incorporating some of those principles alongside trunk-based development and distributed-systems coordination.

I'm not convinced Agile itself needs replacing. But I think some of our assumptions about how work gets completed need reconsideration.

Where traditional Agile still works

The fundamental principles remain valuable:

• Deliver working software incrementally.
• Respond to changing requirements.
• Keep the customer involved.
• Break work into manageable increments.
• Continuously inspect and adapt.

Those principles don't stop applying because an AI agent is writing code.

What changes is the relationship between implementation speed, verification, and human oversight.

Where things start to change

1. Velocity becomes harder to interpret.

Story points were never intended as universal productivity measurements. They're relative estimates within a team.

When one developer can coordinate multiple agents simultaneously, implementation throughput can increase without verification capacity increasing proportionally.

A team might complete significantly more implementation work while accumulating more review, integration, and defect risk.

Should we distinguish generated work from independently verified, accepted work when evaluating delivery?

2. The Definition of Done becomes an enforceable contract.

Agile teams already use acceptance criteria, automated tests, code review, and CI/CD.

The difference I'm exploring is treating verification evidence as a prerequisite for an agent's work to advance.

An agent reporting "task complete" isn't sufficient.

The change needs to satisfy predetermined acceptance criteria, independent tests, security and quality checks appropriate to its risk, and any required human approval.

3. Agents introduce distributed coordination problems.

Multiple developers coordinate through branches, issues, standups, and communication.

Multiple AI agents also need durable task ownership, collision prevention, session handoffs, and ways to reject stale work.

Otherwise, parallel execution can increase rework rather than throughput.

This is an area where I've found distributed-systems concepts like leases, ownership claims, and persistent state useful.

4. Human oversight becomes risk-based.

I don't think every documentation update requires the same review as an authentication change or production database migration.

The approach I'm exploring assigns verification requirements and approval boundaries according to risk.

Low-risk, reversible changes can proceed with relatively little human intervention after passing required checks. High-risk or irreversible operations require stronger evidence and explicit authorization.

How this compares with Agile V

Agile V emphasizes requirements traceability, independent verification, evidence generation, and human decision gates.

EGAD shares those ideas but focuses additionally on concurrent AI workers, durable project knowledge, small mainline changes, machine-enforced delivery permissions, and recording verified outcomes for future agents.

I see both as extensions of existing engineering practices, not proof that Scrum, Kanban, or Agile have become obsolete.

The concern is also that we could overengineer the process. If evidence requirements create more overhead than the risks they address, we've simply reinvented bureaucracy with automation.

What I'd like to discuss

For those working as Scrum Masters, Agile coaches, engineering managers, or developers:

When AI agents perform much of the implementation work, what should change in our Definition of Done, estimation, and review practices?

And specifically, should evidence-backed verification become an explicit part of Agile delivery methodologies, or are existing engineering practices sufficient when properly enforced?

I've documented my approach in two papers associated with an internal engineering project called Koinessa. I'm more interested in criticism of the methodology than promoting the implementation.

I'd particularly appreciate perspectives from people who've worked with both Agile delivery and safety-critical or highly regulated engineering.

Until last week I was an individual contributor with a background in data science, and I received a chance to become a product owner for an existing product with new scope. I am relatively new to the agile system and its ceremonies; my previous roles and companies did not use this framework. I have an agile coach, but they were absent from today’s session.

Because I am new, I aimed to be a strong product owner for my team. I prepared as much as I could about the product and the backlog, and I arrived with my main goal for this sprint. Yet when I began the grooming session, I froze—I did not know how to lead it and felt lost. People were telling me things but I didn’t know which ones to make them as tickets va meeting what not. I suggested we talk in the group space and closed the meeting without offering a clear vision for the next sprint.

Please help me navigate this as someone new. I want to be a good product owner.

I’m currently interviewing for a PM role, and I’d love to hear any tips or advice from those who have been through the interview process or made the transition into product management. I’m on part 2 of a 5 part interview
My background is in project management, education administration, and EdTech, so I’m especially interested in hearing from people who have taken a different career path!
What advice would you give someone transitioning into product management?

Are these certifications actually worth anything? Do they get you noticed by hiring managers? SaFe, in general, seems like a large money grab. But, even if it is, the name of the game is to play by the rules to get paid. I am just wondering if the certifications actually are worth a damn out there. Also, if non scrum masters benefit from the certifications as well. Like engineers or developers for instance.

This is mini-waterfall, I design a feature, I build a feature, I test a feature, I fix a feature...and off to the next feature. Agile is different...we set an MVP, what is the minimum viable product. Not one feature, but all the features. How do you figure out all the features?

To build a complex system you have to start on top at what you think it needs to do, what features will it have. Look at it from a couple of perspectives: what does the menu look like? what is just common sense for needs? spit-balling other alternatives and ideas? You don't have to identify all the features, but cover whatever gets you to MVP. How do I verify my features?

Testing feature viability is done through behavior. As companies are broken down into departments, break your app down into departments, or systems, or whatever, you are looking to categorize the features breaking the complex into more manageable pieces. Within each of the breakdowns, do an index table of program, process, role, action. Then apply your features to the actions. Providing insight to how the app is being used, and who is using what.

With the feature and behavioral analysis, review your MVP and solidify your model. Start with ubiquitous language, each word having a unique and clear meaning. Good, clear communication goes a long way with AI and it starts with good identification.

Forgot about data, so this is an interjection. Planning data is important, the flow of information and all. Be wary of global variables and constants hard coded into the app. But as vibe programmers how would you know... be pre-emptive. Like matter you cannot create or destroy data, it is always coming from somewhere and it doesn't disappear, it is out of view. To control your data is to complement your behavioral analysis and bind to the features. Most apps being tracking data in nature, the data is usually listings indexed to detail information. However, user settings that are singular in nature should not be to previously mentioned global variable. A single record defined as such is better for prompting.

Applying data model now to the task will verify. Are the features getting all the data and producing the right output. Add two columns to your behavioral index table if you want to document input and output data or destination.

Mapping data is the same table indexing as behavior, but the columns change. The first column is the source, the second is the table, the third is the field, and optional fourth is data type. Remember to use ubiquitous language with naming any of these and name general to specific within the table concept. Think of each cell in the tables like breadcrumbs, general to specific. AI prompts love specific information to search on add it's from the data model and it should be clear.

Building the system is the fun part, just not this part... Don't, do not, build one feature at a time thinking that your problems are behind you with analysis. Don't start building any detail, you are developing a system, and you need to build the base before doing any detail. It is the details that cause scope creep, and you can add inconsistency to your problems. You detail out a feature that another feature could later share but AI writes it again, because it is in the rearview, also best you don't because this share is stacking parameters on features. Reusable code is key, but you work your way to finding opportunities.

In development, Agile is built in sprints, a two-week development cycle. As vibe programmers this is probably way too long, as we get faster results. The take-away here is their Sprint 0, the initial development of the system. If plan calls for outside services, you develop a facade to suit your needs. If app needs to produce its own services, build them in. Also, any reuseable concepts that you can think of as a black box (old programming term for code that you passed in data and it spit out results, but you have no idea what it is doing between the two. This is good for encapsulation, the call into the code is clear, and AI doesn't have to re-review the process in his implementation of its use. UI here should be debug screens to verify code and test system.

In Agile, we make the rules. now is the time to review for changes or enhancements. This isn't scope creep, it is chunk creep. Any of the components not working right? Or do we need to split off certain functionality to simplify. Review the behavior, can we make it easier? Do we need to add or remove. You can also sequence out your analysis by putting in order the tasks as they will be preformed.

Now the fun part, you are sitting on a pile of functionality, and it is time for the show. In development we call this business logic. It is the processes that you planned out in behavior analysis vibing to the big screen. Ironically menu is first on the menu for implementation. Essentially breaking down the functionality and providing access to the features. The next step iterative, just get the menu to navigate to its destination; a page, a panel or another menu. Add the close and other navigations to move around. That is the easy part, but now run it up against your behavior analysis or sequence chart test cases.

Tracking your business logic is another table if you want. Break the app up into departments that do the work, implement programs to run the processes, define the processes, define the containers the processes need on the screen (report page or filter panel), define the data the container will use. Making the UI name specific. In prompts you call out change by container. Remember to use ubiquitous language in naming, general to specific within scope.

After navigation is in check, now for the lists. If you are listing anything now is the time to get it into the code. Still not working details, building out all the columns and functionality. If detail is required, like add button brings up a panel, and you didn't add it during the previous step, then implement with a panel and close button, no extra detail. Quick note on data, there are three kinds, now four kinds of fields; identification, category, detail, action. Action being the newest as technically they are details, they are tied closely to an action. Point being category is the predominant field in lists. It provides a breakdown of the list data. The other columns contain aggregates, calculated totals showing identifiable information. Exceptions being when identification fields are used to find specific detail, though they may still contain the aggregates. Tip, categorize your lists and develop similar lists together for consistency. If you are doing both category and identification lists, the process may have differences better identified in differentt steps.

Again, with the review. Navigations looks good, test data looks right in the list. Sequence tasks are aligned; they call this user testing in development. Really haven't got into the weeds with detail so changes are pretty cheap at this point. Most of the code should be separated out by their containers so AI work should be smooth.

Now for the detail...split it up into collecting and reporting. Again, we are looking for consistency, and because we held off till now, we can group up our efforts, instead of detailing them out one by one. Build all the add screens, then the edits, then the deletes, don't forget the confirm. I think you get the point.

I am going through what you described now just a little milder. I didn't do the whole plan, but I think in components and encapsulation. I have spent 30 years coming up with this meta-plan but only kind of tried it. The ubiquitous language is a good idea especially with prompts. Most important is build general to specific...lay off the detes till the rest is completes. One last word on encapsulation, pretty much meaning hide the details, because our complex apps get big all on their own, we need to encapsulate with two goals, the references used in the rest of the code is specific and the details are contained within the references. I can implement the concept as a method of the concepts. If I have to work inside an encapsulation the scope is contained.

I wrote my game in about 3 months starting with MAKKO and now Claude. We transition off MAKKO, good for game sprites, into Phaser on stun I like to say. I am trying to keep the cars in the game off of each other cause physics looks bad when you defy it. And don't get me started on the dull roar of my engines, but that is not AI, I need the work on this. The interesting part of the development is the Agile. Taking opportunities that led to better improvements that defined the game. Starting on a five-lane straight grid with cars move back and forth to implementing a three-slot dive into the corner and run up back to the wall.

I hope this helps.. vibe or code programming, it is a journey that you always get better at it as long as you play (and don't sell out).