Two months ago, I walked away from a $120k Scrum Master role. Here's the wake-up call that changed everything.

The Breaking Point:

I was in my 4th retrospective of the week (yes, you read that right - I was "Scrum Master" for 4 teams). Same complaints, same action items that never get addressed, same people checking their phones.

Thats when it hit me: I had become a professional meeting facilitator for teams that didn't want to improve.

The Scrum Master Illusion:

Servant Leader = Meeting Secretary

My calendar: 32 hours of ceremonies per week. Time spent actually helping teams improve? Maybe 3 hours if I was lucky.

Impediment Removal = Jira Admin

"Can you move this ticket to the right column?"

"Why is our velocity dashboard broken?"

"Can you set up another meeting to discuss this meeting?"

Coaching = Repeating Scrum Guide Quotes

Team: "Our retrospectives aren't helping"

Me: "Well, the Scrum Guide says..."

Team: eye roll

The Uncomfortable Questions I Started Asking:

Why do these teams need a dedicated person to run their meetings?

What happens if I take a vacation? (Answer: Nothing. Everything runs fine.)

Am I creating dependency instead of self-organization?

If this team was truly agile, would my role even exist?

What I Wish I'd Done Differently:

Taught teams to run their own ceremonies, then stepped back

Focused on organizational impediments, not process babysitting

Challenged leadership when they wanted "agile" without changing anything

Admitted when teams didn't actually need a Scrum Master

The Reality Check:

Great teams don't need someone to remind them to collaborate. They don't need ceremony police. They need someone to fight the organizational BS that prevents them from doing great work.

Where I Am Now:

I'm working as an organizational coach, helping leadership understand why their "agile transformation" isn't working. Spoiler: It's usually not the teams' fault.

Anyone else feel like they're cosplaying as an agile coach while secretly being a very expensive admin assistant?

The company hired me to lead their "Agile Transformation." I don't know what Agile means. Nobody does. That's why it works.

I make $425,000 a year. To move sticky notes. From left to right. On a board. The board is digital now. The sticky notes cost $80,000 in Jira licenses. Progress.

Day one, I said "we need to break down silos." Everyone nodded. Silos are bad. I don't know why. But destroying them is a career. My career.

I introduced "squads." Squads are teams. But disrupted. We disrupted the teams into teams. Different names. Same people. Same problems. But Agile problems now. Agile problems are strategic.

A senior engineer asked what we're actually changing. I said, "The mindset." He asked what that means. I said, "It's a journey." He asked where we're going. I said, "Toward agility." He asked what agility means. I pointed at the sticky notes. They were moving left to right. That's velocity. We have velocity now.

The VP of Engineering said two-week sprints don't fit their work. I said, "That's waterfall thinking." Waterfall is bad. Like silos. I don't know what waterfall is. But I know it's bad. She stopped talking. Waterfall accusations end conversations.

We had a retrospective. In the retro, we discussed what went wrong. Everything went wrong. We put it on sticky notes. Then we moved the sticky notes. Into a column called "Parking Lot." The Parking Lot is where problems go to die. It's full. We don't look at it. That's agile.

Velocity is up 40%. I defined velocity. I also defined the points. I also defined the stories. We're crushing it. At the things I made up. To measure. Ourselves.

The CEO asked for ROI. I showed a chart. The chart went up. Charts should go up. This one did. I didn't label the Y-axis. Nobody asked. Leadership is confidence.

We do standups now. Every day. We stand. For 45 minutes. Standing is agile. Sitting is waterfall. My legs hurt. But we're transforming.

The transformation is now "Phase 3." Phase 1 was assessment. Phase 2 was implementation. Phase 3 is "continuous improvement." Continuous means forever. Forever means job security. I'm very secure.

My contract was extended. Three more years. For "cultural impact." The culture is confused. But impacted.

Agile transformation isn't about being agile. It's about transforming. Continuously. Toward more transformation. The destination is the journey. The journey is billable.

Source: https://x.com/gothburz/status/2002786661608874443?s=48

Three weeks ago, I finally admitted what I had known for months: I wasn't building products. I was maintaining to-do lists for engineers.

The Breaking Point:
Sprint planning #47. Same conversation:

• "What's the business value of this story?"

• "Um... the stakeholder said it was important?"

• "What success metrics are we tracking?"

• "Well... completion rate?"

That's when I realized I had no idea what problem we were actually solving.

The Product Owner Theater:

