 Hi everybody, I'm Jen Krieger and I'm an agile coach at Red Hat working with the teams developing Project Atomic and OpenShift. Earlier this year, Fedora project leader Matt Miller asked me if I would go to Brno and do an agile talk for DevConf. My talk went through a few durations but it winded up somewhere in the space of how Project Atomic was delivering software using agile principles and practices. I worked really hard on that talk and I thought I did an excellent job. However, when I returned to the States a few weeks later, I received what I classify as the most epic conference feedback ever. Your talk was poop. I was dismayed but in reality it solidified a thought that I had for a while which I think is a large problem with the way that we talk about agile, which technically is exactly that, the way we talk about agile. Agiles have failed to deliver the message in a way that the open source community understands because let's face it, the current market for agile is essentially an executive or a manager looking to purchase training to help their teams solve their problems. So I'm here to give you a five minute rundown of how we can get around the marketing of agile and to get to the truth of what it really is intended to be. And the way I like to have this conversation is simple. I'm going to talk about four things that I have heard recently at Red Hat and if you notice somebody blushing in the audience, chances are it's that person who said it. Agile has two-week sprints that would never work in an open source community. Agile is not scrum. Scrum is about two-week sprints but it doesn't always have to be what you use. In fact, scrum is one of 40-plus methods that suggests how people could work together. However, XP, Kanban, the scaled agile framework, Lean, large-scale scrum, Spotify's quantification method, DevOps, these are all things that are aligned with Agile and they kind of suggest how you can be agile. However, I'm hoping the majority of you have maybe heard, released early, released often, which was a philosophy that was popularized by Eric Raymond via his essay The Cathedral in the Bazaar, Bazaar was basically published around 1997, which was largely written based on observations of how the Linux kernel community worked. And although I don't think the original signers of the agile manifesto, you know, stole from open source, I think the intention and spirit behind it was actually very similar. Agile is all about speed, forget design, quality, security, and documentation. Agile is not always about speed, but it is about fast feedback loops. So whatever method you choose, the intention behind the implementation is that you get feedback and basically on what you're working on, the code you're writing as soon as possible. Great agilists know that the way to get feedback is to have version control in place, continuous integration, delivery, automated testing, you name it. Similar to the way that open source communities could potentially use GitHub and Jenkins to provide feedback on a PR that is potentially going to merge. Agile only allows for one person to define the product requirements, the product owner. So who is this mysterious product owner anyway? The product owner is a role that is basically defined within the concept of Scrum. Basically this person is responsible to help guide the development teams to make sure they stay on track and generally they work with a product manager to understand the market or understand where the product needs to go. Consider the concept of a product owner very similar to a core maintainer within an open source community. Core maintainers are generally somebody who's going to review code, provide comments, or eventually merge functionality that is intuitive or respectful of what it is they want their project to do. So I would say while the name is maybe new to some of you, it's not a concept that is actually new at all, it's probably something that you're already doing. Agile requires people to be in the same place. I get the impression that when we talk about collocated teams, everyone is thinking that it looks something like this. I assure you having everyone close helps with communication, but it's not 100% necessary in terms of doing Agile. It's just one of those things that makes things a little bit easier. And I would argue that open source community already knows that true because the evidence is here in this room. Conferences like All Things Open bring community members together to help us make that face-to-face relationship before scattering off to the wind and using old school forms of communication that we're used to using. And so while many Agile trainers are all about having teams in one place and they say that's pretty much the only way to do it, I would say be aware of what your community needs to be successful and adjust the way that you're doing to bend around those needs. And please don't balk because someone said the term Agile to you and you were like eh. Instead think Agile just forked the open source community and used to create software and added a little bit more code to it. Thank you.