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?”
If you are a project manager you definitely have ever told your colleagues “I hate these reports! Why do they require those stupid report for every tracked hour? I spend several hours to create it!” You have a weekly call with the customer on the status and have to prepare for it whole the day? You hate Mondays, not only because it is the hardest day of the working week but also because report call? You have to explain each hour spent on the project? It rings the bell? If yes, we are on the same side.
Several months ago I joined the new for me project team. They have been working on this product for more than a year. You know what it means for the mobile project – we have a tons of code created) So, one of the most severe issues guys mentioned is the crappy code – developers told me that during the first retrospective we had. My first reaction was – “So why do you create this crappy code?”. But the answer was very easy for them – “We inherited that code from the previous team, they created all this awful things!”.
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…
One more translation of one of my first posts.
Want to share with you one more idea for the key retrospective activity – discussion of the good and bad things in the previous sprint. Scrum master/PM has to incorporate fun into the routine meetings. Every time I get prepared to the retrospective I browse web to find some new ideas. If I can find nothing I have to do the most complicated thing that I hate – think by myself.
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.
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.