olly - Fotolia
Every company from an IT standpoint is messed up.
You have these little fiefdoms, dev vs. ops, because ops guys and dev guys don't play in the sandbox. The ops guy just wants to watch the lights; the dev guy just wants to toss stuff over the fence. Yet, the ops guy becomes obsolete if he doesn't learn something new, and the dev guy always wants to move onto the next cool thing.
If the two work together, the ops guy might feed back to the dev guy, "These are the things you toss over the fence to me that are all broken and don't work." Or ops might say, "When you give me a tool, these are the things that make my life easier." Now, the dev guy has this in mind for the future. So, when the dev guy does hand things down the line to the ops guy, he takes it in with open arms. Now, it's a partnership.
In terms of the security team, instead of refusing, they have to say, "Hey, you're putting this in, and I understand there's a reason -- these are the things you want to watch for; these are the things to do to test this out and make sure we're good to go."
Who needs DevOps?
That's what always baffled me about DevOps. Why do you have to come up with a term? Instead of dev vs. ops, that partnership should be there already. From my own personal experience, I could push things through when no one else could, even between Thanksgiving and Christmas, because I worked and partnered with operational people and knew how to make their lives easier. Before going live, the operational team would be brought into the loop to provide feedback, input to improvements or new solutions.
Of course, one problem is that leadership is up a million feet from the day-to-day stuff. Also, IT doesn't communicate with itself well; again, it's dev vs. ops, with neither communicating with the business side well.
I think there's a CIO school where all of the CIOs get together -- they all have the same speak. There's almost a disconnect: I know they're really busy and they're getting squeezed by the business, but they need to think about what they're saying for a minute. And, in bigger corporations, the left hand doesn't know what the right hand is doing. Leadership needs to seek out input, and employees cannot be afraid to say what is and is not working. Everything becomes siloed -- whether by design or not.
Where should Agile be headed?
What's holding Agile methodologies from widespread enterprise adoption? While many at Agile 2017 felt this development model is at a crossroads, there's some consensus that the next step depends on leadership. Management must turn the ship and then get out of way.