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:
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)
Is it possible for Artificial Intelligence to take this routine with Meeting Log filling?
Probably in Confluence we need to use checkboxes instead of questions marks.
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!
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?
Unofficial things makes the situation unclear and not manageable. It breaks the work process.
So what does it mean for the project:
Agreements are working from time to time. They work not like agreements but as important recommendations.
Team members and customer easily break the agreements since they look not important and actually not fixed.
Agreements are hard to share and improve.
Hidden agreements became “hidden stones” for newcomers and project at all.
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:
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.
I create Development Agreements for common technical agreements and page for each technical area (i.e. Frontend, Backend, Mobile).
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.
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.
The team and customer has a strong understanding of what agreements they have.
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.
It’s easy to appeal to the agreement if it is broken. Agreements protect the team members and management from useless arguing and discussions.
Agreements with the customer can play an important role in critical situations. It some kind of internal contract which can protect the team.
The customer is satisfied as well since his agreements are supported by the team.
It’s easy to improve agreements if they are written.
It’s easy to share agreements. They can be reused in the future projects!
Introduction of the new team member is simple. The newcomer is on the same page with the team.
After some time, some sets of agreements can be grouped and used as policies and guides.
Technical agreements can be used as points for refactoring: technical agreements should be supported not in words, but in code.
DevOps agreements can be used as points for automatization.
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.
I often notice that people can be separated into the following groups based on how they get satisfaction from work they do.
Let me describe what I mean. Imagine that a project or a business is a marathon with the finish line.
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.
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 😉
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!
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!