A BRIEF SUMMARY OF THE SKILLS OF AN IT PROJECT MANAGER

There are a huge number of project managers on the market with different levels and experience. But can all project managers on the market be IT project managers?

If you look at the market for project manager candidates, everyone has a wealth of experience. There are candidates with experience in construction, medical projects, aerospace. The level of responsibility and requirements in these industries is God willing. Are these candidates familiar with IT? In most cases, if you ask whether it is worth inviting such a specialist, the answer will be ‘what difference does it make whether he knows IT or not, he has experience and knowledge of methodology - and that is the most important thing. He will be able to build us a system for working on projects’.

TASKS ARE NOT PROJECT MANAGEMENT

- Hey there. Long time no see. How are you? What are you up to?

- Good to see you. It’s been a while. I got a job as an IT project manager for a big company.

- It’s cool. Scrum, TDD, Agile. Hard?

- Not really. I write technical tasks and send them between techs and customers. It’s not a big deal.

Unfortunately, such conversion still be real. It’s relevant to many people who are not part of the large vendors or integrators, where all processes are better than Swiss watches and projects are really projects. But small and medium sized companies often ignore the concept of ‘project’ and work is done as it happens. A project manager in such company is more like a supervisor who gives the programmers a task to develop functionality as quick as possible, then asks testers to verify it, and then makes sure that it all go to production and customer. He gets a list of bugs from a customer and cycle starts over again. Such manager doesn’t distinguish between the critically and importance of the required functionality and the bugs. If the customer reports even a minor problem, the developers hear ’everything is broken’. This is an extremely unhealthy situation and this is what I want to talk about in this article.

12 KILLERS OF DEVELOPER PRODUCTIVITY

One of the most important and popular issues for project managers and technical leaders is increasing developer productivity. Many articles have been written on the subject. Let’s take a look at the root of the problem.

Almost 30 years after Tom DeMarco and Timothy Lister’s book ‘The Human Factor’ was published, projects continue to suffer from huge productivity losses. And there are many reasons for this misery.

Breaks and meetings

Interruptions are a major killer of developer productivity. It can take up to half an hour to pick up where you left off. The more interruptions, the harder it is to get back to work. Bottom line - more bugs and errors.

11 PECULIARITIES OF AGILE IMPLEMENTATION

After the article on the myths associated with Agile, it would be strange not to discuss: how to understand if the implementation of Agile is done correctly, which framework to use when, who in the company should be responsible for the transition to Agile.

I have divided the specifics of Agile implementation into two categories: company related and team related.

How do the specifics of the organisation affect the implementation of Agile?

Peculiarity #1. Industry preference for agile.

According to surveys, Scrum is the main method used in software development, financial institutions prefer Kanban, and telecommunications companies use both Scrum and Kanban.

9 MYTHS ABOUT AGILE

Agile development methods work both in IT and out of IT. In the time since the Manifesto was published, they have acquired ideas, stereotypes, superstitions, legends and myths.

Agile principles have transformed the development process and earned respect. The modern world is changing and evolving too fast - dozens of new solutions, applications and services appear every day. Agile methods enable companies to develop new products quickly enough to keep up with the pace of the market and of life, and to provide users with solutions to their problems as quickly as possible.

IS THE ENGINEERING PROCESS OVERRATED

Many engineers and managers focus too much on the process and overlook the far more important aspects of running a successful engineering team.

This article is a quick reminder of what really matters and where engineering managers should be spending their time and energy.

In the course of my work I have interviewed many people. And every time, the question inevitably came up: ‘How is your engineering process structured? Are you in agile team?" At the moment the terms agile, scrum, sprint are used very loosely and I dare say we hardly all understand them in the same way. How did we get from the original Agile Manifesto to where we are today?

CHANGE MANAGEMENT THROUGH RETROSPECTION

Retrospective is a collaborative team format that combines elements of brainstorming, coaching and feedback. Regular retrospectives that lead to change are an important sign of a self-organising team. But in most cases, retrospectives are purely formal rituals that are done for the sake of ticking boxes (well, we have Scrum). A successful retrospective requires a facilitator (preferably with experience of retrospectives). This is particularly important in new teams. In this article I will try to share my views on retrospectives and, if possible, give some tips on how to conduct them so that this ritual does not become an empty formality.

RISK MANAGEMENT PRACTICAL TIPS

Despite the super-accessibility of information, there are still people who turn a blind eye to a number of obvious things. This results in wasted time, money and effort. In this article I will try to make risk management as simple as possible.

Working with risk is, in my opinion, one of the most important aspects of being a project manager. Have you ever been in a situation where you have solved a big task, spent a lot of time on it, and just before the finish line you started to feel insecure? And how often have you had thoughts of ‘do or die’, ‘wasn’t done’, etc. in your head when completing tasks? Were there times when, at the finish line, you said to yourself or out loud ‘it’s over’ and felt relieved? Or, on the contrary, did you pound your fist on the table in frustration?

WHAT CAN BE DONE TO PREVENT BURNOUT?

As long as you don’t know how the brain works, you just think that some people are better off than others. But the brain is not actually designed to make us happy. Put simply, each of us lives in our own personal hell.

The brain grows unevenly throughout life. By the age of 25, the brain’s neuroplasticity begins to drop and our enjoyment of life begins to fade. When the brain processes incoming signals quickly, we feel good; when neuroplasticity decreases, we feel bad. At the age of 30, many people experience a kind of crisis: you are sailing on your favourite yacht, but life is no longer fun; you are in hell.

AGILE METRICS FROM BUSINESS INTELLIGENCE TOOLS

Some people may be surprised by the metrics listed here. You might think that these are abstract metrics related to the business, while the development team should focus on traditional development metrics such as speed and defect rate. I think this is wrong! In fact - these are the most important metrics. These are your ‘results’, not your ‘conclusions’. The whole team needs to know and think about these metrics. The greatest success you can achieve is when the whole team feels ownership and pride in what they are creating. Developers need to feel connected to the customers, their values and the results for the business they are helping.