Meetings Log

Meeting without action items looks like chatter.

But it’s STILL CHATTER if action items were defined, but not checked how they are handled.

I think you will easily remind such kind of meeting when action items are defined in words or even defined in the follow-up email, but not handled or just forgotten after the next followup.

I’ve asked myself how to make the action items not be blah-blah-blah items, but action items: when people will return to them till they are not done.

Actions items should initiate real actions!

On the last projects, I’ve moved from followup emails to Meeting Log.

And it works great!

Meeting Log is a simple Confluence page with the history of the meeting.

It’s just simple grid with the following columns:

  • Date and Type – date of the meeting (in the past or in future), and type (i.e. Technical, Weekly etc).
  • Agenda: Reporter + Agenda. It’s easy now to plan the future meetings. All team members can easily to add items for the meeting in the future etc.
  • Action Items: Actor + Action.  Action initially marked by some visible sign that it should be handled by Actor. During the next meeting, we check the items with signs and remove them if the action is performed. It can be different results of action: email is sent, the ticket is assigned etc

It looks like this:

Meeting Log

With such a simple solution, our action items mean real action: we’re returning to the items with a sign and check them till they are not completed with any result.

The only problem you will meet is to make it filled by the responsible team members. In my case it was easy: BA fills it instead of follow-up, TL fills technical log to not forget what was discussed and what tickets should be created.

I hope it will be helpful for you!

Don’t hesitate to put your comments if you’ve any questions.  Thanks!

Side note: Confluence provides a rich set of macros to make this process easy and good looking (i.e. generation of the question mark, select date, select actor etc)

Open questions:

  1. Is it possible for Artificial Intelligence to take this routine with Meeting Log filling?
  2. Probably in Confluence we need to use checkboxes instead of questions marks.
remington standard typewriter in greyscale photography
Photo by Pixabay on Pexels.com

 

Don’t panic

In our world, a lot of things disturb us from the way to our goals. We call them problems. And it’ usual.

Work problems are usual.

We don’t like them or even scared, but in most cases, problems are resolvable and not dangerous for life.  Anyway, some people try to switch on panic.

In nature it works as life protector: if anything dangerous – you’re running away with screaming. But hey,  it’s useless in your workplace!

Panic as protection mechanism is useless regarding to work problems.

I see the following types of people in the context of behavior if they meet problems:

  • Resonator – emotional person who makes hipe and panic around the problem. He can even resolve it, but it makes stress, disturbs and demotivates his colleagues.
  • Jammer – emotionally stable person who reduces the panic around the problem or just don’t care about it. They can abstract himself and makes possible to resolve the problem without stress. From my experience, it brings more profit than working in panic.

Panic is really dangerous since it transmits by communication. It looks like a virus.

Yeh, one of the way to avoid it is to separate Resonators from communication chains.

As a result, if you’ve Resonators on the project it’s a high chance that the team will jump out from the board even before the riffs.

Panic is doubly dangerous since often it can NOT be stopped just by words – it’s very deep inside of the mind.

The best what Resonator can do is to work it out with a psychologist. The team is often helpless here. By the way, the workplace is not the right place for psychology practice.

What I can say now:

Resonators are dangerous and should be controlled or even separated from the team at all.

Especially if you have many of them in communication chains.

Another big problem if the team leader or manager is Resonator

In this case, I can only suggest

Run away from manager-Resonator. In another case, you need to have iron nerves.

From another perspective, if you see that you became Resonator, calm down an stay Jammer! Don’t panic, keep it simple!

If it doesn’t work for you, let’s start to work it out with a psychologist, but not with the team! Good luck!

Open questions:

  • Should the manager take psychology responsibilities or not?
  • What is the most intelligent way to control/separate Resonators?
  • How to make the work with managers-Resonators comfortable?
  • Is small controlled panic is ok as an alarm of problem existence?
photo of man jumping from boat to the sea
Photo by Oliver Sjöström, Instagram: @ollivves, Website: https://ollivves.com/

All you need is..

I’m often asking myself:

What can motivate to work for a long time?

Let me list here some well-known motivators:

  • Money? Partly. It accelerates for short period. If it’s enough money, people are focused on other things, but we can say for sure: if your efforts not paid enough – it demotivates.
  • Work itself? Agree..it motivates if it gives abilities to grow and ways to apply your knowledge.
  • Team? Agree. It works, if your team helps you, adds challenge.
  • Work environment. It’s not the top motivator but make sense.
  • etc

Every time I write down these points I have the feeling that I’ve missed something really important.

One fine day, my colleagues shared with me their problems like below:

  • My opinion was ignored in the area where I’m expert
  • I receive no feedback about my efforts. Even no “Thank you”.
  • I see no appreciation when I work on the weekend

I don’t know why, but after these words, my eyes opened:

Often people need nothing from you, but RESPECT.

They don’t need money, they need just your attention.

And now if you look back on motivators you will see that all of them are part of the same picture: all of these points exist if your company respects you.

Now let me summarize my personal feelings:

Respect is the best thing what motivates for a long period.

On another hand the most demotivative thing is Disrespect.

Let me describe areas where Respect should be demonstrated:

  1. Respect for your work efforts and achievements: your efforts and achievements are not ignored, but evaluated with appropriate feedback and salary. Your past achievements are not forgotten as well.
  2. Respect for your professional opinion: your opinion and knowledge are not ignored, but used in the right place.
  3. Respect for your time: the time you have is important and carefully used by colleagues.
  4. Respect for your personality: your individuality, personal feelings and goals are not ignored, but respected.

And now let me add a short conclusion:

Don’t forget to demonstrate your Respect. It’s highly important for your collegues.

If your manager demonstrates disrespect – it’s totally wrong.  You have the rights to ask him for respect, for feedback or attention at least.

Let me end with the nice phrase from the Godfather movie:

… But, now you come to me, and you say: “Don Corleone, give me justice.” But you don’t ask with respect.

Please see the whole scene. I think it can be a good definition of “Respect” and how it’s important.

21a35-godfather.png

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!

 

group hand fist bump
Photo by rawpixel.com on Pexels.com

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 Pexels.com

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 Pexels.com

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 Pexels.com

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!

pexels-photo-618612.jpeg

 

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!

cube-six-gambling-play-37524.jpeg

 

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!

pexels-photo-935867.jpeg