Team Manifesto

Introduction

ISE teams work with a new development team in each customer engagement which requires a phase of introduction & knowledge transfer before starting an engagement.

Completion of this phase of icebreakers and discussions about the standards takes time but is required to start increasing the learning curve of the new team.

A team manifesto is a lightweight one page agile document among team members which summarizes the basic principles and values of the team and aiming to provide a consensus about technical expectations from each team member in order to deliver high quality output at the end of each engagement.

It aims to reduce the time on setting the right expectations without arranging longer "team document reading" meetings and provide a consensus among team members to answer the question - "How does the new team develop the software?" - by covering all engineering fundamentals and excellence topics such as release process, clean coding, testing.

Another main goal of writing the manifesto is to start a conversation during the "manifesto building session" to detect any differences of opinion around how the team should work.

It also serves in the same way when a new team member joins to the team. New joiners can quickly get up to speed on the agreed standards.

How to Build a Team Manifesto

It can be said that the best time to start building it is at the very early phase of the engagement when teams meet with each other for swarming or during the preparation phase.

It is recommended to keep team manifesto as simple as possible, so preferably, one-page simple document which doesn't include any references or links is a nice format for it. If there is a need for providing knowledge on certain topics, the way to do is delivering brown-bag sessions, technical katas, team practices, documentations and others later on.

A few important points about the team manifesto

• The development team builds the team manifesto itself

• It should cover all required technical engineering points for the excellence as well as behavioral agility mindset items that the team finds relevant

• It aims to give a mutual understanding about the desired expertise, practices and/or mindset within the team

• Based on the needs of the team and retrospective results, it can be modified during the engagement.

In ISE, we aim for quality over quantity, and well-crafted software as well as to a comfortable/transparent environment where each team member can reach their highest potential.

The difference between the team manifesto and other team documents is that it is used to give a short summary of expectations around the technical way of working and supported mindset in the team, before code-with sprints starts.

Below, you can find some including, but not limited, topics many teams touch during engagements,

Topic	What is it about ?
Collective Ownership	Does team own the code rather than individuals? What is the expectation?
Respect	Any preferred statement about it's a "must-have" team value
Collaboration	Any preferred statement about how does team want to collaborate ?
Transparency	A simple statement about it's a "must-have" team value and if preferred, how does this being provided by the team ? meetings, retrospective, feedback mechanisms etc.
Craftspersonship	Which tools such as Git, VS Code LiveShare, etc. are being used ? What is the definition of expected best usage of them?
PR sizing	What does team prefer in PRs ?
Branching	Team's branching strategy and standards
Commit standards	Preferred format in commit messages, rules and more
Clean Code	Does team follow clean code principles ?
Pair/Mob Programming	Will team apply pair/mob programming ? If yes, what programming styles are suitable for the team ?
Release Process	Principles around release process such as quality gates, reviewing process ...etc.
Code Review	Any rule for code reviewing such as min number of reviewers, team rules ...etc.
Action Readiness	How the backlog will be refined? How do we ensure clear Definition of Done and Acceptance Criteria ?
TDD	Will the team follow TDD ?
Test Coverage	Is there any expected number, percentage, or measurement ?
Dimensions in Testing	Required tests for high quality software, eg : unit, integration, functional, performance, regression, acceptance
Build process	build for all? or not; The clear statement of where code and under what conditions code should work ? eg : OS, DevOps, tool dependency
Bug fix	The rules of bug fixing in the team ? eg: contact people, attaching PR to the issue etc.
Technical debt	How does team manage/follow it?
Refactoring	How does team manage/follow it?
Agile Documentation	Does team want to use diagrams and tables more rather than detailed KB articles ?
Efficient Documentation	When is it necessary? Is it a prerequisite to complete tasks/PRs etc.?
Definition of Fun	How will we have fun for relaxing/enjoying the team spirit during the engagement?