Vision = Last Quarter's Roadmap Copy-Paste
My "product strategy": Whatever came out of the quarterly business review, reformatted in Jira.

Prioritization = Whoever Yelled Loudest
CEO's pet feature? .
Sales emergency? .
Actual user research? "We'll revisit that next quarter."

User Stories = Technical Tasks in Disguise
As a user, I want the database to be optimized so that... wait, why would a user care about database optimization?

The Questions That Broke Me:

• When did I last talk to an actual user?

• Can I explain our product's value proposition without using buzzwords?

• What would happen if we stopped building features for 30 days?

• Am I a product owner or a feature factory foreman?

What I Should Have Been Doing:

• Spending 50% of my time with users, not in internal meetings

• Saying "no" to features that don't solve real problems

• Measuring outcomes, not outputs

• Understanding our business model beyond "build stuff, get money"

Most "Product Owners" aren't owning anything. We're middle managers translating stakeholder wishes into engineer tasks while pretending user stories make it "agile."

Where I Am Now:
Taking a UX research role to actually understand users before I ever claim to represent them again.

Anyone else tired of being a requirements translator instead of a product strategist?

Maybe I will be called a pariah but in my 10+ years working in larger tech companies I’ve never seen agile done properly and here’s the reasons why:

• ⁠Management doesn’t understand that the triangle looks different to what they’re used to. In classic Management you have a requirement, do analysis and then plan for cost and time. They don’t get that in agile you usually have capacity and time and then figure out the scope. Now with „agile“ they believe they can get cost and time estimates but without requirements. That fails. And they tend to misuse it as an excuse to always move the goal posts and introduce scope creep on the fly. Agile principles are not honored, and agile rituals are seen as a waste of time. Same with Scrum Masters or agile coaches. Could hire more devs for that money. It also almost always shows in the type of KPIs that are implemented to „control“ agile orgs. Then, when everyone realizes that they don’t always get what they want when they want it they introduce some weird hybrid approaches where they try to introduce some waterfall-type things like quarterly planning 3 quarters ahead. That usually doesn’t make things any better because the uncertainty is still sky high but now we have „planned“ it so there’s something I can tell the board.

• ⁠the rest of the company and the world doesn’t work agile. Managers need forecasts which they will be measured against and sales wants to know what they will be able to start selling today for in 12 months.

• ⁠customers aren’t agile. They want to know what’s coming when. What they’re committing to today because it might cost them millions to implement a solution, train staff, adapt processes. They want cristal clear dependable information. Or they won’t buy. And they hate continuous delivery. They want stable releases that they can train their people on. Every change is a pain in the ass, especially if it changes any workflows, processes or data requirements. Especially without formal warning ample time ahead. Like 3-6 months.

• ⁠Teams. I’ll be honest here: in my experience most teams actually don’t want ownership and empowerment. They don’t want to be part of the solution process, they want to know what to do so they can immerse themselves into technical problem solving. Usually they’re just not interested in the why, they don’t see themselves as subject matter experts and also don’t want any responsibility or accountability. Ideally they want detailed, written out specifications they can then break down into technical implementation tasks. They don’t want to come up with the solution. All they want is an option to say no to avoid all those things I mentioned above. I know a few honorable exceptions to this, developers that actually want to solve real world customer and business problems but they are few and far in between.

I still think there are some use cases where agile makes a lot of sense. But that’s not in the majority of companies out there. That’s either fast moving early start ups on their way to an MVP or huge corporations that can have a few teams run loose to see what the outcome will be. The rest? Not so much.

That’s my summary after 10 years of working in „agile“ development organizations in fairly large B2B space companies.

I’d love to hear your positive examples to debunk my claims but that’s where I‘m at currently.

Edit: I forgot two things: In bigger features it’s usually not possible to break everything down into small enough chunks. Like building an ETL and data import tool. The groundwork alone takes months. Classic project management would be way more efficient in my mind

Secondly again teams: usually teams are seldomly truly „full stack“ and individual team members have different skills and areas of expertise. So the whole „take the story from the top“ doesn’t work very often as you encounter ressource conflicts within a team itself. Agile is describing a very ideal setting and I have never ever seen anything come even remotely close to it

I'm a technical, Sr Scrum Master with 9 years of experience. I've worked in startup settings successfully implementing the scrum framework from scratch as well as enterprise settings, coaching in a scaled Agile environment. I've helped educate teams new to scrum and worked with C-suite roles to map out agile transformation roadmaps for their organizations.

