<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Agile Testing on Romano Roth</title><link>https://romanoroth.com/en/tags/agile-testing/</link><description>Recent content in Agile Testing on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Romano Roth</copyright><lastBuildDate>Sat, 17 Feb 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/en/tags/agile-testing/index.xml" rel="self" type="application/rss+xml"/><item><title>DevOps in an Embedded World: From Silos to Digital Factories</title><link>https://romanoroth.com/en/blogs/devops-in-an-embedded-world/</link><pubDate>Sat, 17 Feb 2024 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/devops-in-an-embedded-world/</guid><description>&lt;p>Many people still think DevOps is only for web applications and cloud services. But the reality is clear: companies that apply DevOps principles to embedded systems are outpacing their competition. In this talk, which I gave at a DevOps Meetup in Munich, I explore why embedded teams need DevOps and how to build a Digital Factory that enables continuous value delivery, even for hardware products.&lt;/p></description></item><item><title>DevOps: Thinking in Systems and Value Streams</title><link>https://romanoroth.com/en/blogs/devops-thinking-in-systems-and-value-streams/</link><pubDate>Wed, 19 Oct 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/devops-thinking-in-systems-and-value-streams/</guid><description>&lt;p>In this conference talk, I discuss one of the most fundamental topics in DevOps: thinking in systems and value streams. When I work with companies on their DevOps transformations, I consistently see the same patterns. The business has bright ideas. They write them into Word documents and Jira tickets. They throw them over a wall of confusion to development. Development builds something and throws it to testing. Testing compares what was specified with what was built (never quite the same), tests something, and throws it to operations. Operations asks &amp;ldquo;How can we operate that?&amp;rdquo; and somehow, with great effort, they get it running. Then the customer sees it and says: &amp;ldquo;What is that? That is not what we ordered.&amp;rdquo;&lt;/p></description></item></channel></rss>