What I have to say about self-organizing teams


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

Persona tips for dummies


It is time to write in more details about persona’s creation, as I promised in one of my previous articles. I collected all the tips we developed while working with persona. This step is often skipped, but without it we can’t find out our target user needs, as we actually don’t know who are our users. Persona provide us a great testing filter for all our ideas and features. They guide us to make certain decisions, even we are just the development team and product owner is far-far away over the ocean. We used persona in the development teams not to forget about our users and always validated any action with “Would John like this?”. On the initial stages of the project personas are the powerful tool to map your ideas on the real people’s needs.

Continue reading Persona tips for dummies

Cross-functional teams: changing the manager’s mindset


A lot of software development companies have the structure based on discipline – you can come across development department (which can be divided by discipline too: mobile, front-end development, etc), design, QA, etc. Sometimes some mixed disciplines teams are formed for the project, but they depend a lot on the departments and members of these teams are not full time involved into the teams and report to their “manager” – head of department, for making their own tasks. So you can see something like “Ok, project failed, but the QA department work was wonderful!” Who cares, if the project failed?

Continue reading Cross-functional teams: changing the manager’s mindset

Why start with why


Recently I came across the wonderful TED talk by Simon Sinek and his speech was like “I was thinking about the same thing!” to me. But he was brilliant summarizing it. It works for any company. We are not Apple, we are not selling computers, we sell services – software development services. But it works for our company too! I spent a lot of time talking to the top managers and hr department about “why”, but now I even have a respected source to mention and a great illustration to it. So I spent some time and went through exercise – how our company can use this.

Continue reading Why start with why

Sprint 0: what we do prior to coding


When we talk about the development process in outsourcing with my colleagues we usually “start” project with development phase: “So, we got that project and started with the team our sprint 1”. It is the most often phrase you can hear about the kick-off of the project. In the books about scrum you can find a lot about sprints, but so few about sprint 0 and preparation to the development. They start with “Ok, we have a list of features and we need to estimate them and get a backlog”. But where from we get this list of features? We start with design and then hang this design to the developers? Of course, not. We need a good Sprint 0 with a team to be able to start development. And then I discovered that we even need Sprint -1, where we go through the analysis of the project idea.

I just want to share my practical experience, which suits for the outsourcing software development company, that wants to deliver better product-oriented service. I am surprised how far from that we can be in some of our big outsourcing leaders.

Continue reading Sprint 0: what we do prior to coding

Product idea inception – discovery exercise

I became much lazier during the last couple of years – I need to hear a good reason to start doing something. The same when it comes to work – “why?” became one of my favourite questions. I discovered how many things are done without the reason. Ask “Why do we need this new type of report?”  and then repeat the question unless you get deep to the real reason. When you finally get to smth the like “Because everyone does it!” – you can show the maximum understanding of the problem on your face while leaving the room and going to the kitchen to prepare a cup of coffee and get back to reading Reddit. Try and you’ll be surprised too.

Continue reading Product idea inception – discovery exercise

How to undestand you ride a dead horse

Finally, it’s my turn to write about the dead projects. Mostly because I am taking part in more than one now. I collected my observations during the last months and am ready to share them. Let’s start from the most important thing – how to realize that you are working in the zombie project. Zombie – because you can’t say, it’s dead – sometimes a huge team is working on it and you can swear you hear it’s breathing. But it can be only the sound of wind in the tubes.

How to find out that your project is a zombie

Continue reading How to undestand you ride a dead horse

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?

Great team checklist

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

Why do customers need reports

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