Answers: <p>I've heard many, many different definitions of DevOps.  They include:</p>
  
  <ul>
  <li>Developers handling operations tasks</li>
  <li>One person doing twice as much work (in the same amount of time)</li>
  <li>Developers and operations teams working with each other</li>
  <li>Operations work for developer tooling (in the vein of "Web Ops")</li>
  <li>A job title for someone who creates and maintains developer tooling</li>
  <li>The use of automation in operations</li>
  <li>The use of public clouds in operations</li>
  <li>A job that combines aspects of operations, development, and quality assurance</li>
  <li>A job that entails helping the development and operations teams work together</li>
  <li>A philosophy of breaking down barriers between teams</li>
  <li>Treating infrastructure as code</li>
  <li>What you get when former software engineers move into operations</li>
  <li>A completely meaningless buzzword</li>
  </ul>
  
  <p>There is no public consensus on what DevOps actually <em>is</em>.  A few years back we had similar problems with "Agile", and that <a href="http://agilemanifesto.org/" rel="noreferrer">has a written definition</a>.</p>
  
  <p>When introducing your concepts to a newcomer, I'd focus on introducing the concepts, rather than applying a label, or else they'll end up hearing conflicting definitions and being confused.  For instance, if you're trying to talk about <a href="https://en.wikipedia.org/wiki/Infrastructure_as_Code" rel="noreferrer">infrastructure as code</a>, tell them that you're talking about infrastructure as code.  The more specific you can be, the better, as even with agreed-upon definitions most companies focus more on certain parts of a philosophy.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-07T19:07:09.590Z
Answers: 2017-04-07T19:07:09.590Z
Answers: Xiong Chiamiov
Answers: <p>The definition I always use in this situation is the following: </p>
  
  <p>“A software creation culture that emphasizes communication and collaboration between software development and operations teams while automating the software delivery process and infrastructure changes. The goal of DevOps is to make software building, testing and deployment process as frequent, fast and as possible.”</p>
  
  <p>However, along with the definition, it is also important that they understand WHY we need <a href="http://squadex.com" rel="nofollow noreferrer">DevOps.</a> Be sure to tell them that DevOps mitigates software defects faster, allows for better resource management, less human error, better version control, stable operating environment etc. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-27T09:09:04.670Z
