From BC$ MobileTV Wiki
Revision as of 12:19, 29 June 2022 by Bcmoney (Talk | contribs) (Digital Transformation)

Jump to: navigation, search

The union of and full cooperation between Development (Dev) teams/departments and Operations (Ops) teams/departments within (and potentially even across partner) organizations, towards realization of a common set of corporate and/or societal goals, over the entire service lifecycle of systems, from design through the development process to production support.

DevOps evolution.jpg


The DORA report has identified the following 4 metrics as the most important for measuring the health and/or success of any DevOps initiative:

  1. Lead Time - a key metric on which to base our improvement efforts, striving to reduce the time between ideation and delivery into customers' hands
  2. Deployment Rate - these should be constant pace and typically striving for shorter time deltas between each release, meaning more releases is viewed as an indicator of good team/project/product health
  3. Change Failure Rate - depending on organization, in addition to the typically measured rollbacks this could include any unplanned or partial outages in its measurement, but is distinct from "Defect Escape Rate" and is not meant to be a catch-all for any and all imperfections making it to PROD... the idea is to measure any unexpected Business Value lost while introducing new Business Value)
  4. MTTR - how long it takes to recover from any failures or major problems in any given environment (but with a strong if not obvious emphasis on Production), and how gracefully we do so, is an indicator of our team/project/product's capacity to deliver more value faster with high confidence in our abilities to work through any unforeseen issues; we aim to minimize the amount of time between an issue introduced an a corresponding hotfix or full release to address it (and as per "Change Failure Rate" metric which comes first, addressing any such failures or problems should not introduce other issues)

For more metrics, see: Optimization#Metrics

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]


Digital Transformation

Digital Transformation (commonly abbreviated as either DT or DX; sometimes also commonly referred to as "Digital Experience") is the use of new, fast and frequently changing digital technologies to solve problems. In the enterprise setting that's business problems (such as how to drive one or more key metrics like revenue, increase market share, customer loyalty, etc). Regardless of metric(s) chosen to measure a Digital Transformation, its successful adoption and continued implementation typically hinges on how well the initiatives chosen tie to the bottom-line and increase the health and modernization of the business.

Although Digital Transformation may take many forms, a key theme is switching a majority of the applications and tools used from expensive highly customized to Commercial Off-The-Shelf (COTS) and/or Software-as-a-Service (SaaS) where practical. This is not merely "for the sake of being Cloud/SaaS-focused", but because often (but certainly not always) these solutions can be more cost-efficient than a sprawling array of various in-house, or heavily customized self-hosted software and tools. Customized in-house solutions (where they do persist) should be focused on differential capabilities, business logic, and unique product/service offerings not available on other platforms or combinations of platforms.

Tools and custom internally used "business-supporting" applications aside, the final and most important piece of the Digital Transformation puzzle is to convert a certain amount of the key Lines of Business (LoB) over to higher Return On Investment (ROI) cost-per-sale and cost-per-acquisition digital technologies rather than relying entirely on the limitations of any current physical markets (i.e. B2C Retail, or, C2C goods/materials exchange). This could mean creation of an E-Commerce/E-Business enhanced Website, WebApp, MobileApp or some other mechanism for the digital exchange of goods and/or services to supplement traditional physical channels (especially in channels where there was no prior online, mobile or virtual presence), introducing such, as an increasingly viable alternative for exchange of the goods/service.


Digital Transformation is frequently touted as a critical factor of what's being dubbed the "4th Industrial Revolution", with many analysts predicting that only businesses who succeed in their Digital Transformation efforts will be around in that vision of the future.

Some executives and consultants like to list the following criteria for gauging a company's "Digital Transformation maturity":

  1. Market agility
  2. Delivery velocity
  3. Frictionless personalized experiences
  4. Experts in analytics, integration & security
  5. Invest in and realize benefits from robotic process automation

Although, without specific OKRs/KPIs/KPMs these are difficult intangibles to measure.

[13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49]

Business Value Baked-In

Also known as "DevBizOps". This implies that each change or feature requiring any substantial development effort should have a specific Business Value estimation tied to it, not just a Story Points or other form of effort estimate as per typical Agile development. We then measure the change and how it has impacted your Key Performance Indicators (KPIs) towards reaching your Objectives & Key Results (OKRs).


