Why every tech company needs to revisit its development manifesto

Most software development teams have a manifesto that acts as a mission statement for the group.

But all too often, those manifestos remain unchanged for years at a time – and as a result they lose their power to motivate and inspire.

‘Continuous improvement’ is an accepted principle in software development. We believe that continuous improvement should apply to a tech company’s development manifesto as well. Instead of turning it into a museum piece by leaving it untouched, the manifesto should be regularly reworked and updated.

Making it a living document will improve the way you work.

Why have a development manifesto?

At its very core, a development manifesto drives a company’s development culture. It sets the tone for how everyone in the team expects the organization to function.

Without such a document, rules and expectations about behaviour remain unspoken. This can be confusing for newcomers, and create misunderstandings between employees with different backgrounds and varying levels of experience.

That lack of clarity can also make teamwork difficult: A practice that one person views as common sense may not even register on another team member’s radar.

The beauty of a manifesto is that it spells things out.

And the process of creating and refining manifestos helps align the team around key principles.

Once in place, the manifesto helps shape behaviour.

To drive behaviour, we created the Most Valuable Player Award, which is given to someone who shows evidence of using three or more high-level values from the Manifesto over a two-week period, or sprint.

All of this helps build cohesion, both inside teams and across the company.

We have also found our manifesto to be a useful tool in helping us assess job candidates.

As part of the interview process, we ask them what they think of the manifesto. In particular, we ask them whether they think anything is missing, or whether there is anything they disagree with.

We’ve discovered we can find out a lot about interviewees by having them talk about how they view the manifesto. In fact, on at least one occasion we decided not to hire a technically qualified person because the interview showed they did not believe in our ideals.. In that sense, the manifesto makes clear to job candidates our expectations about how our employees work and behave, and it allows us to assess them.

An added bonus of making the manifesto a part of the interview process is that we are able to incorporate into the manifesto new ideas and concepts raised by interviewees.

Finally, in a fast-growing team, it is important to rally newcomers around the team’s core DNA and culture in order to keep that culture alive and vibrant.

Why you need to update your manifesto

No matter how good a manifesto is at the start, or how useful it is, the reality is that circumstances change – sometimes very quickly.

The most common change in circumstances comes when you hire a bunch of new people or shift the focus of your work. If your manifesto doesn’t adapt, you won’t get buy-in from employees. You may even have people start actively questioning the manifesto’s principles – which can detract from their work if that questioning is not channelled into a manifesto amendment process.

We’ve written in the past about how to create an original manifesto. This post focuses on how to change one.

How to change a manifesto

We firmly believe that the manifesto should not be created in a vacuum or imposed from on high. Our feeling is that the result will be better – and stronger – if the manifesto update is a collective endeavour.

We have had good success by following these steps:

1. We took a group of people interested in agile software development and asked them to write on sticky notes about everything they think should be removed from the old manifesto. We grouped the responses into categories and posted them on a board.
2. We then asked the same group of people to write another set of Post-it® notes listing everything they think is missing from the manifesto. We grouped these responses into categories and posted them on a board.
3. We then created a two-person committee (us) to take that information and draft a new manifesto. (We believe it’s important not to have too many people on the drafting committee; that way, it’s easier to reach a consensus.)
4. We shared the initial draft electronically with the original group rather than at a formal meeting to get feedback (we used Slack), and used the feedback to create a final draft.
5. We called a meeting of the original group of Post-it® note contributors to approve the final version, and once that was done we had a designer put the manifesto into poster form. We don’t need upper-level management to sign off on it; the manifesto is an internal document for the development team. The team has to believe in it for it to have its intended impact (cultural unity and alignment).

What we came up with

In Klipfolio’s case, the revision process resulted in some important changes in our development manifesto.

This is our original:

And this is what it looked like after the amendment process:

In a nutshell, here’s what we changed:

• Focus on the customer is new
  • We added this as the unifying theme of our manifesto, central to everything we do, and made it stand out prominently.
• Continuous Improvement is essential/Productivity > Process replaces Agile is a good thing
  • The key takeaway in this is that we should strive to always be better, and not simply follow process for the sake of process. Agile is a way to accomplish this, and we still follow this method, but it’s the goal that’s important, not the method for accomplishing the goal. So we dropped the original ‘Agile is a good thing’ category and replaced it with points in the two new categories.
• Innovation breeds success replaces Automation is essential
  • We felt that calling attention to innovation, which we didn’t do in our original manifesto, was important to foster innovation as part of our culture. The original section on automation could be covered with points in the other categories.

Graphically, the document is more balanced, and each of the seven items is clear, simple and easy to understand.

Making the manifesto part of the company’s agile development culture

For us, creating the new manifesto was only a first step. A manifesto is only effective – and useful – if its principles become part and parcel of the company’s agile development culture. This, unfortunately, is something too many firms ignore.

We take the following extra steps to bring it to life:

1. One member of the committee periodically sends out an internal survey asking people to indicate, anonymously, how they feel we as a company live up ideals the manifesto spells out.
2. Based on the results of the survey, we pick a few areas of behaviour to focus on. It’s important to note that making people happier in one category may make another category weaker, so you need to find the proper balance.
3. To motivate people to hold to the manifesto, we started an internal awards program. Rewards are given to people who follow the manifesto’s principles. The Klipfolio Dev team’s Thanks Awards program allows any member of the team to nominate another team member for an award, which is a gift card and a thank-you card. Awards are announced and distributed every two weeks in front of the entire team. In addition to the name of the person receiving the award, we also announce the name of the person who nominated them, their reason for being nominated and the category of the manifesto to which the award applies.

A development manifesto represents an ideal, something for everyone in the team to live up to. We encourage every tech firm to create and regularly update it.

About the authors:
Elijah El-Haddad (linkedin.com/in/elijahel) is Software Development Manager at Klipfolio.
Kyle Campbell (linkedin.com/in/kmcampott) is Senior Software Developer at Klipfolio.

See also:

• Build a knowledge-sharing culture with Lightning talks in six easy steps
• A simple tip for successfully keeping knowledge workers engaged
• How to run a successful hackathon in 7 steps: A Development Manager’s guide
• Metric Driven Change Management