Author: Sergey Bondarev

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!

Many times I see the same situation inside the company or just inside the team:

  Work or problem exists, but NOT DEDICATED WORKER assigned on it.

Basically, it’s because of lack of budget or the feelings that there’re no work or problem at all.

Possible examples of such work inside the company: organization of team events, sales support by development experts, employee career management, meetups, education process etc.

Examples of such work inside the team: it can be requirements management, DevOps tasks, manual testing etc.

The problem begins when the project manager or customers say that project requirements will be handled by them or not all (this is the same ;)), or delivered project should have no bugs… Sad, but true.

Let me describe what happens in this case:

Work with not assigned employee are unformally handled by enthusiasts when they have free time.

They change since they are not assigned to this work and are engaged in other activities.

What we see as a result of this work: it has totally different quality and work style, the results are not predictable, not consistent with other work etc.

What I recommend in this case and how it’s done by prospective companies, management or team leaders:

Initially management should recognize the existence of the work or problem and take responsibility over it.

Unfortunately, this is a complex process and occurs when the problem becomes critical.

But let me rephrase this in another way:

If you want to achieve results of the work in the new quality  – assign it to a dedicated person! It will have good effect from the very begining.

The result of the work will be predictable, in the same style and so on. Quality will grow as the person will get a constant experience.

And if you find the right person – it will be Bingo!

Good luck!