DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Craft Your Team Culture Using a Team Manifesto

Craft Your Team Culture Using a Team Manifesto

A sample "team manifesto" to help craft your company culture in the direction you want it to go in.

Sam Atkinson user avatar by
Sam Atkinson
·
Jan. 21, 16 · Opinion
Like (5)
Save
Tweet
Share
9.61K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • DZone's Article Submission Guidelines
  • How to Submit a Post to DZone
  • The Path From APIs to Containers
  • REST vs. Messaging for Microservices

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: