What is the impact of ITIL or CMMI on the development?

Question

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 ?

Answer 1

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.

Answer 2

Agile adoption tends to be bottom-up: techies stumble upon it and recommend it to management.

ITIL/CMMI tends to be top-down: management stumbles upon it and pushes it down to techies.

That doesn't make one good and the other bad; mostly that affects the language used to describe each approach. And there are plenty of exceptions - people with experience in the trenches who are good at applying CMMI, and managers who grok agile.

Google for "agile CMMI" and you will get many hits. I prefer not to recommend one in particular, because it's an ongoing debate (i.e. some of these folks are just plain wrong).

In my view, the notion of process is certainly a useful idea to have when analyzing day-to-day software development work. The idea that there are some recurring activities, and that these activities are often organized in similar sequences, is a good entry point for asking questions that lead to improvement. You can also get some mileage by asking what is repeatable and under what conditions activities can be called managed.

The error and the excesses begin when magical thinking sets in: "If we just describe (on paper) the Perfect Process and document it accurately, people will follow it and we will get perfect software." It doesn't work that way.