Project Agreements

It’s not a secret that

during the life, project team including customer creates a large set of internal agreements and rules.

It covers all possible areas: management, communications, development, release process, quality assurance, requirements etc.

Examples of agreements:

• Sprint length is 2 weeks
• TL is responsible for newcomer introduction
• Customer dev team should inform about infrastructure changes.
• Jira tickets for the business feature should be marked by “Feature” label
• The weekly status call should go in the following order.
• DevOps should notify the team about a critical update of environment
• Git commit message should be in the following format
• All shared files should be located in the project folder (link)
• To get access to the Production Server you should use the following guide.
• The configuration of the server should be done in the following way

Some of them look simple and clear, some of them are complex, but most of them are covered by the same problem:

Huge number of project agreements are not documented. They are hidden inside of team members knowledge. They are not official, but exist.

It’s totally the same case I’ve described in the post about informal things.

The effect is known:

Unofficial things makes the situation unclear and not manageable. It breaks the work process.

So what does it mean for the project:

1. Agreements are working from time to time.  They work not like agreements but as important recommendations.
2. Team members and customer easily break the agreements since they look not important and actually not fixed.
3. Agreements are hard to share and improve.
4. Hidden agreements became “hidden stones” for newcomers and project at all.
5. Agreements are lost and forgotten with team members rotation

On my projects I applied the simple and clear solution to avoid the situation from above:

Team should document all project agreements as soon as they created.

To make this possible I do the following things:

1. I create the Confluence page called Work Agreements for all kind of agreements which are applicable for each team member and customer. It has the simple structure: it contains the table with Agreement #, Agreement short name, Agreement definition itself. In the top, I add the Table of Contents for simple navigation across agreements.
2. I create Development Agreements for common technical agreements and page for each technical area (i.e. Frontend, Backend, Mobile).
3. For each Agreements page, I select a responsible person who will take care of agreements fixation, improvement and agreements implementation. Project management (i.e. PM, TL, Scrum Master) is responsible for the whole Agreements process.
4. For other project areas (i.s QA, DevOps, Design/UX) we create pages as soon as the first agreement defined

Now when the team creates an agreement (ordinary during standup and retrospective meetings), responsible person documents it in the dedicated page.

Profit:

1. The team and customer has a strong understanding of what agreements they have.
2. It’s easy to approve agreements with the whole team. It’s important since if the agreement is documented and confirmed by each team member it’s some kind of mini contract of the project. Each team member undersigns it.
3. It’s easy to appeal to the agreement if it is broken. Agreements protect the team members and management from useless arguing and discussions.
4. Agreements with the customer can play an important role in critical situations. It some kind of internal contract which can protect the team.
5. The customer is satisfied as well since his agreements are supported by the team.
6. It’s easy to improve agreements if they are written.
7. It’s easy to share agreements. They can be reused in the future projects!
8. Introduction of the new team member is simple. The newcomer is on the same page with the team.
9. After some time, some sets of agreements can be grouped and used as policies and guides.
10. Technical agreements can be used as points for refactoring: technical agreements should be supported not in words, but in code.
11. DevOps agreements can be used as points for automatization.
12. Design agreements can be used as the basis for a Style guide.

I wrote you that agreements can be reused, but don’t forget that it’s possible just for the most common items.  Each team is unique and should come to the agreement during the work process. Something that works in one project will not work in another.

In addition, the team should understand the importance of agreements. To make it work, the management should initiate the process by documenting of some important rules.

From my experience, it’s not hard to motivate the team, since even the initially fixed agreements will demonstrate the profit described from above.

Enjoy!