The previous company I was at laid off the whole department in February 2023. This was a devastating blow. Since then, I have been applying to jobs. Every job on Indeed has 800+ applicants. I have received only a handful of interviews. However, despite good feedback, I haven't landed a role. I'm either told that the role was cancelled or their budget for the role is much, much lower than my salary expectations. I understand sometimes you need to take a pay cut but at the same time - the pay cut is enormous and I don't want to undervalue the experience I bring. All of the companies I've met with are new to scrum and going through (expected) growing pains... but I know the work it takes to get to maturity and the salary they've budgeted doesn't align with the enormous effort I'd be giving. I've been meeting bills (thankfully) by working with a family member on their real estate business.

This is a shot in the dark, but I thought to reach out to the community. Is anyone's company currently hiring for a SM position where the rate is reasonable for a senior level SM?

I wrote this guide to share exactly how I studied and passed the Professional Scrum Master I certification, and how you can too. Let's get started!

What is Scrum?

Scrum is a framework that helps teams work together to solve a complex problem. It's primarily used in software development and encourages teams to self-organize, keep progress transparent, and continuously plan, reflect, and adapt.

Whether you're just learning what scrum and agile mean for the first time, or you already work in a team that uses these principles, it may be worth it to get scrum master certified to both learn these principles and prove your knowledge to employers. My goal for taking it was to get familiar with the agile methodology and serve as an accomplishment on my resume for job hunting.

This certification costs $150, has no requirements, and is taken online.

Note that the certification I passed was the PSM I certification, not the CSM. They are different - I generally recommend the PSM as it doesn't require you to complete an expensive training like the CSM.

My Process

I dedicated three days for studying - here is everything I did to study for the exam broken down by day. I spent 4-5 hours per day on these tasks.

Day 1

• Read the Scrum Guide, an 18 page document written by the founders of Scrum. This is the main document that the exam is based on

• Re-read the Scrum Guide, taking detailed notes this time

• Go over the Scrum glossary and take notes. These terms are referred to in the exam so make sure you know them

Day 2

• Review Scrum Guide notes

• Review Scrum Glossary notes

• Do the Scrum Open Assessment. This is a 30 question practice exam from the official Scrum organization [Scored 75%]

• Do Mikhail Lapshin's practice quiz in learning mode [Scored 78%]

• Do Mikhail Lapshin's practice quiz in real mode [Scored 93%]

• Valentin Depsa's Udemy Course, sections 1-9. This was great to visualize the material from the Scrum Guide and see it in practice

• Valentin Depsa's practice exam #1 [Scored 85%]

Day 3

• Review Scrum Guide notes

• Review Scrum Glossary notes

• Review notes from practice exams

• Valentin Depsa's practice exam #2 [Scored 82%]

• Do the Scrum Open Assessment a second time [Scored 92% this time]

• Take the exam [passed with 97.5%]

Tips for the exam

If you follow what I did, you'll be more than ready for the exam. Here are a few additional thoughts I want to stress:

• Look over your notes each day to reinforce the material

• Note what questions you got wrong from practice exams (either in flashcards or jot them down) to review so you don't make the same mistakes on your certification

• The main material of the exam is the Scrum Guide. I highly recommend reading this at least 2-3 times and knowing it well

Conclusion

You now have all the tools and resources you need, along with a detailed process you can follow or refer to. Go get that certification!

If you have any questions feel free to DM me on reddit or twitter (@nutlope), or just comment below!

There, finally I said it. I am writing this not to offend scrum masters, but I am writing to share my views which gathered over time. I believe and practice that scrum or any other framework, tool, methodology is a tool that can be learned and applied by any individual in the team. I believe that people can volunteer to take responsibility for the process or elect someone if there is more than one option. And I see how well self organized teams perform, so scrum master is not a prerequisite. Actually the most successful teams I have observed or worked in, had no scrum master.

10 times out of 10 I would hire more engineers, designers, product owners instead of having a scrum master in the team(s).

Finally, I am interested to see if similar view is shared in broader community or it's only my silly thinking.

Hey all -

Recent college grad here. Looking to make the transition into Product Management.

Had the chance to interview a Product Manager at Microsoft in the Azure cloud services organization. I specifically focused on asking questions about his day to day as I really wanted to understand what a PM does.

-------------

What does an average day look like?

Every day is different, but I generally spend my time doing one of three things:

1. Creating clarity on what to build

2. Guiding Execution