For more specifics on this, see: Business Value


Quality Baked-In

Also known as "DevTestOps".


For more specifics on how to achieve this, see: Continuous Testing [51] [52]

Security Baked-In

Also known as "DevSecOps".


For more specifics on how to achieve this, see: Security [53] [54] [55] [56] [57]

Risk Management

NIST RiskManagement-framework.jpg

[61] [62] [63] [64] [65] [66] [67] [68]

Change Management

ITIL DevOps ChangeManagement.png

[69] [70] [71]

Release Management

ReleaseManagement vs EnvironmentCoordination.jpg

[72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86]

Cultural Patterns

DevOps culture can be summarized with the following diagram:

DevOps culture.jpg

[87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97]


Risk evaluation approach/meeting where any higher risk or even potentially complex Backlog items such as high-level feature requests or User Stories (or if still receiving them then converting to Stories, Requirements Documents) are identified, voted on and/or ranked and planned out in terms of which may present blocking dependencies or which may cause the team the most trouble within the desired timelines or current technology architecture/stack.

Blameless Post-Mortem


[99] [100] [101] [102] [103] [104] [105] [106] [107] [108]


DevOps adoption and rollout strategy.

DevOps CALMS.png
  1. Culture
  2. Automation
  3. Lean
  4. Measurement
  5. Sharing

[114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137]



The INVEST "mnemonic" is a guideline for clear and actionable User Stories and all Product Backlog Items (PBI) in general, which ensure that once picked up there will be minimal "hand-offs" or "wait time".

  • I=Independent
  • N=Negotiable
  • V=Valuable
  • E=Estimable
  • S=Small
  • T=Testable

[138] [139] [140] [141] [142] [143] [144] [145] [146][147] [148] [149] [150] [151] [152]

The 3 Ways

Three core principles that promote DevOps. These should be considered the steps to take when analyzing a company, department, team or product level situation for best approaches to take to bring about the types of changes required to reach the ideals of DevOps. While not specific to DevOps "The 3 ways" can be applied for the sole goal of realizing operational efficiencies and/or delivery effectiveness, the need to adopt some or all DevOps concepts in the process will vary to the degree that a given Line-Of-Business (LoB) depends on Software and technology in general. This dependence has grown quite large in the modern world, but will certainly vary from industry to industry, company to company, team to team, product to product, service to service.


  1. Flow
  2. Feedback
  3. Continual Experimentation & Learning

[153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169] [170] [171] [172] [173] [174] [175] [176] [177] [178] [179] [180] [181] [182] [183] [184] [185] [186] [187] [188] [189] [190] [191] [192] [193] [194] [195] [196] [197] [198] [199] [200] [201] [202]

The 5 Ideals

In "The Phoenix Project", author Gene Kim introduced the concept of the "Three Ways", and, the Four Types of IT Work. In his follow-up book "The Unicorn Project", readers are taken through The Five Ideals, or concepts that help drive significant and positive change within the Business and IT.

These include:

  1. Locality and simplicity -- don't underestimate the significance of smaller-scale changes to a single software or infrastructure component.
  2. Focus, flow and joy -- provide quick feedback on code so developers can stay focused and enjoy their day-to-day work.
  3. Improvement of daily work -- implement systemic fixes to streamline daily tasks.
  4. Psychological safety -- ensure all staff feels comfortable and empowered to share their opinions openly.
  5. Customer focus -- instill a culture where leaders across all functional silos focus on what the organization as a whole, and its customers, need long-term.

[203] [204] [205] [206] [207] [208] [209] [210] [211] [212] [213] [214] [215] [216] [217] [218] [219] [220] [221] [222] [223] [224] [225] [226] [227] [228] [229] [230] [231]

FLOW framework

The FLOW framework:


It focuses on prioritizing the 4 separate types of backlog item (which can each come from a number of different sources from customer feedback/demand, to regulator/legislative obligation, to business unit request, to personally direct-requested, to team internally-driven ideation or gap identification):

Backlog 4-types.jpg

They can be described as follows:

