There’s really just one thing that matters in creating an agile team charter: anchoring to a problem instead of a solution. Anchor to a problem, and your team has a shot at creating the next Google. Anchor to a solution, and it’s more likely your team feels like a rerun of Office Space.
Why? Because problems, defined correctly, are durable and keep you focused on what’s valuable to the user. Solutions change a lot and if a new team is chartered for a solution, it’s confronting difficult odds. Depending on which figures you think are most relevant, only around 20% of feature are really used. 80-90% of new products fail. 50-70% of IT projects fail. That’s daunting, but if you anchor to a problem and iterate through solution (as agile suggests), even the improbable becomes probable and that’s the mainstay of a practical approach to innovation (which is pretty much a proxy for success these days). For a great, public example of all this working at scale, see Spotify’s video on their engineering culture.
Yes, the agile charter has more attributes: the parameters for scrum or whatever agile methodology you’re following, notes on what systems you’ll use for what, values, other stuff. I’ve made some notes on those below. That said, don’t pain your team with drafting all that as a group. Draft something plausible, send it out in advance, discuss and and update it with your team, and then treat it all as an experiment that you’ll observe and update as you go. Don’t over-invest in perfecting it up front. Instead, be diligent about updating it based on what you learn and what you actually do and a strong charter will emerge. That’s what agile is about.
A Template for Team Charters
Mainly because blank pages often make it hard to get started, here is a Google Doc template that you can fork/copy (or download as MS Word if you roll that way): Agile Team Charter Template.
6 Quick Notes on Creating an Agile Team Charter
1. Use a Problem Focus
For reasons I described above, this is probably the most important part of the charter. For bonus points, make sure you know what problems your company or division is solving and how your team and your peer teams fit into that (charter-wise).
2. Note Members & Roles
It may seem obvious but this is probably worth taking 5 minutes to do. Depending on what agile methodology you’re using, note the Product Owner, Scrum Master/Coach, etc. If nothing else, it will help folks from other teams understand who’s doing what.
3. Specify Methods & Parameters
The most important thing about your practice of agile is how you evolve it based on experimentation (not picking the rightest, truest methodology). You can’t evolve your practice if you’re not being explicit about what practices you’re implementing vs. not implementing. If you’re tracking burndown (or not) note that, for example. If you’re working to visualize your actual, observed workflow with kanban, note that.
4. Note Systems
List all the the major things you do as a team and what systems you use for those jobs (even if some of those systems are a Google Doc). Maintaining a shared understanding about this is more important than particular tools and practices.
5. Define Conventions & Practices
Yes, agile values individual interactions over processes and tools. That doesn’t mean it’s a good for team members to constantly hunt around for what they need because everyone does their work differently. If the team agrees a practice is important, it’s probably a good idea to agree to a shared view of conventions, even if they’re all under probation as an experiment.
6. Log Changes
Keeping a brief change record is probably a good idea so that if you have a question about why you did something or how a certain set of outcomes correlated with practice, you have an answer.
