Home / Guides

Agile in management: what actually works beyond the ceremonies

Most teams I've joined already had standups, or some form of management system. What they didn't have was a way for someone to raise a problem without it turning into finger-pointing, or an environment safe enough for people to grow and contribute in.

Agile gets adopted as a set of meetings, because meetings are the easy part to schedule. The part that actually changes how a team performs never appears on a calendar at all.

This guide covers both: the frameworks worth knowing, and the things underneath them that decide whether any of it works.

What is Agile?

Agile isn't a project management method. It's a mindset. Seventeen software practitioners wrote it down at the Snowbird ski resort in Utah in February 2001: the Agile Manifesto, four values and twelve supporting principles.

Here are the four values in the manifesto's own words: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. The twelve principles expand on those. They cover early and continuous delivery, welcoming change even late on, and daily collaboration between business people and doers. Then sustainable pace, technical excellence, simplicity, self-organising teams, and regular reflection on how to get better.

None of that is ceremony-specific. Scrum and Kanban are just two different ways of implementing the same four values.

Different common Agile methods

Compare the different Agile methods and they all come back to those same four values. Scrum, one of the most common ways to organise a team, focuses on structure: defined roles, time-boxed sprints and a team commitment for each cycle. Kanban applies flow: a visual board, continuous delivery and fewer fixed roles, with work pulled through as capacity allows rather than batched into sprints. Neither is "more Agile" than the other, and they complement each other well, because they suit different kinds of uncertainty.

There's never a one-size-fits-all checklist for adopting Agile. It comes down to these principles and how well a team can adapt to whatever situation it's actually in. Agile practitioners are expected to understand the environment they're working in and shape a workflow that fits it.

Scrum vs Sprint vs Epic

These three get used interchangeably and they're very different things. Scrum is the framework that combines people with different skillsets into one organised team. A sprint is one time-boxed cycle inside that framework, usually one to four weeks, at the end of which the team ships something. An epic is a body of work too big to finish in a single sprint. You break it into smaller items and pull those into individual sprints over time.

The role of the Agile coach: servant leader

This is where the leader comes in. The Agile coach, or in a marketing content team more often just whoever runs it day to day, operates as a servant leader. The job is removing obstacles and making sure everyone has what they need to perform, rather than directing the work from above.

Two things make an Agile coach or servant leader effective. First, clearing blockers: finding whatever is slowing the team down and removing it, rather than asking people to work around it indefinitely. That takes real communication, active listening, and enough empathy to see the work through their eyes, because none of it works if you don't know what is actually stopping them. Second, a drive for continuous improvement, or Kaizen: incremental gains rather than big disruptive overhauls. In practice the servant leader gets the team fixing one thing at a time as it surfaces, with everyone able to take part, instead of waiting for a quarterly process review to catch it or handing improvements down from above.

Key Agile artefacts

What I actually build and use, rather than reference once in a meeting: the sprint itself. A service level agreement (SLA) with stakeholders. A team manifesto stating what the team does and doesn't do. A backlog. Value stream mapping to find where work gets stuck, a Lean technique dating back to 1918 and popularised through Toyota's production system. Stakeholder mapping. Retrospectives. And a cadence of 1:1s, standups and scrum meetings that keeps information moving, so nobody needs a meeting just to ask for an update.

These are also the artefacts an AI content system ends up encoding, which is why the AI automation guide reads like a tooling version of this section. I've written on these methods elsewhere too: Applying Agile principles to content design, Using a content designer's strengths to lead retrospectives and How to prevent content ops pain points.

How a team grows: 4 stages

Psychologist Bruce Tuckman named this in a 1965 paper, *Developmental Sequence in Small Groups*: forming, storming, norming, performing.

Forming: the team gets to know each other and understands the project goals, politely, without much friction yet.

Storming: conflicts and differences surface as people assert themselves and test where the actual boundaries are.

Norming: the team reaches consensus on roles, priorities and how they'll communicate day to day.

Performing: the team works collaboratively with minimal supervision, trusts each other, and consistently meets or exceeds its goals.

It takes real time, and there's no shortcut through storming to get to performing faster. But once a team has been through it together, the performing stage tends to hold. That's the payoff.

