That's right don't even attempt to do DevOps without Change/Incident Management. Not because you won't be successful in at least small ways. Not because people won't appreciate you automating your companies one hundred and fifty servers in five minutes instead of five days. But because you won't be able to prove any benefit of DevOps to Management. That means they won't appreciate it, value it, or the most important part FUND it.
There are a lot of other reasons you shouldn't do DevOps with a set of agreed to rules to play by. Until you have the rules of how and when you can make changes you can't easily show how long it takes to make a change manually versus with automation. You won't be able to show that you made this many mistakes doing it manually versus with scripts. You need to have a third party, the change or project manager, to say it took some amount of time and we had some number of errors without automation. Then they can validate that after automating you reduced the time and the number of errors.
The next problem is that without rules and processes you and your team can be Gunslingers firing off fixes in every direction. The problem with Gunslingers is that only one-third of them made it past age 35. In IT when you are a Gunslinger you can take the whole company down with one bad shot. If you worked for a Bank and fired off a fix that switched to a Self-Signed SSL Cert as opposed to the officially signed one, that could cost the company millions of dollars in fines. Not to mention the PR campaign to reset expectations of the public. Automation doesn't prevent this time of problem it only makes it faster and easier to push out. There is also the issue of tripping over other teams changes. There is no worse feeling than having the corporate VPN connection go down in the middle of your change. A small amount of communications can go a long way. It might mean that you loose a little sleep when you want to put the change in. When you don't have to spend hours troubleshooting something that was caused by another teams change you will start to appreciate it.
Finally if you aren't tracking the changes you will have a nearly impossible time linking incidents and problems to changes. If you don't know all the things that changed you can't be sure you found the real root cause. Remember that problem you thought was the local firewall are you sure it wasn't just a change in the router? Are you sure that it wasn't the fix for that that fixed your problem? Without a change management process that tells you about all the changes you can't say that it happened.
So embrace the change and incident management process. It really can be the difference between being employed and unemployed. ITIL has a great framework for you to start from that is completely customizable to fit any style, type, industry or size business. So whether it's Excel Spreadsheets or a fancy web app embrace it and help it to mature.