Answers: 2017-12-27T09:09:04.670Z
Answers: DevOps Jedi
Answers: <p>I have been practising and advising on DevOps as a consultant with different clients for almost five years now, before my current position, I held roles in software development, web operations and systems administration.  In my <strong>personal</strong> experience DevOps comes in many flavours.</p>
  
  <h1>Organization Patterns</h1>
  
  <p>DevOps Antipatterns:</p>
  
  <ul>
  <li><p><strong>NoOps</strong> and <strong>NoDevs</strong> - not strictly DevOps in the most strict sense, however, these teams both build and operate software without a dividing line between Development and Operations.  The challenges with these teams come down to maturity, Development teams may be expert Software Developers but novice Operators and visa versa.</p></li>
  <li><p><strong>The DevOps Bridge</strong> - this is where one or more teams are given responsibility for taking work from the development teams and "<a href="https://en.wikipedia.org/wiki/Productionisation" rel="noreferrer">Productionizing</a>" it to make it operable.  The challenge comes down to now there are two hand-offs, i.e. Development → DevOps and DevOps → Operations.</p></li>
  <li><p><strong>The DevOps Team</strong> - this can, arguably, work if the team has responsibility for building tools that support the DevOps enabled Operating Model, however, it should probably be called a "Tools Team" or "Platform Team".</p></li>
  </ul>
  
  <p>DevOps Patterns:</p>
  
  <ul>
  <li><p><strong>Embedded DevOps</strong> - more commonly referred to as Platform Engineering, whereby there is someone within the team who is <em>accountable but not responsible</em> for delivering automation, tools and infrastructure for the provisioning and deployment of the solution, sometimes also including operating the software - in my mind, it's the latter that is actually representative of DevOps.</p></li>
  <li><p><strong>Institutionalized DevOps</strong> - where a project team jointly is responsible for both development and operation of a software package building shared ownership and positive feedback loops.</p></li>
  </ul>
  
  <h1>Practices</h1>
  
  <p>The actual practice of DevOps builds on top of several other practices, namely:</p>
  
  <ul>
  <li><a href="https://en.wikipedia.org/wiki/Agile_software_development" rel="noreferrer">Agile Delivery</a></li>
  <li><a href="https://www.thoughtworks.com/continuous-integration" rel="noreferrer">Continuous Integration</a></li>
  <li><a href="https://devops.stackexchange.com/questions/tagged/continuous-delivery">Continuous Delivery</a></li>
  <li><a href="https://devops.stackexchange.com/questions/tagged/continuous-deployment">Continuous Deployment</a></li>
  </ul>
  
  <p>Each of the above practices builds upon the other, it's possible to <strong>not</strong> follow a practice, however, it means an important feedback cycle is missing which may be indicative of a "missed opportunity".  The key differentiator between following any of the other practices and DevOps is the <em>operation of software in production</em>.</p>
  
  <p><a href="https://i.sstatic.net/LCGnq.png" rel="noreferrer"><img src="https://i.sstatic.net/LCGnq.png" alt="DevOps Practices"></a></p>
  
  <h1>The Three Ways</h1>
  
  <p>In <a href="https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO" rel="noreferrer">The Phoenix Project</a> Gene Kim and his co-authors describes the <a href="http://itrevolution.com/the-three-ways-principles-underpinning-devops/" rel="noreferrer">three ways of DevOps</a>:</p>
  
  <h2>Systems Thinking</h2>
  
  <p><a href="https://i.sstatic.net/6LVx9.png" rel="noreferrer"><img src="https://i.sstatic.net/6LVx9.png" alt="Systems Thinking"></a></p>
  
  <blockquote>
    <p>The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).</p>
  </blockquote>
  
  <p>In my experience starting to get Developers to consider Operational Concerns and Non-functional requirements achieves this goal.  This is very much part of the <em>culture</em> aspects of DevOps.</p>
  
  <h2>Amplification of Feedback Loops</h2>
  
  <p><a href="https://i.sstatic.net/RHMCx.png" rel="noreferrer"><img src="https://i.sstatic.net/RHMCx.png" alt="Amplification of Feedback Loops"></a></p>
  
  <blockquote>
    <p>The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.</p>
  </blockquote>
  
  <p>I generally achieve this through Continuous Integration/Delivery/Deployment and shared monitoring and alerting, thus it very much fits in with the <strong>tools</strong> component of DevOps.</p>
  
  <h2>Culture of Continuous Experimentation and Learning</h2>
  
  <p><a href="https://i.sstatic.net/41mm9.png" rel="noreferrer"><img src="https://i.sstatic.net/41mm9.png" alt="Culture of Continuous Experimentation and Learning"></a></p>
  
  <blockquote>
    <p>The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.</p>
  </blockquote>
  
  <p>This fits very much in the <em>culture</em> space, although it depends heavily on tools and process to enable the culture to grow.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-11T13:55:08.897Z