A real example: joining a new team at Bybit

When I took over a new, fully remote copy team at Bybit, I took my time and observed before changing anything. Everyone had different background stories, talents, motivations and goals. I needed to understand that properly before taking the lead. To achieve that, I set up 1:1s with everyone, alongside regular standups, and I let each team member lead their own 1:1. That was a deliberate decision: I wanted to build trust first, and to work out where I could actually clear a path for them rather than guess at it.

After having understood everyone and their strengths, I organised everyone into squads. Each got a clear manifesto listing what it did, what it did not, and when things were due, so nobody had to guess. Then, I used a value stream map to find where the clutter in our existing SOPs actually sat. Once that was clear, I met the stakeholders and walked them through the changes to get their buy-in, and to understand where the clutter sat from their side, and how I could help. Then, I started retrospectives with the team to find what else needed fixing. Everyone contributed, the points went into a backlog, and every two to four weeks we worked through them to improve how we worked.

The output showed up in numbers I can point at. Turnaround on stakeholder requests got measurably quicker. Morale rose, tracked through the retrospective cadence. And I was promoted twice within 2 quarters, from senior copywriter to Head of Copy and Translations. Later, applying the same systems thinking to the team's AI workflow lifted content production velocity by more than 70% across close to 40 domains.

What ties everything together: psychological safety

None of the above would work without psychological safety, a term Amy Edmondson coined in the late 1990s and one that Google's own internal research later made famous. Project Aristotle studied more than 180 Google teams across 250 variables, and psychological safety came out as the single strongest predictor of team effectiveness. It mattered more than who was actually on the team.

Edmondson is blunt about what this isn't: "Psychological safety is not about being nice. It's about giving candid feedback, openly admitting mistakes, and learning from each other." A team that never disagrees isn't safe. Its members just don't feel safe enough to speak up and be themselves, and both performance and cohesion suffer for it.

Timothy R. Clark's four-stage model breaks psychological safety into four stages: inclusion safety (the team accepts you), learner safety (you can ask questions and make mistakes), contributor safety (you can add value as a full member), and challenger safety (you can question the status quo without risking your standing). A team needs to clear at least stage 2, learner safety, just to function at all. Everything past that is what makes a team capable of actually growing: contributing ideas, challenging norms, and improving continuously through Kaizen.

That's why I always aim for stage 3, and stage 4 where a team can hold it. It paid off. Through the changes that followed and my own promotion, challenger safety was what kept other members questioning the norms and pushing at our boundaries. All of it started with letting people speak.

Most teams that say they've "gone Agile" have adopted the ceremonies and skipped the mindset. They run standups nobody needs, hold retrospectives where nothing gets recorded, and wonder why the process feels like overhead.

What I've found actually moves a team is much less visible than the ceremony. It's whether people can ask a question without feeling judged. It's whether the person running the team spends their week removing obstacles or assigning tasks. It's whether the backlog from the last retrospective got worked through, or quietly forgotten.

Tuckman's stages are worth holding onto here because they set the expectation correctly. A new team will storm, and that's not a management failure, it's the stage where people work out what they actually think. Rushing it produces a team that looks calm and never says anything useful.

1. 1

   Inclusion safety

   The team accepts you and grants you shared identity.

2. 2

   Learner safety

   You can ask questions, experiment and make mistakes without penalty.

3. 3

   Contributor safety

   You can use your skills and judgement to add value as a full member.

4. 4

   Challenger safety

   You can question the status quo and propose a better way without risking your standing.

The artefacts are the proof, not the point

None of these artefacts are the actual goal. Not the manifesto, not the backlog, not the retrospective. They're just how a servant leader makes blockers visible enough to remove. The real measure is whether the team gets faster and more confident over time, and whether people feel safe enough to say something isn't working before it becomes a bigger problem.

Sources

• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Tuckman's stages of group development, Wikipedia (summarising Tuckman, 1965)
• Understand team effectiveness, Google re:Work (Project Aristotle)
• Timothy R. Clark's psychological safety model, LeaderFactor
• Value Stream Mapping, Lean Enterprise Institute