Everyone takes responsibility for all aspects of quality and testing, including those related to deployment pipelines, monitoring, and observability.
A DevOps culture is, to me, the same as what an agile culture was meant to be. We donāt work in silos, we donāt wait for another team to do something for us. We share our knowledge and help others learn the skills, and are there to support each other as needed.
Donāt underestimate your ability as a change agent. The secret is to find your allies.
Lisa also shares a set of handy questions to get started with building relationships with ops people.
How about you, what does DevOps culture mean to you?
And how do you build those all-important relationships?
Iām so glad you enjoyed the post, and thanks for starting a conversation here! Iāve met a lot of testing professionals who think DevOps is for someone else in the organization. My experience has been the opposite. A few years ago I used the term āDevTestOpsā, but someone pointed out to me how many testing activities are central to DevOps. Collaborating to assess risks, to strategize how to deliver a new feature, to think how weāll know if a new change is valuable to customers, that all involves testing. We testers make big contributions.
Thank you @lisa.crispin for raising this issue. The roots of DevOps are in Demingās 14 Points for Management. Demingās philosophy also was an important influence on agile. The 14 Points include psychological safety, which is an important point for me because so much depends upon it: Drive out fear to improve psychological safety ā TestAndAnalysis
Definitely! And itās reflected in the larger community. For example, I joined the DORA (DevOps Research and Assessment at Google, who do the State of DevOps survey and report) community. I thought it would be all platform engineers and SREs, but the members are from a wide variety of backgrounds. And most conversations end up being about testing in some way!
Iām not that familiar with Demingās work, to be honest. So cool that people like him were talking about the need for psychological safety even years ago.
I am also a member of the DORA Community, and found its disucssions really interesting. One of the discussions led me to write this: Are you testing output and outcome? ā TestAndAnalysis It is great that you are reading and John Willisā book it is a good introduction to Demingās philosophy. I have been talking with him recently too
@lisa.crispin I have been thinking about this. I find that if I understand the history of an idea I understand the idea better. John Willis, who is one of the creators of DevOps, talks about the history of ideas in our space. The short version of the history of ideas he speaks about is: Deming ā Toyota ā Lean ā Agile. This means that you find Demingās philosophy in Toyota, Lean, Agile and DevOps and is why I find Demingās philosophy useful. Do you find the history of idea useful too?
For sure! Interestingly, in our small breakout group in todayās DORA community discussion, someone asked if there was any history written about the growth of Scrum, XP, agile from the mid 90ās to the mid 00s. Some folks talked about agile being a reaction to waterfall, and DevOps being a reaction to agile. Thatās maybe too simplistic, but I think we do need to learn from history. Iām told that the John Willis book is a good way for someone like me to learn more about Demingās work, so I look forward to that.
Rosie, itās interesting. Iām not so much an āinsiderā in the DevOps community - though, I think we are ALL part of it. When I think of my own ātesting communityā, it encompasses the MoT community, the Agile Testing days community, and a lot of people Iāve met over the years. Years ago people talked about āschools of testingā and I was never a fan of that idea. You are a wizard of community building, Iām interested in your thoughts.
Devops culture is closely tied to testing but I think its only tied to the āwhen to do testingā.
All the other Ws and Hows are more on the testing side.
Recently, Iāve noticed some DevOps knowledge advocating all code and no hands on approach towards testing. That, I donāt like.