A Software Development Manifesto

What’s a development manifesto?

Manifestos have been used by software and agile development teams for many years. One of the most famous ones that most agile teams have been exposed to is the agile manifesto. Other mission statements have been developed over the years including the more recent Async development manifesto designed to accommodate an asynchronous process and I believe a more modern development style. The goal of these manifestos and other similar guidelines is to ensure software teams are on the same page and have a DNA in place that they can all rally around and work towards. As you can imagine and can observe for yourself with a quick Google search, the value of having a manifesto or guiding principles is a controversial topic.

While some existing manifestos are good starting points for any team, you should only look at them as such and create a set of core principles and values specific to your team using a collaborative process.

Why do you need a development manifesto?

That’s a good question. After all, you may argue, these declarations are simply espousing common sense and I already follow these precepts… Well, the answer is simple. Any team that is formed around solving a specific problem and especially in fast growing startups, consists of people with different backgrounds and levels of experience. As a result, what might be common sense and part of one person’s daily practice may not even be on another’s radar. Furthermore, even if everyone on the team is aligned, the approaches and practices that work early on in the Proof of Concept stage may not scale as the team and product expand. The process of creating and refining manifestos helps with both aligning the team and changing the principles as required. In addition, if you know what the team’s DNA looks like, you can hire people who are a better fit for your team from the get go.

The phrase "forming, storming, norming, and performing" was first coined by psychologist Bruce Tuckman in his 1965 article, "Developmental Sequence in Small Groups." According to this theory, all teams go through these stages before they reach a high level of performance. The storming stage is one of the most difficult stages in team development and it happens whether you like it or not. In fact, if storming does not happen, I would argue that you may not have opinionated enough people on your team to move the needle in the right direction and to create an intellectually challenging environment that allows team members to advance. With any team, either it aligns after a while and moves to the norming and then the performing stage or the team remains in the contentious storming stage the project will inevitably fail. Your goal as a leader or as an individual contributor should be to move your team to the performing stage as quickly as possible.

The challenge in fast growing startups is more significant. If you are doubling and tripling your team every 6 months or every year, it’s like dealing with a whole new team every few months This could push the entire team back to the storming stage reducing everyone’s productivity.

While a development manifesto is not a silver bullet that addresses all growth pains, it can be a very helpful tool in moving the software development team from the storming to the performing stage. I believe the process of creating a development manifesto, getting together and talking about the team’s principles, pushes the team to the storming stage, which is a positive development. It’s beneficial because the storming phase is inevitable so you might as well deal with it head-on and facilitate resolving the personality and opinion conflicts along the way instead of waiting for them to unfold before a critical deadline.

Furthermore, when you already have a development manifesto in place, you can use it during the hiring process to find out if candidates are more or less aligned with the DNA you have established for the team. For instance, if continuous delivery is one of your core principles then someone who believes in a long manual QA cycle will obviously not be a good fit for your team. Remember though, as the business, industry and the team changes, so should some of the guidelines you use in your team. As a result, it is important to be open to revisiting and updating these principles.

How to create a development manifesto?

A manifesto is a set of principles with which most people in the team are aligned. There will be some who may not agree with everything in the document and that’s fine as long as the majority of team members believe in it, understand it, are ready to talk about it, and even defend it. The key is to move the team towards a self-managed state. Make sure it is not a document imposed by management that the team is asked to follow blindly. That’s not going to work... With this in mind, here are a few steps to go through to build and improve your development manifesto:

• Find some examples to show to the team as starting points
• Have someone on the team (not management) lead and facilitate the activity
• Schedule brainstorming sessions and collect as many ideas as possible from the team
• Organize the ideas into logically named groups. Use the groups to develop your high level principles
• Refine and review with the team until you have a good working set of principles
• Create a concise one page document that can be quickly referenced
• Share the document with the team on your collaboration platform (Confluence, Google Docs, Slack, etc.)
• Use it and reference it in your daily conversations
• If there are gaps in the team, come up with action items to address them
• Refine and improve the principles as you see fit

What does a development manifesto look like?

We have decided to share the manifesto we developed at Klipfolio so you can use it as a model when you develop yours. Feel free to use ours as-is, but as I mentioned above, you should create a manifesto that makes sense for your team.

The following is what we have come up with so far after a number of iterations at the time of writing this post. I am sure we will evolve it further as we change and grow as a team.

Feel free to drop us a line, if you would like to share your ideas on development manifestos or have any questions.