Over the last year or so I have had lots of good, robust discussions with other Agile coaches and one thing started to worry me. I heard “But that is not Agile” or “But that is not REAL DevOps” more and more frequently. While I agree that we should always strive for better and better performance, the absolutes seem counterproductive to me. Two topics close to my heart seem to cause this kind of reaction more often than others.
SAFe – The Scaled Agile Framework
There is lots of discussion on the Internet about SAFe and why it is or why it is not really that Agile. Most organizations that I talk to are nowhere close to the maturity that you assume when you see the SAFe framework. I am sure that there are companies who are further down their Agile path and think that SAFe is very restrictive and old-school. I have to say that most people I talk to would be extremely happy if they could achieve the Agility that SAFe can provide. And it is a framework after all, a bit like a scaffold that you can use to move forward from the old Waterfall ways into a more Agile enterprise without throwing everything out. And yes, once you think that SAFe is not challenging your organization and you see opportunities to become even more effective—go ahead, push yourself further. For now, I am quite happy to use the SAFe framework within large organizations to help me speak a language my clients understand and to push them a bit further on their journey. I will have to admit that probably I have not spent enough time with the other scaled Agile ideas to judge them all and perhaps writing this blog can be a motivation to do that. For now, SAFe is my go-to framework of choice. And I think that even those who argue it’s not really Agile would agree that many organizations would be more Agile if they had implemented SAFe than they are now – and that’s good enough, for now!
So many organizations and projects I encounter do not have the right technical practices in place that allow them to deliver solutions effectively. Practices like configuration management, automation of build, deployment and test, and environment management I think belong under the big headline of DevOps. So when I talk about DevOps practices with peers at conferences and describe that in large organizations I often recommend a DevOps team to start with, I hear “But that is not what DevOps is about.” The often-quoted cultural barriers between Operations and Development in large organizations make it simply impossible to embed an operations guy in each development team. And to be honest, there are often many more development teams than operations folks who could be embedded. So why wouldn’t I then create a team with representation from both sides to begin with and to get the best guys into that team to solve the difficult technical problems. After all, that is what Google has done with their Engineering Tools team. I think that is a valid step, and yes, perhaps afterwards we push this further but for now most organizations that I have been working with can gain a lot from good practices being implemented through a DevOps team. Having a DevOps team does not mean we don’t want to change the culture, it just means we want to do this one step at a time.