Yep. Show me an org with a software group that is a part of IT, subject to IT bureaucracy, and I'll show you a software group that delivers software no one wants once a quarter (or something equally as ludicrous).
Maybe a 'one true Scotsman' argument, but every 'software group' that was a part of IT that I've seen might as well be called the 'personal project group', because they spent more time working on those than they did making progress in that environment.
Right, and the aggregate affect it has on individuals, and that creation of a feedback loop, is useful to understand for why the culture won't change. I'm just listing out how the initial expectations and organizational incentives in IT tend to run counter to what is needed in software. IT you don't -want- agility, and so you purposely structure your org to make change as difficult as possible. Software development that gets structured that way tends to be developed very, very slowly, and with no real user feedback. IT basically mandates waterfall approaches, decision by committee, and dilution of responsibility.
Maybe a 'one true Scotsman' argument, but every 'software group' that was a part of IT that I've seen might as well be called the 'personal project group', because they spent more time working on those than they did making progress in that environment.