The winner takes it all

How more likely is it that you lose if you’re convinced that you will lose? No, I don’t think the stuff in The Secret, but I believe in the power of the mind and beliefs. If you’re convinced that you will see Santa Claus you will probably see him, or at least; imagine that you saw him.

Success is no different. Successful athletes imagine themselves winning and those who from start are convinced that they will not succeed seldom finish on top. If you don’t count short track skaters from Australia, that is.

I think that one of the core concepts of agile software development and scrum is building in a faith in the own success. You leave the estimates and the commitment to the people who are going to do the actual work. You just plan as much as you need to be able to change the plan according to actual progress.

When you are successful, you get happy about it. You feel proud and you know you can be successful. Perhaps you also like the feeling of winning and want to feel that again.

We just finished a very successful sprint and I think we all felt happy to go home today. Not just because it’s finally spring here in Sweden, but that we can next week deliver som real and good customer value to our users and customers. And that what it’s all about. What else matters (in software development), really?

As ABBA put it in the good old days:

The winner takes it all

The loser standing small

Project Management – the root of technical debt?

I’m currently labeled Project Manager. According to Wikipedia, that is defined as:

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.

If you read that definition, you can see that the project manager is responsible for the project. The guardian of the project. Responsible for the project being finished on time, on budget and with the right features.

Many companies are conducting their development in project management style. When introducing a new big feature to the IT environment, a project is formed and a project manager assigned. So far, so good. The introduction of project management is often a huge step forward for organisations previously just using ad hoc system development, but there are also big risks to be taken into consideration. It’s not for nothing that the agile software development movement has risen. Projects are over budget, late and include the wrong features. But even if we overcome those problems, there is still other problems with project management and that is project management guard the project, not the complete system environment. In the definition it does not say that one should look at the whole system of an organisation. And the same picture can also be found in the literature I’ve covered in my class in project management. You could bring it down to the following: make sure YOUR project is successful.

So, what does this mean. This is an example I’ve seen to often. A project is started and when the time is running out, it becomes clear that a current feature can not remain as it is when the project is completed and has to be remade. The project manager thinks this is not part of the project and refuse to include the changes on his budget, since that feature has nothing to do with his project. So, the other feature just stops working or a poor developer makes a quick fix, which works poorly.

Another example can be that a project is carried out and a new process is introduced. This can be automated, but this is more expensive. The project manager does not want this on his budget so the process is manual. Then a new project is introduced and the same process is to be used. Since the first project uses the manual process, the project manager thinks this is ok in this case too. The operations (for they are all too often the ones to carry out the manual step) starts complaining that this takes too much time and that there are room for so many errors. But the project manager thinks that automating that process should not fall on his budget.

Yet another example is when time is running out, the developers fight hard to meet the deadline. So, bugs are introduced and technical debt is built through the using of in the long run poor quick fixes. The project is completed, the final report is written. But then after a month or two, the incidents start to build up. The project was successful in itself, but the effects on the whole was a failure.

This is not acceptable. Perhaps these stories are not as common as I believe, but I keep hearing them all the time. Project management can be the root of sub optimizing and there are few tools within the project management field to cope with these questions.

If you boil these issues down, I see them as technical debt. You are harming the system as a whole to make sure a new feature is working. And this is OK if all the other systems are useless or worth less. But we all know that this is not the case. The project manager might think so, but…

I have some statements I would like to add to the role of a project manager. I’m fully aware that this can make the title misguided, but I think the issues are more important than the title.

• We consider the deployment environment is to be considered as holy ground.
  A project manager should tread carefully on the deployment environment and guard it like it was sacred. We guard the environment to make it safer whenever this is possible
   
• We don’t cause harm to current functionality
  We don’t introduce code which is worse than the one which was there! We don’t make things worse for operations!

I’ll probably get back to this subject, if I’m not killed as a traitor by some other project manager.