How to understand developers are really working hard: manager’s guide

Posted on by tisquiiirrel

IMG_8110

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?”

Continue reading How to understand developers are really working hard: manager’s guide

Why do customers need reports

Posted on by tisquiiirrel

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.

Continue reading Why do customers need reports

Crappy code – keep your team happy

Posted on by tisquiiirrel

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!”.

Continue reading Crappy code – keep your team happy

The truth kills me: Half of the features will never be used

Posted on by tisquiiirrel

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…

Continue reading The truth kills me: Half of the features will never be used

Retrospective – what stops your boat

Posted on by tisquiiirrel

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.

Continue reading Retrospective – what stops your boat

The most boring meetings ever

Posted on by tisquiiirrel

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.

Continue reading The most boring meetings ever

Misconceptions about agile

Posted on by tisquiiirrel

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.

Continue reading Misconceptions about agile

Planning poker

Posted on by tisquiiirrel

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.

Continue reading Planning poker

Story Mapping: How we do it

Posted on by tisquiiirrel

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.

Continue reading Story Mapping: How we do it