[lostcolony]

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.

[ethbr0]

I think of it as people-inertia too.

If IT sucks for people who want to change things and roll out new and exciting products, most of those people will... not work in IT.

Consequently, when you're soliciting ideas from your team, there aren't any of those people to speak up.

And if no one asks "Why are we doing this?" or "What if we did this differently?", then it's much easier to pretend another way doesn't exist.

[lostcolony]

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.