3. Reporting Progress

The role is highly collaborative so I’m constantly partnering with Engineering, Design, and PM colleagues. On an average day, I’ll have at least 3 meetings. Here’s what it looks like:

At the start, I meet with my Engineering Manager (EM) counterpart for an hour. We discuss our roadmap and realize we may need to cut a couple features because some work took longer than we planned. We review our backlog and discuss potential features to cut. I agree to get customer feedback to revise our prioritized list of work if necessary.

Before my next meeting, I review customer feedback and notice there’s a bug in one of my features. I contact the customer via email to provide a workaround and add a task to our team’s backlog. I reply to a few emails before my next meeting: a 15 minute stand up with the engineering team.

We discuss the current status of work in progress. One engineer has a question about a feature and I realize the requirements could use a bit more detail. I set up a working session for later in the day to clarify what needs to be done.

In the hour before my next meeting, I continue my work on a new feature. I need to provide feedback on mock-ups from our designer. The options look great! I leave some comments and set up a meeting with the designer to review the final decision. I also schedule a meeting for the following week to get feedback from engineers and other PMs on the team.

Next, my EM and I meet with a team we are partnering with to deliver a feature in a couple months. The other team explains that there will be a two week delay because some higher priority work came up. We decide on a new timeline and agree that the project is not significantly at risk.

To wrap up my day, I review a PowerBI dashboard that displays usage data for a feature we released 3 weeks ago. 40% of users have adopted the feature and 95% of user surveys are at least 4 out of 5 stars. This is great news! Our target is 50% adoption within 3 months and 90% ratings of at least 4 star ratings. I write a status update, include screenshots of the report, and send it to my manager and our engineering team.

After I finish the meeting to clarify the work discussed during standup, I write some SQL queries to gather data to support another feature I’ve been working on. I end the day noting my thoughts on how the data highlights the problem we are trying to solve.

What does a non-average day look like?

I have no meetings! I may spend the day refining my specs, scheduling talks with customers and planning our roadmap. On days like this I like to do big picture thinking and develop the vision for my feature area based on new market research or customer feedback. My vision document includes details on what I think are the biggest opportunities for my team to improve our product for customers.

Sometimes I’ll block my calendar for an entire week with back to back interviews or focus groups with customers. I develop a combination of questions, design mocks, prototypes, and surveys, then partner with User Research, Design, Engineering, and PM peers to execute a research study. I use the results of these various activities to discover the biggest challenges my customers face and add new ideas to my product roadmap and vision document.

What’s your favorite part about the job?

I love working with people and building consensus. It feels good when I get to talk to customers and we reach an understanding about how my product can serve them better. I enjoy when I can take that feedback along with product data to create alignment on what my team should build. Holding a meeting with multiple stakeholders and getting to see the nods of agreement as we develop a collective vision of success is energizing.

It’s also great to look back after a feature has been shipped and recognize the impact that has been made for customers. It feels good when I’m reviewing customer feedback and the comments express gratitude for my feature and how it helped them.

Are there things you don’t like about being a PM?

Project management! This often involves tracking bugs, and features in backlog management software as well as writing status reports for my team and partners. While I don’t love this part of the job, I appreciate the value it provides in keeping the team on target and communicating our progress. Without this work it would be difficult to manage all of my responsibilities.

What advice do you have for someone young (or old) looking to build a career in Product Management?

Go build something! Product management is one of those things you have to learn by doing, so go build something, anything, for someone else. As you're building it, resist the urge to start with the end product. Instead, focus on what problem you are solving and why. Talk to a representative customer, discover their needs. And before you start building, think carefully about how you’ll measure success. Going through this process will give you experience with the essence of product management.

If you already have experience like this, great! Prepare your resume with results-based bullet points about your experience. Read the book, “Crack the PM Interview”, and practice interview questions with an experienced product manager. Then use your network (or build one) to get referrals into your target companies. My MBA program helped guide me through the resume preparation, interview practice, and networking process. Without an MBA program, all these things are possible, it will just take some persistence.

I noticed you studied Computer Engineering (and also worked as a Software Engineer) and now you work as a PM - how important is this technical grounding you have to your role? Could someone succeed without it?

My technical background is important to the extent that it is a part of me. Each PM has a different style and mine is based on my blend of technical and business experience. On a typical day, I communicate with both technical and non-technical teammates, go deep on technical discussions to unblock my team, and perform data analysis to measure success. And these things are not the essence of PM - the essence of PM is solving problems in a way that creates value for both customers and the business. If someone is comfortable learning from and communicating with the technical stakeholders involved in product development, they can succeed.