Item Delivers Primary Sources Goal Artifacts
Feature New/more business value Pushed by Customers (or Business ideation) Additional service offerings & revenue streams Epic, User Story, Functional Requirement
Defect Quality Pushed by Business (on behalf of Customers) Improved customer experience & higher engagement Bug (PROD-related), Defect (project/env-related), ITIL incident
Risk Attack vector eliminated, Governance compliance met Security and/or Risk & Compliance dept, External Auditors Data privacy & service reliability Vulnerability patch, Regulatory criteria, Non-Functional Requirement
Debt Removal of impediments to future deliveries Internal Architects and/or Front-line workers (those delivering) Operational efficiency & reduced Total Cost of Ownership (TCO) Refactored code, Automated infrastructure, Process improvement

[232] [233] [234] [235]



For more, see: IaaS

[236] [237] [238]


Site Reliability Engineering (SRE) is a particular practice or implementation of DevOps that emphasizes:.

  1. Small, testable, measurable, incremental, continuous improvements
  2. Automation for efficiency's sake (not automation's sake)
  3. Practice observability through monitoring vital signs of the entire system, including the four "golden signals": latency, traffic, errors, and saturation
  4. Alerting & Reporting "chain of command" & "responsibility schedules"


[242] [243] [244] [245] [246] [247] [248] [249] [250] [251] [252] [253] [254] [255] [256] [257] [258] [259] [260] [261] [262]

Value Stream Mapping

ValueStreamMapping SOFTWARE.png

[263] [264] [265] [266] [267] [268] [269] [270]

Cultural Anti-Patterns

JDFI Deployments

[271] [272] [273] [274]

Conway's Law

Conway's Law is a hypothesis that:

organizations which design systems... are constrained to produce designs which are copies of their communication structures

Tragedy of the Commons

The "Tragedy of the Commons" states that if it's everyone's responsibility to maintain the resources, then no one is responsible (or accountable).


[275] [276] [277] [278] [279] [280]

Diffusion of Responsibility

Diffusion of Responsibility (also known as "pluralistic ignorance").


Model of intervention and helping to prevent Diffusion of Responsibility: Diffusion-of-Responsibility-intervention-model.jpg

[281] [282] [283] [284]


GroupThink is the effect that a large group can have on decision-making, problem-solving or new idea generation, whereby often the "status quo" or conformist opinions dominate the outcomes due to a fear of ostracism for standing out or demonstrating differing or unfavourable viewpoints.


Some ways to counter GroupThink are:

  • Prevent executives, senior managers and/or bosses from steering the entire conversation or making the decision themselves then managing downwards
  • Invite those external to the problem (other teams), or, third parties (outside the company)
  • Identify outliers or opposing ideas (reverse & inverse)
  • Seek out disagreements
  • Divide by expertise
  • Focus on the right things, same problems
  • Periodically switch roles
  • Come together and discuss
  • Think (individually) and allow time for reflection
  • Decide independently, from a place of informed understanding


[285] [286] [287] [288] [289] [290] [291] [292] [293] [294] [295] [296] [297]

Learned Helplessness

Dev & Ops (silos)

Treating Dev & Ops as two totally separate Teams and/or Departments, with completely separate lines of reporting, performance monitoring, etc.





