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!”.
Have you heard someone saying “I tried scrum and it didn’t work. Scrum is not working at all!” I heard that many times. It is difficult to admire that it was not the methodology fault, it was your fault that everything failed. The big challenge is that there is no out of a box solution, which suits anyone. You need to go through all the way from the learning to mastery, face a lot of difficulties, overcome them, master the copying and them move to adopting the process for you – changing and improving it. So let’t discuss the problems PM can face while adopting new methodology (you know what I talking about ^_^) All these promlems are from my and my colleagues experience.
We talk a lot about developers in agile processes but sometimes almost forget about testers. They are usually rather calm and silent people, so they pass through all the project launch meetings and then come to me to ask the important question “Agile is great…But what should I do with my testing activities? What is the role of QA in agile processes?”
As usual, I start my answer with “Folk, it really depends… Let’s see what we might do this time”. So, I will try to describe what we tried and how we failed/succeeded.
It is time for my first post to be translated 🙂
No doubt retrospectives are one of the most important meeting in the development process. But teams usually tend to ignore them. If you don’t push them they just stop doing retrospectives at all, as this activity seems “useless” to them. But when else can we get such a magical push and start changing for the better, if not during retrospective? We can continue making the same mistakes over and over again.
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.
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.
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?
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.