Most teams know how to start a project. You write a charter, hold a kick-off, and get to work. Launching a Scrum team requires something different, and treating it like a project kick-off is one of the more common ways organizations undermine a new team before it ever ships anything.
What a Traditional Project Kick-Off Actually Does
A project kick-off is built around a charter, the document that captures what everyone agreed to before work began. It defines what is being built, by when, for how much, and who has decision-making authority. Stakeholders are named, constraints are documented, and assumptions are captured. The kick-off is where the PM presents it to the team. Everyone leaves knowing the scope, the timeline, and what success looks like. Then work gets assigned and execution begins.
That model works well for what it is. The problem starts when you apply it to something it was never designed for.
What Launching a Scrum Team Actually Requires
A Scrum team is not a project. Scrum teams are persistent, self-managing units delivering against a product mission. The work will evolve, the scope will change, and the team will make dozens of decisions every week without waiting for someone to hand them the answer.
That requires a different kind of foundation before the team delivers anything. They need a shared product vision and a clear understanding of who they are building for and why. They need a Product Owner with real authority, working agreements the team holds each other to, a Definition of Done, and a clear picture of who the stakeholders are and how the team engages them. None of that is a timeline or a requirements document. None of it comes from a project kick-off.
Where the Two Approaches Diverge and Why It Matters
The most consequential difference is accountability. A project kick-off establishes a hierarchy from the start. Decisions were made upstream, the charter documents them, and the team’s job is to execute within boundaries that were set for them. A Scrum team, by design, is self-managing. The Product Owner holds accountability for the value of what gets built. The Scrum Master is accountable for the team’s effectiveness. The development team owns how the work gets done. When you launch a Scrum team with a project kick-off, you have already undermined that structure before the first sprint starts.
The relationship to uncertainty is where the gap runs deepest. A project kick-off treats uncertainty as something already resolved, which is why so much time goes into defining requirements before the team touches anything. Scrum treats uncertainty as something you manage through short cycles and regular inspection. That is not a philosophical difference. It changes how the team behaves day to day. Teams launched using a project kick-off learn quickly that surfacing what they don’t know is a problem, because the expectation is that it was already figured out. So they stop surfacing it.
Scope follows from both of those points. Projects succeed when they deliver what was scoped, on time and on budget. That standard is appropriate when scope can be defined upfront and held. Scrum teams are not optimizing for scope delivery. Scope emerges through discovery, backlog refinement, and what the team learns from each sprint. The Product Owner is continuously making decisions about what gets built next based on value and learning. Locking a Scrum team to scope that was defined upfront doesn’t just measure them against the wrong standard. It removes the mechanism that makes the team worth having.
The failure mode this produces is predictable. The team operates like a project team because that is how it was launched. The backlog becomes a fixed list rather than a living artifact. Stakeholders expect delivery against the original scope rather than outcomes. The Scrum ceremonies become overhead rather than tools for adaptation. And when the product needs to change direction, there is no mechanism to handle it gracefully because the entire engagement was set up around not changing direction.
The Takeaway for Leaders
The work that needs to happen before a Scrum team starts is not a one-hour kick-off. It is typically a structured two to three day session, and it needs to be facilitated, not presented. That distinction matters. A kick-off is a transmission of information from a PM to a team. A proper team launch builds shared understanding, alignment, and working structures together, as a team. You cannot transmit your way into a self-managing team.
As a leader, your job is to make sure the right foundation gets built before the team starts. That means a shared product vision, clarity on the users they are building for, alignment on goals, working agreements, stakeholder maps, Product Owner authority, and a Definition of Done. Skipping that step because it doesn’t feel like delivery is one of the most reliable ways to set a new Scrum team up to struggle.
If you want to go deeper on what a structured team launch looks like in practice, our Building High Performing Teams Workshop is designed to help leaders build and launch high performing teams the right way.