Answers: Excellent answer ! though I did stumble on that graph comparisons of different practices... especially regarding agile.  I think it is much too broad a term to belong there.  Testing is excluded though some agile methodologies put testing at the core of their practices.  Once could argue that DevOps is (or can be depending on how it is implemented) very much agile.  The agile manifesto depicts more of a philosophy than a well bound practice rules.  Nitpicking more than complaining mind you, it is a really nice answer !
Answers: Newtopian
Answers: CC BY-SA 3.0
Answers: 2017-04-11T14:01:06.320Z
Answers: I can't take full credit for that diagram, it's been drawn by many a consultant before me on many whiteboards around the world.  I guess it is describing the practice of agile where teams focused on building potentially usable products in short iterations, CI followed as a practice that automated some of that work, C. Delivery automated as far as preparing a build for deployment, C. Deployment actually deployed that build and DevOps operates the software in production.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-04-08T21:09:23.510Z
Answers: 2017-04-11T14:03:15.613Z
Answers: 2017-04-13T13:01:29.297Z
Answers: Richard Slater
Answers: <p>Devops is the development practice of writing applications whose <strong>business domain</strong> is operations. Where most application development focuses on building applications which do finance or health care or logistics or cat videos, devops focuses on applications which enable builds, deployments, monitoring, and metrics gathering.</p>
  
  <p>The overriding goal should always be to enable <em>decision-makers</em> to become <em>decision-takers</em>. Imagine your bank's mobile application. When you request a transfer, it happens when you hit the button. You <em>made</em> a decision, then <strong>took</strong> the decision. Same thing with your operations. When the appropriate person decides some work is ready to deploy to production, they should be able to hit a button and the "Right Things Happen". Similarly, they should have all the necessary information they need to make correct business decisions.</p>
  
  <p>It's not about giving business people shell access to servers - that's confusing purpose with implementation. It's about providing the correct knobs and levers with the right information <strong>and the right guard-rails</strong> to the right people so that decision-makers are decision-takers.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-05T18:06:52.730Z
Answers: `whose business domain is operations` : Possible to expand on this, or give some examples?
Answers: Dawny33
Answers: CC BY-SA 3.0
Answers: 2017-04-06T18:24:24.130Z
Answers: I disagree, devops is an organisation model to support software developments not a development practice in itself, you can do extreme programming in a devops model (mixin dev, ops, clients and testers for example) (The remaining of the answer have good points btw)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-04-06T20:06:31.173Z
Answers: The basic definition of "Devops is the development practice of writing applications whose business domain is operations" is not one I've ever seen anyone else subscribe to. Writing applications, regardless of domain or purpose, is development, not DevOps.
Answers: Adrian
Answers: CC BY-SA 3.0
Answers: 2017-04-05T17:49:28.473Z
Answers: 2017-04-05T18:18:30.417Z
Answers: 2017-04-05T18:18:30.417Z
Answers: Rob Kinyon
Answers: <p>By the following scientific research paper to explore exactly this question,"What is DevOps", the proposed derived definition of DevOps is:</p>
  
  <blockquote>
    <p>DevOps is a development methodology aimed at bridging the gap between Development (Dev) and Operations (Ops), emphasizing communication and collaboration, continuous integration, quality assurance and delivery with automated deployment utilizing a set of development practices.</p>
  </blockquote>
  
  <p>[Jabbari et al.] "What is DevOps?: A Systematic Mapping Study on Definitions and Practices" (2016) </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-23T09:14:16.360Z