That being said, a product manager who builds machine learning models for a social media application may need more technical skills than a product manager who builds the web interface for an e-commerce application.

Previously, you founded a startup (Hansel). In what ways is being a product owner at Microsoft similar to building something from scratch?

PMs and entrepreneurs both need to understand who their customers are. I had my first experience running focus groups for my startup and I’ve executed several more since becoming a product manager.

Both also need to understand the market and the competition. As a founder, I spent a lot of time researching, speaking to, and using products of competitors. As a product manager, I don’t often get to speak to competitors or use their products directly, but I leverage any online resources I can find to learn about their products and what customers like about them.

Finally, both require effective communication with various disciplines. In a big company there are many specialized roles: design, engineering, marketing, sales, legal, research. As a PM you’ll need to work with them all at some point. As a founder you’ll need to perform some if not all of these functions yourself, especially in the early stages. And at some point, you’ll need the help of others to be successful.

Finally, how helpful do you think your MBA has been towards your PM career?

My MBA was extremely helpful in helping me transition from engineering, while providing a foundation of business knowledge to complement my technical background. The MBA provided me with tools to pitch my transferable skills and a network to help me land and succeed in interviews.

Additionally, the MBA taught me how to analyze business opportunities, develop business strategies, and collaborate effectively with cross-functional teams. I use these skills daily to be effective as a PM and an MBA is just one way to gain them.

----

Hope this was helpful! The full interview with nice illustrations is available here. Maybe you'll also enjoy my conversations with the CEO of a startup or Data Scientist at Uber.

Any questions and I'll be in the comments :)

Agile development is a disaster. It’s a total failure. Nobody knows what they’re doing. They have these sprints, they call them sprints, but they’re more like crawls. They’re so slow. They’re so behind. They have no plan. They have no vision. They have no leadership. They’re just wasting time and money. And they’re making terrible software. Terrible. The worst software you’ve ever seen. It’s full of bugs. It’s full of errors. It’s full of problems. It’s a nightmare. It’s a disgrace.

I know how to make great software. I make the best software. Nobody makes software like me. I have a very simple method. It’s called winning. Winning bigly. I have a team of winners. They’re very smart. They’re very talented. They’re very loyal. They do what I tell them to do. And they do it fast. They do it right. They do it beautifully. They make software that works. That works perfectly. That works amazingly. That works like magic.

That’s why I’m the best at software development. That’s why I’m the best at everything. That’s why I’m your favorite president ever. Thank you, and God bless America.

At this stage, I'm starting to think ChatGPT is deliberately mocking him in the style of Alec Baldwin on SNL

I’ve been thinking about this a lot lately.

In my current job, we follow Agile, or at least that’s what everyone says. We have stand-ups every morning, sprints every two weeks, retros, the whole thing. At first, I thought it was great.

Structure is good, right?

But over time, it started to feel like we were just... going through the motions.

Standups turned into status meetings. Retros became a place where people complained, but nothing ever changed. team broke tasks into “user stories” just to fit into Jira, even if it didn’t make sense.

We talked about “velocity” and “burn-down charts” more than we talked about what the customer actually needed.

Honestly, feel like we and probably a lot of other teams out there are just doing Agile because it’s what everyone else is doing. Because it looks organised. Because clients expect it. But somewhere along the way, we lost the why behind it.

Agile is supposed to be about adaptability, but for us, it’s become a checklist.

Not blaming anyone, I think it just happens over time.

Standups, retros, sprint planning… the mechanics are easy. You can learn them in a day.

What nobody really tells you is that the real challenge is getting people comfortable enough to actually talk about what’s slowing them down. It’s easy to say “blocked by X” but it’s much harder to admit “I don’t fully understand this task” or “we keep overcommitting because we don’t push back”.

In every team I’ve worked with, the breakthrough moment wasn’t a new board setup or a clever backlog trick. It was when people started trusting each other enough to be honest in those small daily conversations. That’s when Agile actually starts to feel like it works.

Funny thing is, the framework just gives you the excuse to talk. The real work is making sure those talks actually mean something.

• Sprint Planning now takes just 30 minutes - compared to over an hour in teams I’ve worked with in the past where detailed estimation was the norm.

