The major problems of our work are not so much technological as sociological in nature.
Most managers are willing to concede the idea that they’ve got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. They are forever on the lookout for a technical whizbang that promises to automate away part of the work. The most strongly people-oriented aspects of their responsibility are often given the lowest priority.
The text above is excerpted from the book “Peopleware” written by Tom DeMarco and Timothy Lister. I strongly agree with the fact the people are the most important success (or failure) factor for software development projects. I have a critical eye about what is really new in the Agile approaches because many of the technical practices like timeboxing or incremental and iterative development have already been known in software development. I have however to recognize that I like the Agile movement because it is bringing more focus on the people side of software development after a period where more “mechanistic” processes like the CMMI or RUP were dominant. Discussion, communication and feedback are more essential to project than a good diagram even if, as they say, “there is value in the items on the right”. And we shouldn’t forget to use this value.
It might be sadly this “people” side of Agile that will show the limits of its true adoption by organizations. My own experience is that companies are often not very good at handling the “people” aspects of doing business. Don’t they often call them “human resources”? As I was writing this post, a friend forwarded me an e-mail that he received at work: his company wanted to “improve its “agility”. Isn’t it nice? Not really, because the mail was discussing the upcoming layoffs that were planned by this (very profitable) multinational company. It is therefore true that there are many managers that have a “technological” view of the activity or project that they manage and you should not think that when you discuss how to be more “Agile” they share the same meaning than you.
To end this post on a funnier mood, the fact that we focus more on technology rather than people remind me of the story told me by some friends that had presented Scrum to a Swiss bank years ago when Agile was not well-known. The IT guys of the bank said:” This Agile thing seems very interesting. What software do we have to buy to make it work?” Technology is often not the best way to solve problems in software development (or elsewhere), but it can look like the easier solution….
Reference: Peopleware : Productive Projects and Teams (Third Edition), Tom DeMarco & Timothy Lister, Addison-Wesley, ISBN13: 978-0-321-93411-6