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.


  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.



group hand fist bump
Photo by on

Paper and pen

Just give a paper and a pen to the person and he will start to write.

If you’ll give a paper and paints – he will start to draw.

What does it mean to me:

  1. The things can be done easily if you’ll provide the field for creativity.
  2. Remove fears to create sketches. Make possible to create as many sketches as possible! The whole picture will be based on them!
  3. Tools are important. They should be useful and simple. It’s highly important if you want to start something!

Examples where it works:

  • Just create some Confluence page to fill unstructured Development Agreements
  • Create a folder just for sketches mockups without mixing with results
  • Create a simple spreadsheet to fill ideas about the project.
  • Create just empty Source code file with very raw functions.

After a while, you’ll see that a picture begins to emerge from the chaos! It will need just some efforts to extract it from sketches and polish.

Don’t be afraid to draw sketches. Just start do it for fun.

spring book with feather sketch
Photo by Alena Koval on

Muddy water

I think

The most painful problems happen if you cannot proceed due to some facts and rules which exist, but not officially confessed.

It’s like hidden stones in the muddy water.

Usual cases:

  • An informal leader who works in parallel with an official leader. Results: a dangerous confrontation between team members, team velocity reduce, inconsistent work, demotivation of the whole team
  • Informal delegating of management power without official acknowledgment. Results: delegation is not working, conflicts, demotivation, blocks during work performing
  • Undocumented agreements. Results: unexpected results of work, agreements are not working for some parties.
  • Undocumented rules in the code. Results: Unexpected work of application.
  • Problems ignored by management. Problem is unofficial. Results: problems are not solved, employees demotivation.

Let’s be frank:

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

Why it’s happened?

I’m 100% sure that exists some responsible person with enough power, but not brave enough or just lazy to take responsibility and solve the problem.

Such kind of employee is responsible to make water clear to avoid the stones, but he didn’t. It exists even a chance that he does it for some reason.

Maybe it exists some hidden reason. Let me remind you the old proverb:

Fish is easier to catch in muddy water

from latin: Turbato melius capiuntur flumine pisces

What I can recommend,

If you want to make your agreements and rules work and you’ve enough rights to impact on the situation –

Be brave and clear the water – formalize informal things.

If we’re taking a look at the cases from above:

  • An informal leader who works in parallel with an official leader. What to do: work to make informal leader lead the team or remove him at all.
  • Informal delegating of management power without official acknowledgment. What to do: discuss with the team possible changes in responsibilities.
  • Undocumented agreements. What to do: sit down with all parties and document informal agreements.
  • Undocumented rules in the code. What to do: document them in requirements or just fix them.
  • Problems ignored by management. Problem is unofficial. What to do: take responsibility for the problem and inform how it will be handled.

If you’re not enough rights, but in the situation as defined above: don’t hesitate to inform a responsible person about the problems and needs to resolve it.

You’ve all rights to push your manager to resolve such painful and blocking situation.

Anyway, you need to be brave. Don’t be afraid to create the conflict. Otherwise, you’ll break your legs in the muddy water.

beach black coast daylight
Photo by Tatiana on

Catch the problem

Hi again.

Let me start with the joke:

The husband is the last person who was informed about wife’s adultery.

Let’s be frank, in case of work each of us was such a “husband”. Doesn’t matter if you are a manager or employee.

I don’t know how about you, but I want to prevent such problems 😉

So what I really want to say?

I think,

Large number of critical problems of the company or team can be prevented by improving of communications.

It looks like general words, but what really should be improved?

If we’re talking about communication you need to have a way to communicate 😉 – communication channels.

Setup communication channels.

Just do it! You’ll be surprised what kind of “fish” problems you’ll catch.

There’re many options to use: Regular meetings with the management, visiting a pub with the team, face-to-face meeting with team members etc.

Let me continue the analogy with fishing: communication channels will work as “nets”. They will catch important information about the problem before it will bite you.

Like in fishing, to catch important information you should be patient: you need to make communication channels work not from time to time but on regular basis!

Communication channels should work on regular basis.

Yep, it needs efforts, but only in this case you’ll have notable results.

One more point: channel should work in both directions. You need to have the ability to contact all needed persons. Nothing should disturb them to provide information to you.

It should be easy to communicate in both directions.

From my experience, to make it work you need to build quite informal, positive relationships. Try to allocate time to persons if they want to talk. Don’t be like “always-busy man”.

A little informality in communication makes it more humane and open.

So what to choose?

For the specific fish problem, you need to have a special net communication channel.

