Everyone is agile nowadays. I think that even my cat knows this word. Our sales team is agile, our development teams are agile. We do daily stand-ups, why would you say we are not agile?
I am really
very a bit tired because of all this hype.
Let me tell how it usually looks like when you are agile*. I mean “agile”. I know, I am mixing the issues of agile frameworks with the bad implementation issues. Please don’t blame me for that, as this is like real life – all possible mistakes are made and they are uniquely mixed.
*All characters appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
Continue reading Say “agile” one more time
Are you happy on Monday morning? What about Friday evening? We all know how office workers are waiting for the Friday evenings… Because work is hard. Because there is no more joy. Really? How people who are not feeling good about their work can produce something great?
If you ask any of your colleague when they felt joy at work they probably tell you about some challenge they faced and successfully solved or brainstorming, where their team produced a great idea. Also they can point out the time when they worked with a great passionate team of developers. Even if they were creating “one more social network”.
Continue reading The fun is dead, long live the fun!
Show me your burndown chart and I will tell you how the things are going. To be honest I am amazed how simple the things became for the project managers (does not depend whose hat PM is wearing now – scrum master, product owner) now – you need only a few metrics to be able to plan and forecast with the same success rate as it was previously. The burndown (I personally prefer burnup) chart is a very simple thing – easy to explain, easy to maintain. But it is a powerful instrument in the hands of the scrum master and the team.
Continue reading PMs guide to tricky questions: What burndown can tell you?
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.
Continue reading Increase My Velocity, Baby!
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.
Continue reading Fixed Price Projects and Agile, or The Scariest Nightmare
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”.
Continue reading Things I hate about Agile
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.
Continue reading Variations of Lego Scrum simulation and lessons learned
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.
Continue reading WTF Project Manager is doing in Scrum team?
That is seems to be the PMs nightmare – your developers are lying to you when they provide you the estimates. For the 1-hour task they give you 1-week estimation and spend the whole week watching youtube videos with cats. HAHAHAHA!!!
Are you already scared to death?
It also should be a rather common problem, as I often get such a question during the job interview. “Galina, what would you do if developer gives you the unrealistic estimations?”. They ask me and wait for some one-for-all-cases answer. Probably they expect me to say something like “I will double check all the estimates myself/with the other developer”. So I will be a kind of the PM auditor. And then they are definitely ready to ask – “And what if the other developer lies to you too”? Seems to be one global developer’s conspiracy. What one small PM can do against that?
My honest answer to all of that is: “I’ll resign ASAP, as I killed that team and should not do any more harm. Then I ‘ll walk outside the office and perform seppuku”.
Continue reading What if developers are [cheating] giving you the unreasonably high estimates?
I think every Project Manager knows how easily you can become flooded with the tasks. While developers can afford spending some time on the single task, PM has to switch between a lot of tasks during the single hour (some PMs think that they are multitasking, but it is not true :). Sometimes, in the end of the day I feel like I spent all my time on switching and dream about getting some task on which I can spend 3 hours in a row and not been distracted.
Developers usually say that while they work they fully wrap their mind around the task at hand, they create the “mental model” of the classes, methods, etc and they need some time to “get context loaded” when they start working with the task. They feel something like the “work stream”, so when they are distracted – it takes time to get back to it.
I should say, for me PMs work process is the same – I get to the office in the morning, sit in my chair and have so spend some time to “load mental model” of my projects: project details, people, relationships, todos, etc. Sometimes I do that on my way to work. I am not keeping all details in my head all the time – I unwrap this model when it is needed. The difference between the “work stream” of developer and the manager is that manager’s constants of “interruptions” – you have to think quick, make some decisions, answer questions and be always alarmed.
Continue reading Personal Kanban: my experience