The budgeting syndrome is usually connected with the line manager day-to-day life, but PMs seem to have their own unique mutation of it. How the PM budgets the project usually(of course, we all have t&m projects with no fixed cost, but the budget is always there)? You have a great team that estimated everything, but the person who presents the budget is a PM. Here is the point where many of us come to the dark side…
I really love games, that is why I am trying to use them in my work life too. When it comes to the serious questions – adopting new processed framework or show the team why it is great to work in a team – I prefer to use games too. It is fun, it is easy and very engaging. When I came across lego scrum simulation by Alexey Krivitsky, I thought – “Bingo! That is what I need.” In addition – I really wanted to buy some lego and could not find any excuse to do that…So it was my chance.
I have heard from a lot of PMs that it is hard to involve the team into retrospective process. Team members are usually enthusiastic about discussing complaints, what the idiot is the customer (yes, I know that you don’t have that in your team, as all of you respect your customer, you have a great atmosphere in the team. But I do have these problems in my teams). When I try to ask the developers some more constructive questions – I get something like “Everything was ok” from the developer. How to get more?
Sometimes I am standing in front of the team, which is comfortably sitting in the chairs and looking at me, with their faces showing “Hm..one more meeting…what does that PM need? We didn’t have this crap with the previous PM!”. And I am thinking how to awake them, make the part of the process, share their thoughts (you’ll be surprised, how many great thoughts can developers come up with).
I want to share my thoughts on the main project manager/scrum master/leader responsibilities in the team. In the vacancies texts I usually come across the following PMs responsibilities: he should plan, estimate, manage risks, etc. But why our projects are still so often a disaster, nevertheless our PMs are planning, estimating, managing risks, etc and doing that thoroughly?
About two months ago I had a severe argue with one of our lead developers about ‘agile stuff’. After 15 min of listening to my enthusiastic speech his face became red and I could read “Woman, what do you know about the real life?” from it. And then he said the phrase I can’t forget: “And why do we need all of that? Why we can’t just collect our best architects and analytics and write down all requirements, describe models, create the ideal architecture, plan everything and then start development?”
Hey, PM, how often do you hear “Those meetings make me crazy…They are so boring!” from developers? I hear this phrase while having my lunch in the office kitchen, while passing by developers, comfortably sitting on the sofa, and so on and so far… It can happen up to 10 times a day, if your company is big enough. So, PMs, let’s be honest, our meetings often suck.
I will try to analyze why that can happen and what can be done.
I definitely love that talks with people new to agile. I bet you came across that guy, great developer, really “star” in your company, who started the discussion with “Agile is a crap…Why do we need all this overhead,why I can’t just code?”. At that moment I usually open my mouth, having the intention to say something, but instead I remain silent, my face become red, blue, green and then red again. I would better keep my thoughts at that moment off this post 🙂
So, let’s talk about the misconceptions about agile I come across. Some of them are mine, as I am not a genius and started with agile as all of you.
Are you as frustrated when you have to perform a demo to the client as me? Hope, I am not alone) I think, that the sprint demo is one of the most important meetings in the scrum process. It is the time to show our work to the product owner and make our progress transparent. For the team it is very important to celebrate their achievements and see what that achieved. Also it is a chance to receive valuable feedback.
Estimation is the core activity in Agile process. So making it faster and more accurate is the goal of every team. If we also can make it fun – great!
No doubt it is the one of the hardest thing – define, when your product will be shipped. So, taking into consideration all uncertainty of the estimation, planning poker proved to be the simple, but powerful estimation tool for the agile team. It was first described by James Grenning in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning.
As the every development team we have to survive the big stress in the beginning of the project: our clients usually have a lot of ideas, requirements and push us to give them the estimations ASAP) Once we tried story mapping as the requirements gathering tool and sticked to it for a long time. Story mapping appeared to be a great thing when you want to understand what your system is intended to do.
Prioritized backlog helps a lot, when you want to know what to do next, but it is not the best choice, when you want to think about the whole system. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog. Also it is a great tool for planning releases.