I spend maybe half of my time working alongside developers to define security controls that need to be added, verifying they were implemented, and testing production. I do this because I realized when reading The Phoenix Project that the only way for security to be taken seriously by a company, I have to have an integral hand in the SDLC. Ironically enough, by defining the security controls that must be put into scope this early in the process, I also am able to make sure our software maintains compliance. This experience will be very different for a company that has more technical debt then we do, keep in mind.
I spend maybe 10% of my time on compliance. However, this is because we've already achieved our benchmarks; I only focus on determining violations, remediation, and making sure the company is ready for the next audit. Like I said, we have little technical debt and I work tirelessly to make sure security controls have been identified before the scrum starts. Back when I was working to get us to this point, I spent perhaps 90% of my time learning about the compliance benchmarks we needed to achieve and when needed to happen for us to get there.
Where I do see compliance come up is from customer demand or niche applications (healthcare). Even so, compliance is more about people and paper than technology, so yeah it takes longer, it's bureaucracy!