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
Once you start working with the team that is really great, you stop thinking about the things that make them great – their greatness just exists and you “feel” it. But “feel” doesn’t work for me – I really need to describe, classify, plan and predict. So, let’s try to describe the features of a great team, so it would help us breed more great teams. Have you ever been a part of great team? Or worked with one? Please share your experience.
What makes the difference:
Continue reading Great team checklist
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
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
When I came up for the first time with the idea “Guys, why not to have a board for our project? Visualizing is so cool!” all the team looked at me as if I said something absurd. We had the status board in Jira and that seemed to be enough. I started talking about the benefits and future opportunities, but no one was as enthusiastic, as I. They treated it as “One more action I have to do when closing the task – move it on the board”. Finally, I got the support from the unexpected source – one or the girls in our team said – “We can use colorful stickers, so it would be so nice and pretty!” ^_^ That is where our story begins.
Continue reading One scrum board life story