Category: Work Approach

This post is not about viruses =) Let me share an important note I’ve made during the work process setup for any activities or projects I manage.

Any work process should be self-sanitized: it should have a step to review the process, detect problems and have a mechanism to apply fixes for them.

Why do we need to? Self-sanitizing makes the process adaptable to a reality, fix the issues, make it more convenient for participants and etc.

This point looks like a Retrospective meeting in SCRUM, but it’s not only about SCRUM.

I think any long-running work process should follow this rule.

For example, after each estimation, I do a retrospective with the team to detect all pains we met during the process . I’ve created a spreadsheet where I accumulate all sensible action items to fix raised problems. Also, I have a reminder to take at least one item and perform it. Now the process is much better than it was before. It’s alive and convinient!

 

 

 

During my work, I’ve made many interviews with the candidates.

Most of them were for my projects.

It’s a really important fact since it gave me an understanding of my mistakes and successes: I’ve worked closely with the people I’ve selected.

After all these experience I want to share some of my conclusions about interviews:

1. Avoid situations and questions which cause pity for the candidate or make him feel bad. Don’t ask deep questions if you know that candidate is weak in the area etc. Results: all these bad feelings will not affect your decision and it will be objective. From another hand, the candidate will be not demotivated and will show his best.
2. Candidate should be motivated to get the job. He should demonstrate an interest in the work described by you. Results: if the candidate has no motivation even from the start- it’s a small chance that you’ll change it in the future. If the candidate is not motivated after the interview – you need to reject him and think if your speech about the future work was motivative. This is the next point.
3. Your speech about future work should inspire. You should be motivated to find the candidate and say correct words for each of them. Results: the candidate will feel it and choose your offer if you’ll make it.
4. The best question for an interview is a question related to future work, without a single answer, but with a range of answers which are depending on the knowledge of the candidate. Don’t be focused on deep details or logical games if it’s not specific of your work. Range of answers will give a room for creativity. Results: it gives you much more information about candidate knowledge in the area you really need.
5. Pay attention to the soft skills of the candidate. It’s critical since most future problems with all employees are not in the technical area, but with communications, responsibility, ability to support your team culture, etc. In my practice, I split the interview into 2 parts. 1st part is just to detect soft skills. Results: you will save your time and nerves.
6. Be open with the candidate. Don’t lie about future work. Result: the candidate will not leave the job if he made a balanced choice knowing of all future challenges and profits.
7. Mentor the candidate in a friendly manner. Provide him technical advice, recommend some books to read, etc. Make him feel that he leaves the interview with the new knowledge, in a good mood. Results: even if he will not pass, it’s a high chance that he will be back with the new knowledge.
8. Make a short practical test. Prepare some technical task which is close to the real work. See point 4 from above. I prefer to leave the candidate alone for 20 minutes for some code refactoring. Result: the real work is the best test for the skills. This is the next point.

Finally, I want to highlight the following conclusions I made:

The best check for the candidate is a real job.

Unfortunately, exists such type of people who can speak nice and pass all your questions, but the real job is hard for them. Anyway, be ready that all issues will appear during the real work with the candidate.

The recommendation of the candidate is highly important. Especially from a trusted person.

Try to get feedback about the candidate from the past co-workers. It will give you really strong arguments for your decision.

Trust your feelings and intuition.

A big piece of our experience is hidden inside of intuition. Some candidates will cause you to doubt, although all questions will be well answered. Don’t ignore your intuition. I prefer to have one more interview later when the reason of doubt will be clarified and should be checked. After some time I follow the rule – I reject the candidate if I have doubts.

Listen to each other! Good luck with the interviews!

What does come to mind if you need to asses your colleague? What areas do you usually measure?

Let me mention some of them:

• Knowledge in the technical area
• Professional approaches
• Ability to work in the team

During my practice, I’ve detected one more important option.

But let me describe the situation I’ve met:

Due to some reasons, it was no daily stand-ups on the project. One of my team members worked for a long time on the task. The task was quite complex with different hidden stones inside.

The problem was that he provided his status only on my request. Results were hard to check and he always shifted the deadlines. As a result, after a month of work, when it was an internal assessment it was hard to evaluate his efforts and skills. He was like an invisible man for me. It was not clear how professional he is.

Another colleague was confused as well. She said a great phrase:

He has low VISIBILITY.

Yep. That is the perfect word! I’m using it now for some set of professional approaches.

After thinking let me summarize what I mean under Visibility:

Visibility is the ability of a person to provide timely and tangible information about his current work results.

Tangible means that the results can be easily checked: it could be a pull request, test case, user story, demonstration, charts, video recording, report, email etc.

Note that results of work can include even the list of blockers provided by email.

Problems we meet are the results of our work as well.

Timely means not right before the deadline but provided in an iterative way, right after receiving any tangible achievement.

What is the profit from visibility?

For the manager and the whole team I see the following points:

• It makes it easy to check actual results and plan the future work and deliverables
• It reduces delays in development and unexpected problems and results at all
• It makes possible timely handling of the problems
• The results are visible for the team and the customer
• It avoids unpleased moments during work result assessment

For the employee itself:

• It works as self-marketing. If your positive results are visible for management it increases your karma salary: your achievements will be not ignored and will be used during the assessment procedure.
• If you speak openly about your problems, it’s a big chance that your team will help you to resolve them
• If you make your work results tangible it means that they became better quality
• It avoids unpleased surprises during your work assessment

Why Visibility is so important? Let’s imagine that the profits from above are revoked.

In the context of the situation from above, I’ve made additional conclusions:

Daily standup increases the visibility for the whole team. Avoiding this practice badly reflected on each team member.

The manager should describe to the team how to become visible. Keep it in mind that visibility is not usual for some people.

High visibility is a part of high professionalism!

Be visible!

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:

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.

 

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!