I read a lot of books about what practices work well or not in software development. And I have NEVER heard about methodoly like ITIL or CMMI in any webcast or book or blogs in the development field.
I have heard about these methodologies in my school, and to me it seems to be bureaucratic practices.
However every books on development I've read talk about collaboration, or people over documentation. (Yes, lots of agile books)
So my question is : Does methodologies like ITIL or CMMI have some impact or relation with development or the everyday life of the developer ? And do you have great books or blogs which talk about some good ideas in these metodologies I can use on a development team ?
ITIL is more focused on the infrastructure and support side and not development, so discussion of ITIL is probably more appropriate on the "IT" focused version of StackOverflow that is supposedly in development. As an aside, I take exception with calling that other site "IT" focused as IT encompasses infrastructure, support, and development in most enterprises...probably a good percentage of StackOverflow users are developers in IT departments.
I've worked with CMMI and the Team Software Process (TSP), both products of Watts Humphrey and the Carnegie Mellon Software Engineering Institute. If you are committed to continuous improvement and believe that measurement is at the heart of any continuous improvement, then you will find value in CMMI.
It is very easy to do CMMI (and TSP) wrong or in a way that alienates developers and ultimately ends up as window dressing or something that looks good on a pile of certifications. Look at the development vendors in India...they are miraculously all CMMI level 5. What they don't tell you is that was almost always one small project or team in their organization that worked hard to get the certification, but the repeatable practices are simply not there for 95% of their organization.
The focus on time tracking (clock punching), defect tracking (bug quotas), lines of code (lots of ways to "game" if you are so inclined), and making your process repeatable (making a developer feel like a cog with no freedom to innovate) turn off many developers. <-- note the jaded counter-arguments in parentheses.
The fact remains that 90% of the developers out there (few of which read StackOverflow or any technical blogs/web sites) shoot from the hip and are sorely lacking in self-awareness of where their opportunities to improve reside. For them, the process rigor and opportunity to make incremental improvements in quality through the self-awareness that repetition and measurement facilitate are valuable components of CMMI.
Done right, you get the same benefits from Agile methods like Scrum where again the focus is on repeatable iterations, learning from each iteration, and improving/narrowing in on your goal. It takes a lot of maturity and experience to lead a team in adopting either Agile methods or CMMI and get full value out of them.
Agile is sexy and CMMI is about as far from sexy as you can get, which is why you don't hear about it as much.