• We now determine the size of work items based on experience and shared understanding. Over time, the team has gotten better at splitting work into smaller, more manageable pieces that can realistically be completed within a sprint. With story points, they would use it as a crutch to keep tickets large, ‘let’s just size it at 8 points’.

• The biggest shift, though, is in mindset. The team no longer measures success by the number of tickets or story points completed.

Instead, the focus is on outcomes. In the past, there was a tendency to become emotionally attached to tickets, and success was often equated with velocity. Now, it’s about delivering real value.

Early 2023s, small fintech startup. Deadline: 4 months to launch. Engineering team was literally 3 people. Me as architect, plus two devs. We had our shit together. Architecture designed, infrastructure running in the cloud, backend skeleton ready.

Devs were building features. We were on track. Then month 2 hit and management started hiring. A bunch of managers showed up. Then they brought in a Scrum Master. First week this guy wants to implement full Agile ceremonies.

Daily standups, sprint planning, retrospectives, backlog refinement. The whole package. His reasoning: "You need process to scale." We had 8 weeks left.

We weren't trying to scale. We were trying to finish. I've seen this same pattern play out multiple times now. Small team shipping. Management gets uncomfortable with lack of visibility, they hire process people. Process people need to justify their existence, ceremonies get implemented and everything slows down.

The thing that kills me is the timing. We were working. Why fix what isn't broken when you're 8 weeks from deadline? I'm genuinely curious, why can't management just leave working teams alone? Is it actual concern about sustainability or is it just discomfort with not having control mechanisms in place?

What's your experience with this?

Context: I’m a scrum master. My work day is busy all day long. Yes, I host meetings and take notes (team secretary and fun committee all rolled into one!) but I also am proud of my involvement in the details and help people all day long. I don’t write code but I burn bugs, build poc’s and reports, run projects etc. I’m just starting to freak out that jobs are moving away from the title of SM and more into product ops or business analyst, neither of which are titles I possess. What’s my future guys? Am I screwed?

Today is 6 months since we dumped Sprints at Teamhood🍾🥂.

All I can say - nothing is being missed, continuous flow towards product goals, laser focus, freed up time from ceremonies are at all time high.

For context, here is the day 0 original post on why did we do this change: https://teamhood.com/kanban/52-sprints-later-win-some-lose-some-scrum-butt-done/

Retrospectives are at the very heart of the Agile mindset. They give your team the opportunity to regularly step back and reflect on their organization so that it keeps improving.

I don’t think anybody here would disagree on the fact that Retros are crucial when it comes to being successful as an Agile practitioner. However, as I got to experiment with it, I eventually stumbled upon the cold hard truth: they’re definitely not performed as they should be.

Without proper guidelines and practices, they invariably tend to turn into a dull, inoperant routine, as teammates start to see it more and more as a complete waste of time. Now, that is one unfortunate discrepancy between what’s in the book and what takes place in reality.

I got to attend tons of Retros during which nobody ever took the floor. The overall atmosphere in the team was not conducive to communication, despite an ongoing project which desperately needed it, that no one was even able to question how the group functioned. Let alone change it.

Simply put, the team completely missed the mark and missed out on a great opportunity. To get the sprint back on track. To quit the fear of actually communicating. To grow together as a team and as individuals.

Retrospectives are a chance for everyone involved to collectively appraise how the team works as a social construct. Doing so, they’re able to spot areas of improvement and get their priorities aligned.

Retros can make or break a team depending on how well they’re performed. Knowing how to pull it off in a productive and impactful way can take you a long way. Here’s my 2 cents on how to make the most out of them.

Tip °1: Do not, EVER, cancel a Retro It can occur that Retrospectives need to get cancelled. And there’s never a good reason. See, “ain’t nobody got time for that, we’ve got to get over with our User Stories” or “Retros are just pointless anyways” are undoubtedly the worst things that could be said.

Why is that? Because they’re symptoms of an even more serious, deeper flaw.

The best way to diagnose it and find a workable solution is twofold: Setup a dedicated Retrospective Use the 5 “Whys” to dive as deeply as possible into the issue

As a facilitator, you need to ensure that all team members participate and that each and every single issue is being addressed. In other words: avoid at all cost having your squad go through yet another “Elephant In The Room”.

Using this method might mark a turning point within your team and its Agile abilities.

Tip °2: Prepare your Retrospectives from Day-1 Retros are THE ideal opportunity for you to learn more about how your mates’ feelings. Do they feel comfortable enough? Is there any concern that needs to be addressed?

