Crew Manifesto
Introduction
Our crew 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 ice-breakers and discussions about the standards takes time, but is required to start increasing the learning curve of the new crew.
A crew manifesto is a light-weight one page agile document among crew members which summarizes the basic principles and values of the crew and aiming to provide a consensus about technical expectations from each crew 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 "crew document reading" meetings and provide a consensus among crew members to answer the question - "How does the new crew 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 crew should work.
It also serves in the same way when a new crew member joins to the crew. New joiners can quickly get up to speed on the agreed standards.
How to Build a Crew Manifesto
It can be said that the best time to start building it is at the very early phase of the engagement when crews meet with each other for swarming or during the preparation phase.
It is recommended to keep crew 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, crew practices, documentations and others later on.
A few important points about the crew manifesto
- The crew manifesto is built by the development crew itself
- It should cover all required technical engineering points for the excellence as well as behavioral agility mindset items that the crew finds relevant
- It aims to give a common understanding about the desired expertise, practices and/or mindset within the crew
- Based on the needs of the crew and retrospective results, it can be modified during the engagement.
We aim for quality over quantity, and well-crafted software as well as to a comfortable/transparent environment where each crew member can reach their highest potential.
The difference between the crew manifesto and other crew documents is that it is used to give a short summary of expectations around the technical way of working and supported mindset in the crew, before code-with sprints starts.
Below, you can find some including, but not limited, topics many crews touch during engagements,
| Topic | What is it about ? |
|---|---|
| Collective Ownership | Does crew own the code rather than individuals? What is the expectation? |
| Respect | Any preferred statement about it's a "must-have" crew value |
| Collaboration | Any preferred statement about how does crew want to collaborate ? |
| Transparency | A simple statement about it's a "must-have" crew value and if preferred, how does this being provided by the crew ? 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 crew prefer in PRs ? |
| Branching | crew's branching strategy and standards |
| Commit standards | Preferred format in commit messages, rules and more |
| Clean Code | Does crew follow clean code principles ? |
| Pair/Mob Programming | Will crew apply pair/mob programming ? If yes, what programming styles are suitable for the crew ? |
| 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, crew rules ...etc. |
| Action Readiness | How the backlog will be refined? How do we ensure clear Definition of Done and Acceptance Criteria ? |
| TDD | Will the crew 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 crew ? eg: contact people, attaching PR to the issue etc. |
| Technical debt | How does crew manage/follow it? |
| Refactoring | How does crew manage/follow it? |
| Agile Documentation | Does crew 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 crew spirit during the engagement? |
Tools
Generally crew sessions are enough for building a manifesto and having a consensus around it, and if there is a need for improving it in a structured way, there are many blogs and tools online, any retrospective tool can be used.