Craft Your Team Culture Using a Team Manifesto

My most recent team at work has been by far the best one I have worked in. Not only has it been fun, but we’ve been very productive and delivered a lot in a short time period. There were many contributing factors to this, but the main driver for me was our creation of a Team Manifesto. It was the best thing we did and is something I would recommend to any other developers whether there team is old or new. I hope after reading this article you’ll schedule a meeting in to create your own.

But first, what is a team manifesto and what is the problem it is solving? Simply put, it’s a big list of all the team “guidelines”. They can be about absolutely anything, although there are a couple of key areas that should be covered which are discussed below. But what problem is this solving?

Organizational culture is a very important thing. It’s what dictates what is considered “the norm” for doing your job. In one firm you will be expected to take responsibility and get everything done on a task single handedly. In another, you will be expected to trawl through red tape and consult with a number of colleagues to get anything done. In one culture, a standup meeting will be expected to last an hour and be the main touch point between a manager and his team whereas in another it would be frowned upon to be over ten minutes. I’m not saying either culture is correct or wrong (that’s for another article), but simply that our team habits tend to be dictated by the organizational culture, and that it generally grows organically. No one things 3 hour planning meetings are a good idea, but if everyone else is doing it you will probably fall into the same mold. This is the problem.

Most teams are happy to plough forward following along blindly. Occasionally the culture will change, often dictated from above. But whilst we spend ages optimizing agile practices or retrospecting on what we could have done better in the last iteration, we rarely sit back and take stock of how the team is working and whether we think it is how we want to work.

The Team Manifesto clearly states what a team views as good and what a team views as bad. It is decided upon and agreed (“ratified”) by all the members of the team. The team has to keep itself accountable.

Let’s take an example: meetings. The bane of every developer. What do you want your team approach to meetings to be? At the moment you probably don’t have one and will just attend whatever’s put in your calendar. Here are some key questions to ask:

• Do we want to have formal meetings in our team?

• If the team is asked to an external meeting, who should go? The whole team? The dev lead? No one?

• What do we want the output from each meeting to be? Wiki page? Email around? Nothing?

There are a lot of questions that can be expanded upon here. The important thing is to decide as a team what you value. It takes bravery to say that you’re going to stop all meetings, but surely you can try it out and iterate later if need be? If you must have meetings, can you all just grab chairs around someones desk or do you have to go to a room? The important part is not necessarily a radical change in approach, but the fact that it is a conscious decision by the group, and not something that has just become habit.

One of my favourite aspects for a manifesto is code quality. It’s something that most teams will have a process for; code reviews, pairing, and demonstrations. But often these will be handed down from management and are not effective because the team doesn’t buy in. Challenge your team; no one will disagree that good code quality is important, but how do they want to maintain it? What processes do they think will add value? 

By getting your co-workers to create the manifesto and attach their names to it you instantly have the buy in needed for the plan to succeed. They came up with it! If people stop following the manifesto they’re clearly accountable and the group can go on to find out what isn’t working and improve again. The Manifesto is not a static document; if parts aren’t working then perhaps it was a bad idea in the first place. The team can look at this and improve it.

An Example Manifesto

Below are a few highlights from a made up but eminently sensible Team Manifesto.

Development Methodology

• Lower case a "agile" — delivering quality quickly is more important than the process.

• Estimates are good if they’re useful, preferably using story points.

• Pair programming rocks. Team should be pairing at all times.

• No standups; we should be interacting throughout the day.

• Continuous deployment; code goes straight into prod. Stop the line mentality on broken builds. 

• Mainline development, branches only used locally.

Meetings

• No formal meetings. There are only 4 of us so if you need a meeting, just grab everyone and we’ll sit at someone's desk or around a whiteboard.

• External meetings are taken by the dev lead. Developers' time is better spent developing. The dev lead will do their best to shield developers from the real world.

Communication

• Email is terrible and should be avoided. When forced to use email by external teams, the team mailing list should be used to provide visibility for everyone

• Slack is the best way for intra team communication, augmented with blogging for documentation.

• Regular Code on the Wall sessions (developers to organize) to show off work.

Languages

• Must run on a JVM, or else go crazy.

• Only REST used for APIs unless extreme performance is needed.

Whatever your team finds important should be in there, and it should be the first thing on your internal wiki page; everyone should be able to see what you stand for and how you work so they can try to link in with your processes and hopefully adopt them.

Any comments or suggestions? Drop a message in the comments or let me know via @SambaHK on Twitter.