I suggest to start with the well-known channels  (they can be used together):

  1. Message-oriented channels (i.e. skype groups, project mailboxes, company newsletters) – to get/send information. This channels can be used as the basis for other types.
  2. Group meetings (Skype call with the project team, etc) – to detect the problem and get an overview
  3. Meeting in person (Performance review meeting, progress check etc)- to understand the problem and get a personal vision of the situation.
  4. Informal meeting (i.e. barbeque, drinking beer in pub etc) – to understand roots of the problem.

Let’s select something and make it regular!

Last note for the case if you’ve supervisor, but there is no communication channel between you.

If you want to avoid the situation when after a long time manager will inform you that he is not satisfied with your work and you’re fired:

Doesn’t hesitate to ask your manager for a regular meeting with you.

The supervisor will share his concerns before they become fatal for you. On another hand, It will help you to share your problems and achievements!

Ok, let’s stop to talk and start the fishing 😉

grayscale photography of man holding a fishing rod near body of water
Photo by payam masouri on

What is your orientation?

I often notice that people can be separated into the following groups based on how they get satisfaction from work they do.

  1. Tool-orientated
  2. Process-oritented
  3. Goal-oriented

Let me describe what I mean.  Imagine that a project or a business is a marathon with the finish line.

  1. Tool-orientated people. They like to run in their special boots and sportswear. During the project development, they enjoy playing with the “tool”: it can be some process methodology, framework, service etc. The big concern that they are just focused on playing. If the new tool will arrive and not used – they will be really unhappy and leave the marathon before the finish line. Do they bring profit? Yes, of course: they are brave to use new technologies and they are geeks, they like to dive deep into the details. I think many good experts started in this group.
  2. Process-oriented people like just to run in their own manner… doesn’t matter where is the finish line. They are interested in some work area of the project and they do it in their own way.  They do it well, not restricted by tools and have a good vision of the process they do.  The problem is that they can forget about the work goal. Additionally, they are losing their satisfaction if it’s not possible to make things in their way. From another side, they do they work and will go till the finish line. Not in the top, but still with good result. It depends on the trainer who will remind them about the goals 😉
  3. Finally, Goal-oriented people. They like to meet the finish line … anyway. As a result, they are winners and they like it. It doesn’t matter what tool to use and how. The Goal is their God.  What could be wrong?  They’re using not perfect tools, they can use them in a wrong way, they can bring down other runners. Yes, they are not perfect. But hey… winners are not judged!  The project is completed. It’s good for management, good for the customer and…  quite stressy for the project team 😉

Of course, people are not dedicated just to one group and the project is not just marathon.

All people make some profit for the project, especially in the right place.

But let’s be frank:

If you need to win, you need to be a Goal-oriented person.

Make your choice, but don’t be indifferent to your work!



Work without worker

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!



Retrospective vs Psichology

I have a weekly retrospective meeting with my team. To be prepared for the meeting we fill out some kind of board with the table: 1st column for good points (i.e. “Where we succeed), the 2nd column for other points (i.e. “Where can we be better”)

I noticed that the whole team and even I don’t like to add items in the 2nd column even if you want to suggest or improve something. I see here 2 reasons:

  1. Since all positive items are in the 1st column. The 2nd column always contains non-positive and negative items. As a result, even positive improvements interpreted as negative.
  2. If you are writing something negative about any point and it always makes pain for the responsible person

The result is sad:

  • People don’t want to talk about improvements to avoid conflicts with colleagues.
  • If they are brave and add something in the 2nd column it becomes a negative background and makes stress for the writer. After a while, he will just skip writing in this column at all.

Let’s see what Psychology could say for this case:

If you want to say something about others work:  let’s share YOUR PERSONAL feelings instead of evaluations!

NO- “Your code is really bad”

YES –  “I’ll be happy if you change something in this code”

SO-SO – “I’m sad, since your code breaks our application”

Now let me share the solution I noticed from Atlassian newsletter:

It should be 3 columns:

  1. I like
  2. I wish  //to improvee existing things
  3. What if  //ideas for the future

That what we need!

  • All items are with positive background
  • All items are focused just on personal feelings instead of evaluations
  • This allows you to write ideas for  improvements

It’s great and it works! Let’s use it!


Let’s begin

Welcome to my personal Tech Blog!

What I’m doing there? Heh…

  1. I write here my thoughts and ideas related to my work area: IT, Management, Development etc. I think this process will organize them in my head and make clear even for me.
  2. I want to accumulate my visions to organize  them in the future
  3. I want to share my knowledge

Writing helps to organize the thoughts.

Hmm…  coding works in the same way!

Don’t hesitate to code even if the idea is not clear!