To my surprise, the previous post about the influences of job market regulations on agile development in Italy has been cited in an InfoQ article, and had a couple of interesting comments. This glamorous parenthesis happened while I was on holiday, and my Inbox was dangerously inflating. So, after getting back to work and diligently processed all of the issues waiting for me, here's the second part of my post.
The "too much process" rebound
Be it for our latin nature, be it the average size of projects and companies, I've never faced a situation in which "too much process" or "too much paper" was an issue. There can be a correlation with the Italian job market issues presented in my previous post, in the sense that structured processes definition were meant also as a way of protecting the project from turnover, by making everyone a "replaceable part" of the process. Agile practices lowered the process burden, and put the emphasis on individuals implicitly stating that the best way to handle turnover is to have no turnover at all, thus putting some effort in transforming the team in a nice place to work in.
The average company, has instead sort of a "raw" development process instead, and spoken words prevail on written ones. Given this scenario, I feel like I am a sort of "fake agilist", because many times my job is not to strive for a thinner process definition, but just set up a process, whatever it might be. I also think that one needs to start from something structured, to acquire degrees of freedom later: as an example, even if I fancy the "user story" concept a lot, I seldom use it in undisciplined contexts, and favor a more traditional use case approach. Once you master use cases and are able to distinguish the key parts of the specifications, you can benefit from a less structured and more distilled way to express them. Doing otherwise will probably result in a "blank paper syndrome".
Letting the kids play
Apart from careful people selection and the job market issues discussed here, the single most effective team motivator is probably the introduction of a new "cool" technology in the project. This approach is particularly effective in situations where the technology scenario is particularly flat. Once, I've found myself pushing for a technology change, and the only real reason for it was to have something new to "let the kids play", and to have a motivated team. Of course, there is a limit to the number of new concurrent technologies that a team can master simultaneously, but a "technically boring" project breeds low motivation, and turnover (so you have learning costs anyway) and productivity tends to flatten in the long term.
