We all think that we are unique. Even when we make mistakes – they are unique. But it seems we are so predictable, that people already studied and classified all our epic fails – past and future ones. So it is very useful sometimes to read about the issues others suffered and compare yourself to the persons described – you definitely find something common. Project managers are not exceptions – you may think you are a smart project manager, but still you can follow some of the well known anti-patterns. I tried to collect the most common ones – which I built myself or observed in action. I found they fancy names on the internet and now I am prepared to use them in my speech, so I would look as smart as the developers talking about their architectural patterns.
I never had such an issue or was thinking about this topic during my PM career(Not because I was extremely respected by the developers. It was more like…I didn’t care.) But it seems to be an important question for a lot of Project managers. A good indicator of that is the interview question they keep asking you – “How can you get a team’s respect if you don’t have 10+ years of Haskell development experience???”. Looks like project managers really have some issues with respect…Sometimes I even think that developers treat project managers worse than QAs.. Oh my God, QAs!!! How that can be possible?
As the project manager I often found myself in the situation when everyone was looking at me and waiting my decision. As they really thought I am an expert or I know what to do. So every project manager should know some facilitation techniques to help team produce the decision or ideas. Because the smartest thing PM can do – allow the people who are really good at thinking to think the problem over and find the decision (I am talking about the team). PM should be a good facilitator and have a list of hand-on practices to help the team.
Have you ever met the manager who is satisfied with the speed of development? I, personally, not. But sometimes it is even worse than just the speed…I had so many educational talks with the customers about the development work – why you can’t code 8 hours in a row and why sitting and staring at the wall or even playing table tennis can be a work too for the developer, as he is thinking over the issue during that time. Once one of the top managers entered my room shouting “They are not working! They are browsing Internet!!! What we can do with that?”
Managers often ask me – “What should I do to increase our team velocity?” And the answer I give is very simple – “Just double the story points for each user story”. After that they usually smile and think I am joking. But I am serious, as usual.
Managers not only expect team to increase it’s velocity in this sprint, they expect team to continuously improve velocity. “Give me 10 story points increase each sprint!”. I also heard managers complaining that team has the same velocity for the last 7-10 sprints. We have this great metric – team velocity – for planning and budgeting. Going from sprint to sprint we collect the statistics and understand what amount of work team can do during the next sprints. But management is often too optimistic about this metric – they start measuring everything on base of velocity, even the team productivity.
There are thousand of posts for project managers about motivating their teams on the internet. While searching “Motivating Project Managers” I kept coming across the articles about the developers and how PM should behave. You can’t be a great PM without been a good motivator, so PMs are asked about the ways to motivate developers on every interview. But I think we miss some important item here – the motivation of the Project Managers. We assume that they are somehow already motivated and shine bright every day. Otherwise they can’t motivate the team, right? But no one cared about their motivation in software companies I know, they just required the managers to be “self-motivated”. We just don’t take that into account, as we don’t take into account that all our developers are not so brilliant as we think (and this is normal).
You think my life in agile world is ideal? No. There are several things that I really hate about agile. So let’s start our “two minutes hate”.
Thousands of companies are changing to agile, thousands are already agile (they tell you so very confidently). Some of them implemented Scrum. But I still come across of a lot of Project Managers in such companies. Ok, even better – I have a title of “Senior PM” myself (I hope no one from my teams/colleagues will not see my business cards, as they don’t know I am a PM ^_^). When company implements scrum they have to make a hard decision – what to do with these PMs we have? And usually they have a lot of PMs. I have seen companies where there is 1 PM per each 2 developers. Usually they become Scrum Masters or Product Owners, as it seems the most natural way. Just change the title and that is all – you are the Scrum Master now. Sometimes PMs are left as they were – they still “manage” the projects.
Development seems to be one of the slowest things on the earth – I hear so many complaints about it’s slowness every day. “Why we can’t do that in a day instead of a week?”, “We missed deadline because your developers are too slow, they should work faster!.”
Sometimes project managers think that the team they got is the slowest they can imagine. And they dream about making it 2 times faster (I mean “work 2 times faster”). But the fact is that there is a big chance the team is pretty average and managers don’t get the difference between “make the flow faster” and “make the team work faster”. They somehow think if the developers start typing 2 times faster everything would be fine with the schedule.