New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You may be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others. A relatively new kid on the block is DevSecOps. What does that mean? Where did it come from? Why is it important? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome? In this session I’ll explore the origins of DevSecOps before going on to demonstrate the distance between the label and the intent of DevSecOps. Finally I’ll try to generalise the journey from “good idea” to “empty slogan” that seems to underpin many of the hyped transformations that I’ve lived through during my 40 year career in software. Along the way I’ll describe a form of structured interaction that can relieve the tension between team autonomy and centralised control.