Mickaël’s Weblog

Software development methodology is hot topic, especially around agility. I’m still questioning myself on the notion of “people” in these methodologies. Xtreme programming is claiming putting “people” in the core of the methodology but why there not one principal based on ”people”.  What I’ve seen in the past years is that people develop their own methodology (or used to use a specific methodology) and are not tend to change their practice. I understand this as the change is naturally rejected by humans.

Phil Haack has written an interesting post on Bug Driven Development. Beyond the post, the comment from “she” is of high interest and I agree with it. “she” says:

The thing is, “bug driven development” is the most simple and straightforward one. Its a lot associated with experience too, the more experienced one gets, the less bugs he does (but it also depends on the language, and whether it supports certain coding schemes or not)

I think that the biggest difficulty his to convince people to drastically change their way of working. This can even put endanger a project. The source of the problem is when agile methodology is enforced by management (and they usually propose scrum, read this post on this). This put useless pressure on middle management to make the team adopt the methodology, produce disruption, and finally delay in the project.

The only way to avoid any problem on this is to hire people that believe in your methodology, demonstrate results and have excellent communication skills to convince others (a kind of propaganda).

Obviously, if you have not this choice…you will have to update your methodology !! This is esactly the same as for micro-management and macro-management: some folks need micro-management even if you dislike doing it…you will have to do it.

I’m a voluntary provocative on the post title; you can read Udi’s post. Udi also refers to a prior post of him (Don’t trust developers with project management) which is of interest.

This is all about estimates done by developers. I’m hearing frequently that estimates from developers are always under estimates and should be compensate by a factor. I thinks the “underestimate” assertion is not always wrong (maybe often true…) but I disagree on the way to handle such behaviour. The management is trying to balance the initial estimation with a magic factor which should make current and future project predictable and delivered on time. This approach can be discussed for its efficiency, but I’m mainly surprised on the fact that it can be summarized this way: a manager can’t trust developer estimates, but we can trust the manager. This is to me a very strange position for a manager: how can we trust more the guy which knows the less about the “hand-on-work” when he use a magic factor? More over, why hiring a developer if you don’t trust his(her) estimates?

I think this is the role of the manager (or project lead) to improve and support his(her) team. That means to me: learn them how to be more accurate in there estimates even if finally they will use a magic factor. This can be done also by providing data and tools to allow the team to understand better their estimates errors and be more accurate in the future. The manager is also the gate keeper for all changes requested that have an impact. I do not mean reject any change, but track them to have a clear vision of the project progress.

Apple sort l’iPhone …sans le téléphone: c’est l’iPod touch !

Vous trouverrez plus d’info ici.