External Links


  1. Measuring DevOps Success with Four Key Metrics:
  2. Failure – the fertilizer of "Continuous Learning":
  3. How to measure the accuracy of forecasts:
  4. Does Your Kanban System Produce Reliable Probabilistic Forecasts? Thin-Tailed vs Fat-Tailed Cycle Time Distributions:
  5. Kanban Maturity Model – Understanding Lead Time:
  7. Latency Numbers Every Team Should Know: (Unit Test runtime, time to CodeReview, PR merge to PROD deploy, etc)
  8. Top 10 Metrics You Need For Measuring Productivity:
  9. Unlocking Measurability:
  10. 5 WhitePapers to Improve Software Delivery -- Measure Efficiency, Effectiveness, and Culture to Optimize DevOps Transformation:
  11. A Data Scientist’s Guide To Measuring Product Success:
  12. DevOps Metrics & Measurements Playlist:
  13. ZDNet -- Digital Transformation Series - The wrap:
  14. What does Digital Transformation mean? What are its nine core elements?:
  15. What is digital transformation?:
  16. What is digital transformation? A necessary disruption:
  17. What Digital Transformation will enable:
  18. World Economic Forum (WEF) -- The Fourth Industrial Revolution - what it means, how to respond: (includes video summary that caused a stir from support to skepticism)
  19. Davos WEF - Everything you need to know about the Fourth Industrial Revolution:
  20. Davos, Blockchain, and the 4th Industrial Revolution:
  21. World Economic Forum -- Leading through the Fourth Industrial Revolution - Putting People at the Centre (2019):
  22. Digital Transformation Report (2018):
  23. 5 ways to kickstart a Digital Transformation project:
  24. What’s driving digital transformation (and what can hamper it)?:
  25. 9 Digital Transformation Statistics That Every Business Should Know:
  26. The Future of Digital Transformation & The Growth of IoT: (nice stats/figures on higher profit margins and revenue growth/stability)
  27. (Maybe Digital Transformation should be called) "Customer Experience lead Transformation":
  28. Brian Solis - The Definition of Digital Transformation (INFOGRAPHIC):
  29. 6 stages of Digital Transformation in HR (INFOGRAPHIC):
  30. CGI UK's take on Digital Transformation (INFOGRAPHIC): (generational)
  31. Benchmarking Digital Transformation to Drive Better Outcomes in Health & Life Sciences (INFOGRAPHIC): (goals .vs. challenges)
  32. Digital transformation is disrupting quality assurance:
  33. 10 digital transformation must-reads:
  34. The Satir Change Model:
  35. Digital Transformation Outlook In 2019: (what keeps IT Leaders up at night)
  36. Accelerating Digital Transformation and Application Performance In Turbulent Times:
  37. COVID-19 Triggered the Turning Point:
  38. COVID-19 is Accelerating the Rise of the Digital Economy:,-technology-transformation/covid-19-is-accelerating-the-rise-of-the-digital-e
  39. Your business has gone "Digital" - now what?: (11 best practices for Digital Transformation and measurement)
  40. The Seven Domains of Product Transformation:
  41. What Is Product-Based Software Delivery?:
  42. Digital is not (and never was) an easy button:
  43. How the FT went from no digital presence to over a million paid digital subscribers:
  44. Digital Presence - What It Is and How To Expand Yours (Infographic):
  45. The "Digital Transformation" COVID-19 joke:
  46. Many Small Businesses Have Little to No Online Presence: (in 2015-09-16 only 40% of those run 1-5 people had a website, only 12% have Facebook or other Social Media presence)
  47. 40% of small businesses don’t have a website, survey finds: (4 years later, by 2019, it had improved by 20% but 40% still don't have online presence)
  48. What’s the Cost of Not Going Digital For a Business?:
  49. 74 Percent of Small Business Websites Have No eCommerce:
  50. The Complete List of Resources on Cohort Analysis:
  51. Will DevOps Culture Come to Smart Buildings?:
  52. Zero Defects -- Baking Quality into the Agile Process:
  53. How NIST CSF and NIST RMF Can Work Together:
  54. DevOps is outdated. Here comes DevSecOps.:
  55. Achieving DevSecOps with Open-Source Tools:
  56. Baking Compliance in your CI/CD Pipeline:
  57. Diving into DevSecOps w/ John Willis:
  58. Scaling a governance, risk, and compliance program for the cloud, emerging technologies, and innovation:
  59. Assessing Security Controls - Keystone of the Risk Management Framework:
  60. Risk Management Framework (RMF) -- An Overview:
  61. The Five Rules of Risk:
  62. Risks in IT/Software digest:
  63. Managing Risk on Agile Projects with the "Risk Burndown Chart":
  64. 2019 Global Data Risk Report From The Varonis Data Lab:
  65. Netflix tech blog -- Open-Sourcing "riskquant" - a library for quantifying risk:
  66. Three Innovative Funding Models to Enhance DevOps - IT Revolution: (incorporating risk factors towards measuring ROI/Budgets)
  67. A Global Risk Assessment of 2021 and beyond - COVID's impact on national/organizational/personal risk (CHART):
  68. Quality Leadership -- Risk Analysis as Quality Advocacy:
  69. Integrating ITIL Change Management and DevOps:
  70. Innovate ITIL -- A DevOps Approach to the ITIL Framework:
  71. DevOps or Die - DevOps and ITSM/ITIL:
  72. The Difference Between CI Pipelines and "DevOps Assembly Lines":
  73. Splunk & VictorOps -- DevOps Release Management Best Practices:
  74. Plutora -- Release Management Process and Best Practices:
  75. Disciplined Agile -- RELEASE MANAGEMENT:
  76. Release Engineering vs. Release Management:
  77. Release Management In DevOps: (use of CCB & CAB can still work, with some tweaks)
  78. Application Release Automation (BEFORE & AFTER):
  79. Release and deployment management made easy with 11 ITIL best practices:
  80. Intersection of ITIL and Agile methods in the cloud:
  81. ARCAD Release Management Fits With UrbanCode DevOps:
  82. Enterprise Release Management for DevOps & Continuous Delivery/ From Spreadsheets to Pipelines in Simple Steps:
  83. Why environment provisioning is a key part of DevOps?:
  84. The Job of the Release Manager:
  85. 5 Steps to a Successful Release Management Process:
  86. DevOps Maturity Curve:
  87. DevOps Culture -- A Huge Step for Mankind:
  88. 24 Key Capabilities to Drive Improvement in Software Delivery:
  89. Five cultural changes you need for DevOps to work:
  90. DevOps Culture - What It Means, Why It Matters:
  91. Shifting Organizational Mindset from “Project” to “Product”:
  92. Shifting Mindsets - How to Break Free From a ´Fixed Mindset´ to a ´Growth Mindset´:
  93. The five keys to a successful Google team:
  94. What Google Learned From Its Quest to Build the Perfect Team:
  95. Two Simple Questions for Better Business Outcomes:
  96. A Visual Guide -- To Sustainable Software Engineering:
  97. Don’t lose developers to bad culture:
  98. Blameless Postmortem:
  99. Its not your fault -- Blameless Post-Mortem:
  100. How to run a blameless postmortem:
  101. Blameless culture - post-mortem guidelines: (nice summary table on biases that can result in blame)
  102. 5 Whys — how we conduct blameless post-mortems after something goes wrong:
  103. Blameless PostMortems and a Just Culture:
  104. Why Blameless Post-Mortems are Essential:
  105. "Blameless" postmortems don't work. Here's what does.:
  106. Let’s Stop Using The Term “Blameless Culture”: (maybe actionable retros instead)
  107. "Blameless Post-Mortems" presentation by Jason Hand, DevOps Evangelist, VictorOps (VIDEO):
  108. Why Blameless Post-Mortems:
  109. What is DevOps?:
  110. What is the "essence" of DevOps?:
  111. The Essence of DevOps:
  112. 7 warning signs you need DevOps:
  113. Towards Compliance as Code using the DevOps Audit Defense Toolkit:
  114. DevOps library:
  115. IBM -- Keys to DevOps success (VIDEOS):
  116. 8 Ways to Track the Success of DevOps Teams:
  117. Blue-green Deployments, A/B Testing, and Canary Releases:
  118. Blue/Green Deployment: (the A/B Testing of server infrastructure, test your releases in PROD and quickly revert back)
  119. Culture, Automation, Measurement & Sharing (CAMS): (acronym describing the core values of the DevOps Movement, later expanded to "CALMS" by addition of Lean thinking)
  120. What Is DevOps?:
  121. What Is DevOps?:
  122. Ken Mugrage -- My Definition of DevOps: (A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system)
  123. What is DevOps and why does it matter?:
  124. The benefits of DevOps:
  125. An idiot’s guide to DevOps:
  126. Targeting software development to SoCs / NoCs using a DevOps approach: (Software-On-a-Chip & Network-On-a-Chip)
  127. wikipedia: Network operations center (one of two main IT definitions of NOC, the other being Network-On-Chip)
  128. The Role of a Traditional NOC in the new DevOps World:
  129. How QA Can Help Lead the DevOps Charge:
  130. DevOps Interview -- Patrick Debois: (often credited as the creator of the term "DevOps" in 2009 to summarize tendency towards integration of Agile/Scrum/Lean/CI/CD/CT/Automation movements)
  131. Minneapolis 2014 - Five Years of DevOpsDays:
  132. Why We Need DevOps Now (2012):
  133. You, yes YOU -- DevOps' people problem: (Chucking a copy of "The Phoenix Project" at the team ain't the answer)
  134. Inside Obama's "Tech Team": (with quote from "Head of DevOps, Scott VanDenPlas")
  135. DevOps At Obama for America & The Democratic National Committee:
  136. Cultural Challenges of Release Management Best Practices, DevOps Accompanied Obama Campaign Successes:
  137. Culture Automation Lean Measurement Sharing (CALMS) -- A Principle-based DevOps Framework:
  138. INVEST in Good Stories, and SMART Tasks: (S=Specific, M=Measurable, A=Achievable, R=Relevant, T=Time-boxed)
  139. DevOps - The smart person's guide:
  140. A DevOps primer -- Start, improve and extend your DevOps teams:
  141. Yes, DevOps initiatives sometimes fail:
  142. Creating the Safety to Fail:
  143. The Essence of Mobile DevOps Is to Destroy Silos:
  144. The Basics of Mobile Continuous Integration Workflow:
  145. Continuous Integration and Delivery for Agile Teams:
  146. Diving Deeper into DevOps Deployments - Featuring Gene Kim:
  147. Atlassian - StatusPage: (communicate with your business/customers about service/website availability providing downtime/uptime transparency)
  148. WIP -- The System Bites Back:
  149. User stories in an Agile world:
  150. INVESTing in good stories:
  151. Product Backlog is DEEP; INVEST Wisely and DIVE Carefully:
  152. INVEST in "good" User Stories - Managing Requirements in Agile Business Analysis:
  153. Agile and DevOps -- Friends or Foes?: (includes a nice table summary of the infamous "Three Ways")
  154. Is DevOps Agile?:
  155. DevOps -- Where the world meets DevOps:
  156. DevOps Reactions:
  157. IBM developerWorks -- Learning DevOps:
  158. Sate of DevOps 2017:
  159. DevOps Days:
  160. What Is DORA and Why Should You Care?:
  161. The DevOps Assessment: (DORA = DevOps xRay Assessment)
  162. The DevOps Handbook -- An Introduction Summary:
  163. DevOps - Boring Is the New Black:
  164. Microsoft take on question "What is DevOps?":
  165. Microsoft Azure - DevOps guides:
  166. 10 ways to build highly effective - DevOps teams:
  167. DevOps Transformation Using Theory of Constraints - Part 1:
  168. DevOps Transformation Using Theory of Constraints - Part 2:
  169. Definition of what a "Brent" is: (to help recognize when you or someone on your team is becoming one)
  170. Sad alternative outcome from The Phoenix Project for what happens when a "Brent" is not managed correctly:
  171. wikipedia: Andon (manufacturing)
  172. wikipedia: Traditional_lighting_equipment_of_Japan#Andon
  173. The Andon Cord:
  174. Toyota Andon concept at the infamous "MotoMachi factory" in Japan:
  175. Toyota cutting the fabled "andon cord", symbol of Toyota Way: (principle not going away, replacing white cords with yellow buttons)
  176. Incorporating Andon Cord in DevOps:
  177. The Andon Cord - A Way to Stop Work While Boosting Productivity:
  178. DevOps, Deming, and how "Pulling the Andon Cord" works in software development:
  179. DevOps Leaders vs. Laggards -- Continuous Testing is a Key Differentiator:
  180. Agile Vs. DevOps -- 10 Ways They're Different:
  181. Waterfall to Agile to DevOps -- The State of Stagnant Evolution:
  182. DevOps -- Who Does What (Part 1):
  183. DevOps on AWS Radio -- Continuous Delivery at Netflix — Adam Jordens (Episode 16) (PODCAST):
  184. DevOps Case Study -- Netflix and the Chaos Monkey:
  185. All-day DevOps conference 2017: (all speakers)
  186. AWS Public Sector Summit 2016 -- DevOps track - Getting out of Operations Hell:
  187. Amazon AWS - DevOps model defined:
  188. How Amazon handles a new software deployment every second:
  189. Amazon deploys every 11.6 seconds (2011):
  190. Velocity 2011 -- Jon Jenkins, "Velocity Culture": | SLIDES
  191. The Story of Apollo - Amazon’s Deployment Engine:
  192. AWS re:Invent 2015 -- DevOps at Amazon - A Look at Our Tools and Processes (DVO202): | SLIDES
  193. Why the DevOps faithful keep pulling away from their competitors:
  194. 10 companies killing it at DevOps:
  195. Adobe turns to DevOps to manage cloud deliveries:
  196. Netflix earnings, DevOps & profitability:
  197. What can you do when the pup of programming becomes the black dog of burnout? Dude, leave:
  198. DevOps - working to prevent "Karōsu" & "Karōjisatsu" (aka. "death by work" & "burnout"):
  199. Google .vs. Amazon's approaches to DevOps:
  200. Is DevOps Bullshit?:
  201. Twitter feed -- DevOps Borat:
  202. Continuous Delusion at the Infrastructure Layer:
  203. The Five Ideals and The Unicorn Project:
  204. Going to Market Faster -- Most Companies Are Deploying Code Weekly, Daily, or Hourly:
  205. DevOps & Security - Chaos Monkeys:
  206. 2018 State of the Software Supply Chain Report (12 DevSecOps findings):
  207. Best Practices for Measuring your Delivery Pipeline: | SAMPLE CODE
  208. The Ultimate DevOps Tools Ecosystem Tutorial, Part I -- Overview - Plan, Develop, Test, Release, Operate:
  209. The Ultimate DevOps Tools Ecosystem Tutorial, Part II -- Planning:
  210. The Ultimate DevOps Tools Ecosystem Tutorial, Part III -- Developing:
  211. The Ultimate DevOps Tools Ecosystem Tutorial, Part IV -- Testing:
  212. The Ultimate DevOps Tools Ecosystem Tutorial, Part V -- Releasing:
  213. The Ultimate DevOps Tools Ecosystem Tutorial, Part VI -- Operating:
  214. 11 Tools You Must Have in Your DevOps Toolchain (INFOGRAPHIC):
  215. Complete DevOps (at & with GitLab) is DevOps reimagined. Here's what that looks like:
  216. Build Continuous Quality Into Your DevOps Toolchains (GARTNER REPORT):
  217. 10 Tips for Enterprise DevOps:
  218. 7 Things Your Boss Doesn’t Get About Software Development:
  219. Do programmers take advantage of managers that don’t understand code?:
  220. 7 signs you're doing devops wrong:
  221. DevOps Is Bullshit -- Why One Programmer Doesn’t Do It Anymore:
  222. Why One Programmer Doesn’t "Do DevOps" Anymore (HackerNews discussion):
  223. Is DevOps Buillshit (i.e. why it isn't... response to previous blog post):
  224. Why DevOps (done badly) is burning out developers:
  225. Doing DevOps? Turn your boss into a DevOps leader first (or suffer):
  226. How to convince your boss that it is DevOps that he wants (by Jan de Vries):
  227. DevOps automation remains a high hurdle for DevOps culture:
  228. What DevOps Taught Us in 2018:
  229. Why you need a DevOps Transformation to Survive:
  230. 5 Guaranteed Ways to Kill DevOps Developer Productivity: (Plumbing work, Security after the fact, Status checks, GUI/overhead overload, Tool tyranny)
  231. Digital Transformation for Modern Enterprises Through DevOps — A Complete Guide:
  232. How the Flow Framework® Maximizes Your Wins from SAFe®:
  233. Signs You’re in a Death Spiral (and How to Turn It around before It’s Too Late):
  234. Flow Metrics - What They Are & Why You Need Them (SLIDES):
  235. Minimize Team Cognitive Load to Increase Flow:
  236. Have you already started to use Infrastructure as Code on your daily work?:
  237. IaaS, EaaS, PaaS, and DevOps – Good for Absolutely Everything:
  238. Should We Start Baking Immutable Infrastructure Instead of Frying On-Demand?:
  239. Google -- SRE vs. DevOps - competing standards or close friends? (BACKUP):
  240. SRE vs DevOps vs Cloud Native (SLIDES):
  241. Intercom’s Rich Archbold on how to run less software:
  242. Site Reliability Engineering -- How Google Runs Production Systems: (full book by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Murphy & Google SRE teams)
  243. NewRelic -- guide to Site Reliability Engineering:
  244. SREiously -- goal, role & types of SRE:
  245. Why Do Great Product Companies Release Software To Production Multiple Times A Day:
  246. 5 things toxic to scalability:
  247. SRE vs DevOps: What's the difference?:
  248. SRE vs. DevOps — a False Distinction?:
  249. Google SREs on "What's the Difference Between DevOps and SRE?":
  250. SRE vs. DevOps -- Any Common Ground? :
  251. DevOps vs. SRE -- Why not both?:
  252. DevOps and SRE Words Matter - How Our Language has Evolved:
  253. The 4 Quality Gates Every SRE Team Must Check Before Promoting Code:
  254. An awesome roundup of SRE links:
  255. Building a Site Reliability Engineering (SRE) Capability:
  256. Showing the Value of Site Reliability Engineering (SRE):
  257. Implement Site Reliability Engineering:
  258. An Infographic for Site Reliability Engineering (SRE):
  259. Site Reliability Engineering (SRE) overview:
  260. What SREs Can Learn From Facebook’s Largest Outage:
  261. Building a Platform and SRE Team:
  262. How to Adopt an SRE Practice (When You're not Google):
  263. Value Streams in Software Development:
  264. Value Stream Mapping is a System Approach…Or Is It?:
  265. Value Stream Mapping to Eliminate Waste in the Supply Chain:
  266. Lean meets Industry 4.0 - Value stream thinking as denominator:
  267. Value Stream Mapping Guide - Complete VSM Tutorial:
  268. What is Value Stream Mapping (VSM), Benefits, Process and Value:
  269. Understanding Value Stream Management (as a software professional):
  270. Values, Leadership, and implementing the Deming philosophy:
  271. JFDI — When rationality and common sense leave the building…:
  272. US Department of Defense (DoD) -- "Title 10" - Authority & Responsibility:
  273. Netflix -- Migrating to Public Cloud (SLIDES):
  274. Jedi's Feel Doin' It: | MANIFESTO (an anti-thesis to command-control JFDI to start JDFI yourself)
  275. The underlying problem with Congress is deciding how to allocate their time:
  276. The Tragedy of the Commons:
  277. Tragedy of the Commons and a Land Ethic:
  278. The Tragedy of the Commons - How Elinor Ostrom Solved One of Life’s Greatest Dilemmas:
  279. Elinor Ostrom's 8 Principles for Managing A Commmons:
  280. Elinor Ostrom - Nobel Prize Lecture:
  281. Pluralistic Ignorance and Diffusion of Responsibility:
  282. Diffusion of Responsibility -- the Perspective for Bystander Effect from the Chinese Story of Three Monks:
  283. Building a culture of Responsibility in CEP Plant Timisoara :
  284. The Bystander Effect - Diffusion of Responsibility:
  285. wikipedia: DIKW pyramid
  286. wikipedia: Tuckman's stages of group development (Forming, Storming, Norming & Performing)
  287. MIT - Using the Stages of Team Development:
  288. Forming, Storming, Norming, and Performing:
  289. Question -- What Is The Difference Between Data, Information, Knowledge:
  290. Data, information, knowledge and wisdom:
  291. The Circle of Data, Information, Knowledge, Understanding, and Wisdom:
  293. Strive to get higher on the Data -> Wisdom Continuum — another key tenet:
  294. Remarkable Comic Explaining Why It’s Better To Really Understand Few Things Than Partially Know A Lot!:
  295. Good Decision-making (INFOGRAPHIC):
  297. Groupthink Kills Collaboration!:
  298. Dotted Line Reporting:
  299. What Team Structure is Right for DevOps to Flourish?:
  300. The State of DevOps 2019 -- A Roundup of “State of DevOps” Reports:
  301. 2019 Accelerate State of DevOps Report:

See Also

Agile | IT | Productivity | CI/CD | Automated Testing | Optimization/Metrics | Analytics | Dashboard