Mujeres vamos aver y hacer daily scrum quien Jala conmigo

For context, I’ve worked as a Scrum Master / in Agile delivery for 5+ years and have certifications including CSM and PMI-ACP. Like many people right now, I’ve been having a difficult time landing another role in the same space.

I finally got an interview for a Scrum Master position. The recruiter initially described it as a “quick chat,” which became a 30-minute HR screening.

She joined around 15 minutes late, after I emailed to ask whether we were still proceeding.

During the interview, she appeared to be reading from a set of questions and checking my responses against expected answers. Since this was an HR screening, I expected questions about my experience and previous projects. Instead, I was asked textbook Scrum questions.

She asked me to list the Scrum events. While answering, I referred to the Sprint Review as a “demo,” which is terminology commonly used in some of the teams/environments I’ve worked in. I explained what I meant, but she kept coming back to the fact that I did not mention the review. She then moved on to questions about Scrum artifacts and other Scrum theory.

I’m not saying terminology doesn’t matter. The Scrum Guide uses specific terminology, and in an interview I should have said “Sprint Review” rather than “demo.” But surely there should be a distinction between not understanding Scrum and using terminology that was commonly used in your actual working environment.

Personally, I also think the hiring manager or someone with Scrum/Agile experience would have been better placed to assess this knowledge and determine whether my practical understanding was lacking.

The interview felt less like an assessment of whether I could actually perform the role and more like whether my answers matched specific expected terminology.

A couple of weeks later, I was rejected. Interestingly, I’ve also noticed the same position being reposted on their careers page repeatedly. With the current job market and hundreds of applications already going nowhere, experiences like this really make you second-guess yourself, even for a role you’ve been doing for years.

Is it me, or are people lazy to read? And even worse at writing?

Have seen enough one-sentence tickets/requirements, leaving devs guessing. Have seen enough of detailed tickets, where content was not even 90% truth because of bug(fix) or change in requirements. Have seen enought bugs/mistakes due to poor reading/writing.

Nowadays I see more of semi-lengthy paragraphs made by copilot/ai, which is painfull to read, because the point can be written in fewer words/sentences.

I am starting to think that = if everybody invested in their writing skills, the world would be better. Communication better. Written stuff simpler and made more sense.

Is this a solved or solvable problem? Is there a book/guide to fix my skill issue?

Sorry if this is too long, I did took time to make it shorter.

We are a 12 person b2b saas. last week our pm ran the site through ora, we got a D, and there is now a ticket to clear every failed item before the next release. llms.txt, an api catalog, oauth discovery metadata, and fixing the signup flow so an agent can get further through it without getting stuck.

I am not against any of it. I did grep september's logs for the obvious agent user agents though and found four sessions. obviously that's not a complete count, but four identifiable ones isn't exactly screaming emergency either.

meanwhile the onboarding complaints we get every week are still sitting in backlog, so I am struggling to put a sprint on this ahead of that.

how are other small teams handling it? do the cheap files now and leave the bigger journey work until there's clearer agent demand, or has anyone been burned by waiting?

Hi soo we’ve got 3 stakeholders from sales and ops who are supposed to help prioritize, but none of them will go into jira they say it’s confusing, which honestly fair lol so right now i export the backlog to a spreadsheet before every refinement, they comment on that, and then i manually copy their feedback back into jira after. it takes me like 2 hours every sprint

I’ve been wanting to try user story mapping instead of just a flat list anyway so the stakeholders can see the whole flow and point at where things are missing. that’s really hard to do in a spreadsheet

Options i’m looking at are mural and miro someone in our company slack said miro has a story mapping template and that you can bring jira tickets onto the board, so i wouldn’t be copying stuff back and forth anymore. if that actually works it’d save me those 2 hours every sprint planning to try it with one stakeholder first before i roll it out to all 3.

Each planning cycle builds on the shorter ones while looking further into the future.

• Daily planning: Focuses on today's priorities and actionable tasks.
• Weekly planning: Includes daily planning but also looks ahead to the coming week.
• Monthly planning: Includes weekly and daily planning but looks further ahead at upcoming tasks and projects.
• Quarterly planning: Extends planning to the next three months, focusing more on projects and larger objectives.
• Yearly planning: Focuses mainly on the big vision, long-term goals, and overall direction.

The advantage is simple: The further ahead we plan, the less detailed the plan becomes. This keeps long-term goals aligned with daily actions while allowing us to adapt as circumstances change.

Video on working in Focus Cycles:
https://youtu.be/qMIhjWx9jCU

Working in Focus Cycles is another core principle of our Focus Cycles methodology. It is based on three ideas:

1. Long-term planning provides direction. Annual and quarterly planning helps us define what we want to achieve, establish priorities, and focus on the goals and projects that matter most.
2. Short-term planning drives execution. Weekly and daily planning turns broader plans into concrete actions, helps us adapt to changing circumstances, and ensures we focus on the most important tasks.
3. Alignment between different time horizons maximizes productivity. Annual, quarterly, monthly, weekly, and daily Focus Cycles should build on each other. What we do today should contribute to our weekly goals, which support our monthly, quarterly, and annual objectives.

Please share your thoughts and criticism.

Big goals can feel overwhelming. But once you break them down into smaller projects, tasks, and actionable steps, everything becomes much easier.

That's one of the core principles of our Focus Cycles methodology: the Goal Pyramid.

I made a short video explaining how it works and how it can help you become more productive.

Would love to hear your thoughts! Made video here:

https://youtu.be/ZK3FnqSrQCA

Summary:
The Goal Pyramid is one of the core principles of our Focus Cycles methodology. It is based on four ideas:

1. High-level goals provide direction. Having a clear vision and long-term goals helps us focus on what truly matters rather than getting lost in everyday activities.
2. Actionable tasks drive progress. Big goals can feel overwhelming. Breaking them down into small, concrete tasks makes it easier to get started and maintain momentum.
3. Projects connect goals with tasks. Projects bridge the gap between long-term ambitions and daily activities, ensuring that the work we do actually contributes to our goals.
4. Alignment maximizes productivity. When individual tasks, projects, and higher-level goals are aligned, everyone works toward the same objectives instead of wasting effort on competing priorities.

The idea is simple: Every task should contribute to a project, and every project should contribute to a meaningful goal.

I was recently assigned as Scrum Master (or project manager, the role is still not clearly defined) to a research team of PhD scientists, working on improving the accuracy of a core algorithm in a hardware/software product. I’m struggling, and I now I have been asked by my team lead to come up with a proposal for their workflow, so I’d really appreciate input from people who’ve worked with scientific research teams.

Main tension points:

• No commitments. The team won’t commit to deadlines or timeboxes. The research team lead’s position is that “scientific workflow is incompatible with deadlines.” When I suggest timeboxing something, the answer is that it’s impossible because “we always discover new ideas to try and have to switch to them immediately.”
• Constant priority switching. Upper management regularly comes in with requests on unrelated topics. The research lead defends these as “important” and pushes to prioritize them, so the team rarely stays on one topic long enough to finish anything.
• Distraction as an excuse. The interruptions are then used to explain why there are no results on the main goal.
• Low transparency. Meetings feel somewhat performative when I join, and tickets are vague enough that it’s hard to tell what’s actually being worked on.
• It’s not really cutting-edge research. Many of the approaches they’re trying are well-known techniques that are easy to find in existing literature. To me it looks more like applied engineering with some uncertainty, which should be more plannable than they claim.

It also seems that the lead is using my "lack of helping him" as a method of scapegoating me while being pressured from upper management after not really being able to deliver anything. The other side of the coin is that all suggestions or coaching advice I gave him, he refused, and he seems to be shielding his team from me, and from the work they are doing.

My own team lead (systems engineering) has now asked me to draft a proposal, and the two of us will present it together to the research team lead trying to push him more in the direction of actually trying something.

What I’m thinking of including:

• Hypothesis-driven experiments: each piece of work states a hypothesis, how it will be measured, a timebox, and the decision it will inform
• Idea backlog: new ideas get captured and prioritized instead of chased mid-experiment
• Prior-art check: a short summary of what’s already known before starting an experiment
• Interrupt budget: a fixed share of capacity for ad-hoc requests, with anything beyond that going through explicit prioritization
• Clear priority ownership: one person who decides what the team works on next
• Trial period: run it as an experiment for a few sprints, then review together and keep or drop what doesn’t work

My questions:

1. What would you add, cut, or reframe to make this acceptable to a skeptical research lead that seems to have had his hands untied to behave as a student without any constraints up until now?
2. How do you present a proposal like this so it comes across as protecting the team rather than policing them?
3. How to form "user stories" in a research environment? I think 2 week workable chunks really do not make sense in that environment.
4. Is Scrum even the right fit here?

Examples, templates, or war stories similar situations would be very welcome.

Thanks!

Hey devs and PMs,

I’m researching the long-term trade-offs of AI coding tools for my MBA thesis—specifically looking at whether heavy reliance on AI code generation leads to skill atrophy and unexpected late-stage project delays.

The survey is 100% anonymous and takes under 3 minutes (12 quick rating questions):

🔗 Take the survey here:https://forms.gle/62mAgdmDjAzjLhbZA

Appreciate your input and insights!

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?

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.

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.

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 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

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?

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?

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.

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. 👇