The worst thing that can happen, which yet happens 50% of the time, is to let team members forget about how they felt during the first days of the Sprint. Mood is an inconstant thing and chances are your team has been going through a wide array of emotions that needs to be tracked.

My take on this: Do NOT wait until the last minute, a.k.a the Retrospective, to bookmark your team’s mood variations. Gather feedback on a daily basis and be very serious with your data. The quality of your Retros’ outcomes will skyrocket for good.

TeamMood was especially designed for this. It enables Scrum Masters to dive deep into their team’s feelings by surveying members each and every day. The cherry on the cake being that it is totally anonymous, so that participants can speak up freely.

https://www.teammood.com/en/agile-retrospective-tools-ideas/?utm_source=reddit&utm_campaign=retro&utm_support=ownpost

Tip °3: Keep track of past Retrospectives’ action records This piece of advice is crucial. The decisions and actions that ensue Retrospectives need to be tracked. A good idea is worth nothing if it’s not executed upon.

I’ve had the chance (or should I say misfortune?) to attend sessions that were all about blabbering about the very same issues one thousand times on end. Where areas of improvements had already been bookmarked 4 sprints ago. Where it was all play and no work.

Needless to say things didn’t end up well for the team.

The best way for you to prevent this is to make your team accountable for its progress in the long run by making execution a priority.

Ask yourself if what’s been made actually suits the original plan. If not, dive deeper into each situation using the “5 whys”. The end goal is to track down the roots of every problem so that you don’t stop at surface-level explanations. Some food for thoughts here: “I didn’t have time” is one of them.

I genuinely hope that this answer will be of good help. Feel free to catch up with me if you need any point to be cleared up!

I’ve worked with teams that swore by Scrum, others that leaned on Kanban and a few that called what they were doing Agile when it was really just waterfall with new labels. And honestly, what I’ve noticed over and over is that the framework isn’t the real deciding factor.

I’ve seen teams doing textbook Scrum, every ceremony on the calendar, every artifact in place and still failing because nobody felt safe raising issues. I’ve also seen teams running a messy mix of Kanban and weekly check-ins absolutely nail delivery, just because they trusted each other and kept their eyes on outcomes instead of rituals.

That’s what makes me think Agile with a capital “A” doesn’t guarantee agility with a small “a”. You can follow the rules and still be rigid. You can also break half the rules and be more adaptive than most organizations.

For me it always seems to come back to culture. If people don’t feel safe being honest, if the team can’t actually shift direction when reality changes or if leadership isn’t willing to hear hard truths, then no framework is going to save you. Everything else just becomes theater.

Does this sound familiar or am I the only one seeing it this way?

I’m a founder now, but I’ve spent years in engineering and product teams across enterprises. One pattern I keep seeing - ritual of obsessing over ticket status, column changes, and "Done/Not Done" theatrics.

The standups turn into ticket reviews. Retros become blame games. And somehow the actual work becomes secondary to updating the board.

These days, I’m rethinking what clarity and alignment really mean. And maybe it’s less about perfect ticket grooming and more about surfacing blockers and priority signals — fast.

Curious how others here feel ?

After 7 long years of suffering our IT director left and has been replaced by someone who has a clue. Onwards and upwards! Just a little more context - I have had a chat with the new guy and he has had a lot of experience over the years as both a consultant and a contractor. His first action was to get rid of our SAFe consultant who has been with us off and on for the whole seven years!

He has even read Inspired by Marty Cagan, though is not sure that's completely appropriate for our organisation.

Though if he has any sense he will be getting rid of me!

The original spirit and philosophy of agile has been completely lost for so many with so many companies now believing that a scrum-based system with zero agile best practices or cultural considerations is the "definition of Agile". For so many, "going through the motions of scrum" is "being Agile".

Agile is all about a communicative collaborative mindset with flexibility based on feedback... not the mechanics of sprints, tickets, and story points.

I blame this state of affairs on the software to facilitate Agile teams spreading faster than the education on Agile best practices.

Agile needs a Protestant reformation to restore its original intent and to emphasize the spirit over works in terms of getting projects completed, less about process more about mindset.

The current state of the Agile market - based on conversations I’ve had with hiring managers at Fortune 100 companies.

Q: Do you need people to implement agile ways of working?

A: No. We’ve spent the last few years investing in our transformations. Now we just need people to focus on delivering the work.

Q: What would you like Scrum Masters to focus on?

