When I was introduced by the management by objectives during my first working day in one of the companies I worked as the project manager I was impressed – I was so keen on measuring and controlling everything. “It was something I read about in management books and now I will see how it works in the real life!” – that is how I was thinking. Guys told me that they successfully used MBO for all the departments, so I expected the great results in the next quarter…But smth went wrong. We tried to adjust and redefine the objectives next quarter, but it seemed impossible to win this game – each time we redefined the objectives the system and people somehow could hack it and we just could not keep up with that speed of “hacking” – our suggestions were not good enough each time.
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.
Aaaand continue reading the Slack by Tom Demarco book. This time chapter 16.
Fixed price contract is by itself the greatest nightmare in the project manager’s life. But when it is combined with agile development frameworks – scrum/kanban/etc – it becomes also a tricky nightmare.
Usually, when clients ask you for “fix price” they mean: fixed money, fixed scope, fixed time. Some of the most reasonable clients I worked with on fixed price projects told me “We are not crazy! Let’s not fix the time! But we should be live till the 1st of June, we have this marketing campaign, you know…”
Even if you work in the “so agile” software development company there is the day when the sales manager comes to you and says: “Hi! We have a new project. I have a bad and a good news for you. The bad one is that it is fixed price, I know how you hate it. But the great one is that you can still your agile, client is ok with it”. So, let’s discuss what you, as PM, can do in this situation.
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”.
Aaaand continue reading the Slack by Tom Demarco book. This time chapters 13-15.
Almost 2 years ago I wrote about my experience with Lego Scrum simulation. Since that time I practised it about 10 times with different teams – inside and outside of my company. When you start playing it for the 2-3rd time you get a bit tired of building the city, so we changed the theme and the backlog every time) I also discovered, that this game helps teams not only to understand the Scrum better, but to uncover some conflicts existing in the teams. When I stopped trying to combine the roles of trainer and product owner and invited my gorgeous colleague Dmitry Velikoivanenko (thank you, thank you a lot for all you have done!) to join I was able to get more from the sessions, as I had time to observe the team’s behaviour.