What I have to say about self-organizing teams

IMG_4911

Remember Agile manifesto? ‘The best architectures, requirements, and designs emerge from self-organizing teams’. But why self-organizing teams? How to build them? How do they emerge?

When I say “self-organizing teams” top managers usually think ‘teams which need no management’, ‘magic teams which work twice as much’. They behave as if we can just hire 10 nice people, put them in one room and tell them “And now you have to self-organize.’ We talk a lot about such teams, but rarely can we assemble one. Some of my colleagues even say that it is a luxury to have such teams and we just can’t afford them.

I tried to collect all my thoughts on the self-organizing teams in this post.

Continue reading What I have to say about self-organizing teams

Ok…But who is resposible for delivery?

Decided to create this post as I’ve heard this question many times during the last 3 weeks. Several people asked that during the cspo training; clients asked 2 times; my boss and my colleagues could not omit this question too(3 times in total). So I want to share some of my thoughts on this topic.

Let’s imagine a scrum team, which is working on a Product. We have a Scrum master – a nice guy – and a Product owner, who has a lot of great ideas and drives the product on. The team works hard every sprint (yes, they play tennis and drink coffee several times a day. And… oh, hell… they even read facebook and watch cat videos during the working hours. So, just an average team). And one day their stakeholder/big boss comes and asks Scrum Master, “Ok, I see the team is working. You have a scrum master, a product owner… But we have a release planned in 2 months. So, tell me, who is responsible for the delivery? Who is responsible for the release being shipped on time?”

Continue reading Ok…But who is resposible for delivery?

It seems that I hate estimations. Really?

Once (ok, let’s be honest, not just once) I was thinking, “Why not to get rid of estimations?”. I heard a lot from the developers in our company that they hate estimating. That is usually a very painful process for a project manager, too. Not only because of the process itself, but because of what happens afterwards. If you worked on more than one project, you definitely know that the estimation your team created won’t be ok for business people. They certainly know that this feature is very easy and that story can be done in a day… Or, “My colleague – he is a developer himself – thinks this can be done in a week!”. They all need hours, exact numbers and deadlines. Team wishes not to provide that.

Continue reading It seems that I hate estimations. Really?

Crappy code – keep your team happy

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

Growing incredible teams: some useful tips

Working as the project manager in outsourcing companies in our country means that you are responsible for almost everything – writing the specification, creating application prototypes, schedules, plans. Sometimes you can even find yourself writing tests or editing designs. As a result, busy and tired PMs completely forget about their teams. They start treating them as resources. 1 item of development resource. “Hmm…Let’s put this 2 items on this projects and that one will go here. They are from the different offices/buildings? No matter…They are professionals! So they just have to write code.” As people are simply the “functions” they provide. And not even noticing we start using all the tips from “How to prevent teams formation” list.

Continue reading Growing incredible teams: some useful tips

Common problems while adopting scrum

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.

Continue reading Common problems while adopting scrum

We vs they: agile testing

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.

Continue reading We vs they: agile testing

Offshore Agile – when your PO is far away

I am sure this scenario will sound so familiar to you. You have a great agile team and great PO overseas. But he can’t devote much time to the distributed team. Yes, you asked him and he tried. But failed –  he can’t spent so much time on discussing these user stories. The team starts suffering from the lack of understanding. The user stories are not ready for the development – they are not analyzed and communicated properly. If you ever solved the same issue – let’s continue discussion in the post.

Continue reading Offshore Agile – when your PO is far away

How we do retrospectives

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.

Continue reading How we do retrospectives