Answers: 2017-06-23T10:55:06.617Z
Answers: 2017-06-23T10:55:06.617Z
Answers: Ta Mu
Answers: <h3>DevOps in a nutshell</h3>
  
  <p>From <a href="https://en.wikipedia.org/wiki/DevOps" rel="noreferrer">Wikipedia</a>:</p>
  
  <blockquote>
    <p>DevOps (a <a href="https://en.wikipedia.org/wiki/Clipped_compound" rel="noreferrer">clipped compound</a> of "<a href="https://en.wikipedia.org/wiki/Software_development" rel="noreferrer">software <strong>DEV</strong>elopment</a>" and "<a href="https://en.wikipedia.org/wiki/Information_technology_operations" rel="noreferrer">information technology <strong>OP</strong>eration<strong>S</strong></a>") is a term used to refer to a set of practices that emphasize the collaboration and communication of both <a href="https://en.wikipedia.org/wiki/Software_developer" rel="noreferrer">software developers</a> and <a href="https://en.wikipedia.org/wiki/Information_technology" rel="noreferrer">information technology</a> (IT) professionals while automating the process of <a href="https://en.wikipedia.org/wiki/Software_delivery" rel="noreferrer">software delivery</a> and infrastructure changes.</p>
    
    <p>It aims at establishing a culture and environment where <a href="https://en.wikipedia.org/wiki/Software_build" rel="noreferrer">building</a>, <a href="https://en.wikipedia.org/wiki/Software_testing" rel="noreferrer">testing</a>, and <a href="https://en.wikipedia.org/wiki/Software_release_life_cycle" rel="noreferrer">releasing software</a> can happen rapidly, frequently, and more reliably.</p>
  </blockquote>
  
  <p>From <a href="https://en.wikipedia.org/wiki/DevOps#Overview" rel="noreferrer">Overview</a>:</p>
  
  <blockquote>
    <p><a href="https://i.sstatic.net/odnjG.png" rel="noreferrer"><img src="https://i.sstatic.net/odnjG.png" alt="enter image description here"></a></p>
    
    <p>Venn diagram showing DevOps as the intersection of <a href="https://en.wikipedia.org/wiki/Software_development" rel="noreferrer">development</a>
    (software engineering), <a href="https://en.wikipedia.org/wiki/Information_technology_operations" rel="noreferrer">operations</a> and <a href="https://en.wikipedia.org/wiki/Quality_assurance" rel="noreferrer">quality assurance</a>
    (QA)</p>
  </blockquote>
  
  <p>While there is no single "tool" for DevOps, but rather a set of tools, also known as a <a href="https://en.wikipedia.org/wiki/DevOps_toolchain" rel="noreferrer">DevOps toolchain</a>:</p>
  
  <blockquote>
    <p><a href="https://i.sstatic.net/kKb3O.png" rel="noreferrer"><img src="https://i.sstatic.net/kKb3O.png" alt="enter image description here"></a></p>
    
    <p>Illustration showing stages in a DevOps toolchain</p>
  </blockquote>
  
  <h3>Illustrations of DevOps</h3>
  
  <p>Below are a few quotes from some of the questions on <a href="https://devops.stackexchange.com/">DevOps.SE</a>, which all seem to somehow fit / confirm part of the DevOps description above:</p>
  
  <ul>
  <li><p>From '<a href="https://devops.stackexchange.com/q/86/40">What is the difference between SRE and DevOps?</a>':</p>
  
  <blockquote>
    <p>... DevOps is about maintaining code ...</p>
  </blockquote></li>
  <li><p>From (an <a href="https://devops.stackexchange.com/a/474/40">answer</a> to) '<a href="https://devops.stackexchange.com/q/468/40">How do I hire a good DevOps, fitting my company?</a>':</p>
  
  <blockquote>
    <p>... It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies ...</p>
  </blockquote></li>
  <li><p>From '<a href="https://devops.stackexchange.com/q/333/40">Does my organization need adopt Agile Soft. Dev. before adopting DevOps?</a>':</p>
  
  <blockquote>
    <p>... there are still organisations which are not practicing Agile in their software development, who might be interested in adopting DevOps ...</p>
  </blockquote></li>
  </ul>
  
  <h3>DevOps is NOT a role</h3>
  
  <p>Below are a few quotes from some of the questions on <a href="https://devops.stackexchange.com/">DevOps.SE</a>, which all seem to illustrate that DevOps is <strong>NOT</strong> a role:</p>
  
  <ul>
  <li><p>From (an <a href="https://devops.stackexchange.com/a/160/40">answer</a> to) '<a href="https://devops.stackexchange.com/q/157/40">What is the difference between Sysadmin and DevOps Engineer?</a>':</p>
  
  <blockquote>
    <p>... DevOps is not a role (when used as such it's more a buzzword than a real role).</p>
  </blockquote></li>
  <li><p>From (an <a href="https://devops.stackexchange.com/a/474/40">answer</a> to) '<a href="https://devops.stackexchange.com/q/468/40">How do I hire a good DevOps, fitting my company?</a>':</p>
  
  <blockquote>
    <p>... It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies ...</p>
  </blockquote></li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-06T17:44:02.263Z
Answers: 2017-04-06T18:08:38.670Z
Answers: 2017-04-13T13:01:29.297Z
Answers: Pierre.Vriens
Body: <p>I've done / created lots of SCM related presentations, and now I'm trying to "upgrade" to a DevOps successor of it.</p>
  
  <p>What I always try to do in my presentations, is to come up with an introduction slide which somehow includes the message I want to deliver (and which I then elaborate on in the rest of my presentation). When doing so, I try to answer my own question like "What would me 1 to 3 phrases be that I'd want to use if I got like 10 to 20 secs (only!) to explain it to somebody new to it?*".</p>
  
  <p>I thought I knew what <strong><em>DevOps</em></strong> actually means, and what it is about. But I've seen some bizarre usages/contexts of <em>DevOps</em> (even on <a href="https://devops.stackexchange.com/">DevOps.SE</a> ...). It makes me wonder if maybe what I think DevOps is, is completely wrong.</p>
  
  <p>So what is generally agreed to be the definition of DevOps?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-06T19:50:33.293Z
Comments: History of Comments have been [moved to chat](http://chat.stackexchange.com/rooms/56681/conversation/improvement-exchange) for record on how a question can be improved.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-04-07T17:45:13.523Z
Comments: The main thing I've learned from talking to many people is that there is no agreed upon definition.
Comments: Xiong Chiamiov
Comments: CC BY-SA 3.0
Comments: 2017-04-07T17:47:50.717Z
Comments: merci @XiongChiamiov ... that sounds like you may be aware of one of more other definitions ... Why not try to post them as an extra answer?
Comments: Pierre.Vriens
Tags: <terminology><culture>
Title: What could be a valid definition of DevOps to introduce it to a novice?
UserDisplayName: Pierre.Vriens
ThreadText: # What could be a valid definition of DevOps to introduce it to a novice?
  
  (Asked by: username_0 on 2017-04-05)
  
  I've done / created lots of SCM related presentations, and now I'm trying to "upgrade" to a username_3 successor of it.
  
  What I always try to do in my presentations, is to come up with an introduction slide which somehow includes the message I want to deliver (and which I then elaborate on in the rest of my presentation). When doing so, I try to answer my own question like "What would me 1 to 3 phrases be that I'd want to use if I got like 10 to 20 secs (only!) to explain it to somebody new to it?\*".
  
  I thought I knew what ***username_3*** actually means, and what it is about. But I've seen some bizarre usages/contexts of *username_3* (even on [username_3.SE](https://username_3.stackexchange.com/) ...). It makes me wonder if maybe what I think username_3 is, is completely wrong.
  
  So what is generally agreed to be the definition of username_3?
  
  **Tags:** terminology, culture
  
  > **Comments:**
  > **username_1**: History of Comments have been [moved to chat](http://chat.stackexchange.com/rooms/56681/conversation/improvement-exchange) for record on how a question can be improved.  
  > **username_2**: The main thing I've learned from talking to many people is that there is no agreed upon definition.  
  > **username_0**: merci @username_2 ... that sounds like you may be aware of one of more other definitions ... Why not try to post them as an extra answer?  
  
  ---
  
  ## 6 answers
  
  ### Answer by username_0 on 2017-04-06. Score: 13 | Accepted answer
  
  ### username_3 in a nutshell
  
  From [Wikipedia](https://en.wikipedia.org/wiki/username_3):
  
  > username_3 (a [clipped compound](https://en.wikipedia.org/wiki/Clipped_compound) of "[software **DEV**elopment](https://en.wikipedia.org/wiki/Software_development)" and "[information technology **OP**eration**S**](https://en.wikipedia.org/wiki/Information_technology_operations)") is a term used to refer to a set of practices that emphasize the collaboration and communication of both [software developers](https://en.wikipedia.org/wiki/Software_developer) and [information technology](https://en.wikipedia.org/wiki/Information_technology) (IT) professionals while automating the process of [software delivery](https://en.wikipedia.org/wiki/Software_delivery) and infrastructure changes.
  >
  > It aims at establishing a culture and environment where [building](https://en.wikipedia.org/wiki/Software_build), [testing](https://en.wikipedia.org/wiki/Software_testing), and [releasing software](https://en.wikipedia.org/wiki/Software_release_life_cycle) can happen rapidly, frequently, and more reliably.
  
  From [Overview](https://en.wikipedia.org/wiki/username_3#Overview):
  
  > [![enter image description here](https://i.sstatic.net/odnjG.png)](https://i.sstatic.net/odnjG.png)
  >
  > Venn diagram showing username_3 as the intersection of [development](https://en.wikipedia.org/wiki/Software_development)
  > (software engineering), [operations](https://en.wikipedia.org/wiki/Information_technology_operations) and [quality assurance](https://en.wikipedia.org/wiki/Quality_assurance)
  > (QA)
  
  While there is no single "tool" for username_3, but rather a set of tools, also known as a [username_3 toolchain](https://en.wikipedia.org/wiki/DevOps_toolchain):
  
  > [![enter image description here](https://i.sstatic.net/kKb3O.png)](https://i.sstatic.net/kKb3O.png)
  >
  > Illustration showing stages in a username_3 toolchain
  
  ### Illustrations of username_3
  
  Below are a few quotes from some of the questions on [username_3.SE](https://username_3.stackexchange.com/), which all seem to somehow fit / confirm part of the username_3 description above:
  
  * From '[What is the difference between SRE and username_3?](https://username_3.stackexchange.com/q/86/40)':
  
    > ... username_3 is about maintaining code ...
  * From (an [answer](https://username_3.stackexchange.com/a/474/40) to) '[How do I hire a good username_3, fitting my company?](https://username_3.stackexchange.com/q/468/40)':
  
    > ... It is a common misbelief that “username_3” is a role in a company. The word merely denotes an organisational shift in software companies ...
  * From '[Does my organization need adopt Agile Soft. Dev. before adopting username_3?](https://username_3.stackexchange.com/q/333/40)':
  
    > ... there are still organisations which are not practicing Agile in their software development, who might be interested in adopting username_3 ...
  
  ### username_3 is NOT a role
  
  Below are a few quotes from some of the questions on [username_3.SE](https://username_3.stackexchange.com/), which all seem to illustrate that username_3 is **NOT** a role:
  
  * From (an [answer](https://username_3.stackexchange.com/a/160/40) to) '[What is the difference between Sysadmin and username_3 Engineer?](https://username_3.stackexchange.com/q/157/40)':
  
    > ... username_3 is not a role (when used as such it's more a buzzword than a real role).
  * From (an [answer](https://username_3.stackexchange.com/a/474/40) to) '[How do I hire a good username_3, fitting my company?](https://username_3.stackexchange.com/q/468/40)':
  
    > ... It is a common misbelief that “username_3” is a role in a company. The word merely denotes an organisational shift in software companies ...
  
  
  ---
  
  ### Answer by username_4 on 2017-04-08. Score: 13
  
  I have been practising and advising on username_3 as a consultant with different clients for almost five years now, before my current position, I held roles in software development, web operations and systems administration. In my **personal** experience username_3 comes in many flavours.
  
  # Organization Patterns
  
  username_3 Antipatterns:
  
  * **NoOps** and **NoDevs** - not strictly username_3 in the most strict sense, however, these teams both build and operate software without a dividing line between Development and Operations. The challenges with these teams come down to maturity, Development teams may be expert Software Developers but novice Operators and visa versa.
  * **The username_3 Bridge** - this is where one or more teams are given responsibility for taking work from the development teams and "[Productionizing](https://en.wikipedia.org/wiki/Productionisation)" it to make it operable. The challenge comes down to now there are two hand-offs, i.e. Development → username_3 and username_3 → Operations.
  * **The username_3 Team** - this can, arguably, work if the team has responsibility for building tools that support the username_3 enabled Operating Model, however, it should probably be called a "Tools Team" or "Platform Team".
  
  username_3 Patterns:
  
  * **Embedded username_3** - more commonly referred to as Platform Engineering, whereby there is someone within the team who is *accountable but not responsible* for delivering automation, tools and infrastructure for the provisioning and deployment of the solution, sometimes also including operating the software - in my mind, it's the latter that is actually representative of username_3.
  * **Institutionalized username_3** - where a project team jointly is responsible for both development and operation of a software package building shared ownership and positive feedback loops.
  
  # Practices
  
  The actual practice of username_3 builds on top of several other practices, namely:
  
  * [Agile Delivery](https://en.wikipedia.org/wiki/Agile_software_development)
  * [Continuous Integration](https://www.thoughtworks.com/continuous-integration)
  * [Continuous Delivery](https://username_3.stackexchange.com/questions/tagged/continuous-delivery)
  * [Continuous Deployment](https://username_3.stackexchange.com/questions/tagged/continuous-deployment)
  
  Each of the above practices builds upon the other, it's possible to **not** follow a practice, however, it means an important feedback cycle is missing which may be indicative of a "missed opportunity". The key differentiator between following any of the other practices and username_3 is the *operation of software in production*.
  
  [![username_3 Practices](https://i.sstatic.net/LCGnq.png)](https://i.sstatic.net/LCGnq.png)
  
  # The Three Ways
  
  In [The Phoenix Project](https://www.amazon.co.uk/Phoenix-Project-username_3-Helping-Business-ebook/dp/B00AZRBLHO) Gene Kim and his co-authors describes the [three ways of username_3](http://itrevolution.com/the-three-ways-principles-underpinning-username_3/):
  
  ## Systems Thinking
  
  [![Systems Thinking](https://i.sstatic.net/6LVx9.png)](https://i.sstatic.net/6LVx9.png)
  
  > The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
  
  In my experience starting to get Developers to consider Operational Concerns and Non-functional requirements achieves this goal. This is very much part of the *culture* aspects of username_3.
  
  ## Amplification of Feedback Loops
  
  [![Amplification of Feedback Loops](https://i.sstatic.net/RHMCx.png)](https://i.sstatic.net/RHMCx.png)
  
  > The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
  
  I generally achieve this through Continuous Integration/Delivery/Deployment and shared monitoring and alerting, thus it very much fits in with the **tools** component of username_3.
  
  ## Culture of Continuous Experimentation and Learning
  
  [![Culture of Continuous Experimentation and Learning](https://i.sstatic.net/41mm9.png)](https://i.sstatic.net/41mm9.png)
  
  > The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.
  
  This fits very much in the *culture* space, although it depends heavily on tools and process to enable the culture to grow.
  
  > **Comments:**
  > **username_5**: Excellent answer ! though I did stumble on that graph comparisons of different practices... especially regarding agile.  I think it is much too broad a term to belong there.  Testing is excluded though some agile methodologies put testing at the core of their practices.  Once could argue that username_3 is (or can be depending on how it is implemented) very much agile.  The agile manifesto depicts more of a philosophy than a well bound practice rules.  Nitpicking more than complaining mind you, it is a really nice answer !  
  > **username_4**: I can't take full credit for that diagram, it's been drawn by many a consultant before me on many whiteboards around the world.  I guess it is describing the practice of agile where teams focused on building potentially usable products in short iterations, CI followed as a practice that automated some of that work, C. Delivery automated as far as preparing a build for deployment, C. Deployment actually deployed that build and username_3 operates the software in production.  
  
  ---
  
  ### Answer by username_2 on 2017-04-07. Score: 6
  
  I've heard many, many different definitions of username_3. They include:
  
  * Developers handling operations tasks
  * One person doing twice as much work (in the same amount of time)
  * Developers and operations teams working with each other
  * Operations work for developer tooling (in the vein of "Web Ops")
  * A job title for someone who creates and maintains developer tooling
  * The use of automation in operations
  * The use of public clouds in operations
  * A job that combines aspects of operations, development, and quality assurance
  * A job that entails helping the development and operations teams work together
  * A philosophy of breaking down barriers between teams
  * Treating infrastructure as code
  * What you get when former software engineers move into operations
  * A completely meaningless buzzword
  
  There is no public consensus on what username_3 actually *is*. A few years back we had similar problems with "Agile", and that [has a written definition](http://agilemanifesto.org/).
  
  When introducing your concepts to a newcomer, I'd focus on introducing the concepts, rather than applying a label, or else they'll end up hearing conflicting definitions and being confused. For instance, if you're trying to talk about [infrastructure as code](https://en.wikipedia.org/wiki/Infrastructure_as_Code), tell them that you're talking about infrastructure as code. The more specific you can be, the better, as even with agreed-upon definitions most companies focus more on certain parts of a philosophy.
  
  
  ---
  
  ### Answer by username_3 on 2017-12-27. Score: 2
  
  The definition I always use in this situation is the following:
  
  “A software creation culture that emphasizes communication and collaboration between software development and operations teams while automating the software delivery process and infrastructure changes. The goal of username_3 is to make software building, testing and deployment process as frequent, fast and as possible.”
  
  However, along with the definition, it is also important that they understand WHY we need [username_3.](http://squadex.com) Be sure to tell them that username_3 mitigates software defects faster, allows for better resource management, less human error, better version control, stable operating environment etc.
  
  
  ---
  
  ### Answer by username_9 on 2017-06-23. Score: 1
  
  By the following scientific research paper to explore exactly this question,"What is username_3", the proposed derived definition of username_3 is:
  
  > username_3 is a development methodology aimed at bridging the gap between Development (Dev) and Operations (Ops), emphasizing communication and collaboration, continuous integration, quality assurance and delivery with automated deployment utilizing a set of development practices.
  
  [Jabbari et al.] "What is username_3?: A Systematic Mapping Study on Definitions and Practices" (2016)
  
  
  ---
  
  ### Answer by username_6 on 2017-04-05. Score: -2
  
  username_3 is the development practice of writing applications whose **business domain** is operations. Where most application development focuses on building applications which do finance or health care or logistics or cat videos, username_3 focuses on applications which enable builds, deployments, monitoring, and metrics gathering.
  
  The overriding goal should always be to enable *decision-makers* to become *decision-takers*. Imagine your bank's mobile application. When you request a transfer, it happens when you hit the button. You *made* a decision, then **took** the decision. Same thing with your operations. When the appropriate person decides some work is ready to deploy to production, they should be able to hit a button and the "Right Things Happen". Similarly, they should have all the necessary information they need to make correct business decisions.
  
  It's not about giving business people shell access to servers - that's confusing purpose with implementation. It's about providing the correct knobs and levers with the right information **and the right guard-rails** to the right people so that decision-makers are decision-takers.
  
  > **Comments:**
  > **username_7**: `whose business domain is operations` : Possible to expand on this, or give some examples?  
  > **username_1**: I disagree, username_3 is an organisation model to support software developments not a development practice in itself, you can do extreme programming in a username_3 model (mixin dev, ops, clients and testers for example) (The remaining of the answer have good points btw)  
  > **username_8**: The basic definition of "username_3 is the development practice of writing applications whose business domain is operations" is not one I've ever seen anyone else subscribe to. Writing applications, regardless of domain or purpose, is development, not username_3.  
  
  ---
  
  