Agile Ceremonies That Actually Work in People Operations
👋 This is a free edition of the MPL Build Newsletter—resources for running your people team like a product team. Become a paid member to get access to guides, templates, case studies, and exclusive AMAs.
This is for every People Ops professional who's been told to "be more agile" without anyone explaining what that actually means for HR teams.
You're sitting in yet another meeting about "digital transformation" and "agile ways of working," nodding along as your CTO explains how engineering teams ship features every two weeks using sprints, standups, and retrospectives. It all sounds very impressive and efficient.
And suddenly you're wondering: What exactly does a standup look like when you're talking about performance reviews instead of product features? How do you run a retrospective on hiring? What's the HR equivalent of shipping code?
The Agile Cargo Cult Problem
Here's what I see happening in loads of organisations: People teams are being asked (or inspired to – and I realise I am a part of this problem!!) to adopt agile ceremonies without anyone thinking through whether they actually make sense for People work, or how to adapt them so they're useful instead of just another meeting that could have been an email. This results in folks going through the motions of standups and sprint planning without understanding why these ceremonies exist or how to make them valuable for People work.
You end up with daily standups where people awkwardly report on "yesterday I reviewed three CVs, today I'm going to review four CVs," and sprint planning sessions that feel like elaborate ways to plan your already-planned recruitment pipeline.
It's agile theatre, not agile thinking.
The Real Question we need to ask is: What Problems Are These Ceremonies Actually Solving?
Before we start scheduling more meetings, let's step back and think about why engineering teams use these ceremonies in the first place:
Standups create visibility to catch blockers early
Sprint planning aligns the team on priorities and capacity, resourcing, and sequencing
Retrospectives capture learnings and improve processes
Goal planning gathers feedback and prioritises the team’s next step
The thing that is most important isn't in the specific structure or traditionally frameworks of the ceremonies themselves. It's in solving coordination problems, maintaining momentum, and continuously improving how work gets done. HR teams absolutely have coordination problems, momentum challenges, and processes that need improving. We just don't always think about them the same way as engineering and product teams, and being inspired but not necessarily being identical helps us address this.
When Agile Ceremonies Actually Make Sense in People Ops
Not every agile practice translates to People work (please don't make your recruitment team write user stories for their weekly phone screens). But some ceremonies can be genuinely useful if you adapt them thoughtfully… Sprint-based work makes sense when you're:
Rolling out new people programmes or policies
Running structured projects like compensation reviews or engagement initiatives
Implementing new HR systems or processes
Working on cross-functional initiatives that need regular coordination
Traditional project management makes more sense when you're:
Handling ongoing operational work like recruitment pipelines
Managing individual employee issues or coaching
Doing compliance work with fixed deadlines
Running annual processes like performance cycles
Three Product Management Ceremonies That Actually Work (When Done Right)
Let me walk you through three agile ceremonies that I've seen People teams use effectively, along with the specific adaptations that make them valuable instead of just more overhead.
1. The People Ops Sprint Planning: "What Can We Actually Ship This Quarter?"
The situation: Your team has seventeen different initiatives competing for attention, from updating the employee handbook to launching a mentorship programme to fixing the broken expense system.
Traditional approach: Try to work on everything simultaneously, make slow progress on all fronts, and wonder why nothing ever seems to get done.
Agile approach: Pick a limited set of initiatives that your team/squad can actually complete in a 12-week cycle, commit to them fully, and ignore everything else until they're done.
Definition of done: Setting an output based goal for the end of the 12-week cycle. New hire satisfaction scores improve by X% and time-to-productivity decreases by Y days
Why it works: Forces you to be realistic about capacity and actually finish things instead of having fifteen half-done projects.
2. The Weekly People Team Standup: "What's Blocking Our Employees?"
The situation: Your team is handling multiple employee issues, system implementations, and programme rollouts, but nobody has visibility into what's actually happening or where help is needed.
Traditional approach: Wait for things to escalate, discover problems after they've become crises, and duplicate effort because people don't know what others are working on.
Agile approach: Brief weekly check-ins focused on employee-impacting work and removing blockers.
What this looks like in practice:
Format: "What was my progress this week, what problems are on the horizon, and what are my plans to get through them?” (PPP Meeting structure)
Focus: Employee impact, not task updates ("I helped resolve the benefits enrolment issue affecting 23 people" vs. "I answered emails")
Timeboxed: 15 minutes max, anything longer becomes a separate conversation
Why it works: Creates early warning system for employee issues and prevents work from falling through cracks.
3. The Monthly People Ops Retrospective: "What's Making Employee Experience Better (or Worse)?"
The situation: Your team keeps encountering the same problems, processes that seemed like good ideas aren't working, and you're not sure if your initiatives are actually improving the employee experience.
Traditional approach: Power through problems assuming they'll resolve themselves, or wait for annual planning to address systemic issues.
Agile approach: A deep-dive and reflection on what's working, what isn't, and what to change.
What this looks like in practice:
Start, Stop, Continue: What should we start doing for our team in this situation? What should we stop doing? What's working well? What lead to this?
Data review: Look at available qualitative and quantitative data, time-to-hire metrics, retention data etc.
Process improvements: Identify 1-2 specific changes to try in the next month to the ways of working, and flag them as items to discuss in stand-up.
Why it works: Turns improving our team’s ways of working and experience into a continuous practice instead of an annual event.
The Key: Adapt, Don't JUST Adopt
Here's what I've learned from teaching and leading People teams as they implement agile approaches to their work: the teams that succeed don't just copy engineering practices wholesale. They take the underlying principles (transparency, continuous improvement, focus, collaboration) and adapt them to People work.
The teams that fail get caught up in the rituals without understanding the purpose. They end up with standups about recruitment metrics and sprint planning for compensation reviews, missing the point entirely.
If your team struggles with focus and finishing initiatives, sprint-based work might help. If you're constantly firefighting employee issues, standups might create better visibility. If your processes aren't improving, retrospectives might help you learn faster. The question isn't whether your People team should be "agile." It's whether adopting some agile practices will help you deliver better employee experiences more consistently.