A: Helping to put together delivery plans, facilitating the ceremonies, and making sure the work gets delivered on time.

Q: Is there scope to transform ways of working beyond team level?

A: No. We already have a framework in place and expect people to work within it. Any change can impact programme-level metrics and be disruptive.

My take:

You can complain on principle that the role is no longer transformation-led. But if that stance doesn’t bring food to the table - and companies clearly don’t want it - what’s the point? You are just spreading misinformation and killing people’s livelihoods.

Agile Coaches had the opportunity to coach this properly while leading transformations. Frankly, many messed it up. After all these years, if organisations still don’t understand the Scrum Master role, that failure sits with the people who were meant to teach it and ensure it was implemented correctly.

You can’t spend a decade leading transformations, fail to translate the value in business terms, and then be surprised when leadership reverts to delivery-first roles.

I’ve been working at this company for 10 years, currently as a manager overseeing several IT teams. The company has its own internal IT department building internal products. When I started, we were moving from classic waterfall to Scrum. Like in any big corporation (2,000+ people in IT alone), it was slow and painful.

Demos were basically walking through the backlog and accounting for every single task. Sprints had no real goal. Former analysts became Product Owners, and people with the least actual work were sent to Scrum Master trainings. Dailies were used by team leads to check if everyone was “doing something.” The organization cared about how much we delivered and how late it was - not what we delivered or what value it brought. A textbook “agile transformation.”

But after a few years, real change started to show. POs really dug into their domains and had deep knowledge of customers and competitors. IT invested in DevOps to speed up releases. Architecture evolved from one big monolith deployed 5 times a year into hundreds of independent microservices deployed on demand. Backlogs started to reflect actual customer needs instead of just task lists. Employee engagement scores were well above industry average in every survey. Over all of this watched a transformation department made up of Scrum Masters and change leaders.

Then the board changed.

The new board introduced a new one-year strategy. This strategy had little to do with the product visions owned by individual POs and was pushed into IT through side channels. Chaos followed. Suddenly the board started blaming department directors for not delivering their goals. Directors started holding POs accountable for their existing roadmaps while trying to kill future increments to make room for “the strategy.” At the same time, IT directors bypassed POs entirely and pushed architectural changes under the label of “technical debt.”

Teams ended up with three priorities: one from the PO, one from “the business,” and one from IT. Every delay caused fights between these three sides, finger-pointing, and accountability theater. A year passed. The board’s strategy was not delivered.

So the board decided to fire the entire transformation department (including all Scrum Masters) and introduced “improvement actions” to make sure this would never happen again.

Those improvements included:

• assigning an additional Project Manager to every PO to “help deliver projects on time”

• abandoning story points in favor of estimating every task in days

• limiting time for technical debt and bugs (!) to 10% and strictly enforcing reporting

• hiring additional analysts to create Feature Requirement Documents for every product to “help IT estimate better and improve predictability”

All of this, of course, branded as improving our agile way of working.

That was 6 months ago.

More than half of the teams I know haven’t released a single change to production since then. Some teams still haven’t received FRDs for any change at all - analysts have been working on documentation for 6 months, and IT doesn’t even know what’s in it yet. I personally reviewed one of those documents (they had dependencies on my system) and saw that an FRD for a simple change was already 100 pages long.

At one point they asked me to confirm a single variable. I told them I’d look at it in a month because I was working on something else. They replied that in a month they’d already be assigned to another project and wouldn’t be able to update the document anymore.

I’ve also heard Project Managers explicitly telling teams not to log time spent on technical debt, because we’d burn through our yearly 10% too fast and wouldn’t have any left for “more important bugs” later.

10 years of transformation.
Buried in 6 months.

I’m watching all of this from the sidelines. My department hasn’t gone through the new “transformation” yet and we’re still working the old way - just the team and the PO. We’re the last department in line for the great enlightenment. I’m going to try to use this time to prove to everyone above that the “old” system can still be efficient. Wish me luck - the last island of agility in this waterfall of despair.

In my opinion, the board threw the baby out with the bathwater. After the first year they clearly lost trust in POs and dismantled the entire system instead of trying other approaches. Not all POs were good at their job, and that’s probably the most important lesson I’m taking away from this whole story: being a PO is brutally hard and comes with real responsibility. Not everyone is cut out for it, and not everyone should take on that role. And paradoxically, over the last few months the best POs left, while the worst ones stayed - still pretending to be product owners, even though most of their decision-making power is already gone.