How DevOps Impact Product Management by xOps Co-Founders
•Transferir como PPTX, PDF•
1 gostou•335 visualizações
Main takeaways: - Build an understanding of what DevOps is and the impact it can have on your business - Learn key principal of DevOps and understand practices and technologies you can use to implement them - Learn how DevOps impacts Product Management - Understand how DevOps can help deliver better products to market faster
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a How DevOps Impact Product Management by xOps Co-Founders
Semelhante a How DevOps Impact Product Management by xOps Co-Founders (20)
Mais de Product School
Mais de Product School (20)
Último
Último (20)
How DevOps Impact Product Management by xOps Co-Founders
- 1. www.productschool.com How DevOps Impact Product Management by xOps Co-Founders
- 2. Join 35,000+Product Managers on Free Resources Discover great job opportunities Job Portal prdct.school/PSJobPortalprdct.school/events-slack
- 3. C O U R S E S Product Management Learn the skills you need to land a Product Manager job
- 4. C O U R S E S Coding for Managers Build a website and gain the technical knowledge to lead software engineers
- 5. C O U R S E S Data Analytics for Managers Learn the skills to understand web analytics, SQL and machine learning concepts
- 6. C O U R S E S Learn how to acquire more users and convert them into clients Digital Marketing for Managers
- 7. C O U R S E S UX Design for Managers Gain a deeper understanding of your users and deliver an exceptional end-to- end experience
- 8. C O U R S E S For experienced Product Managers looking to gain strategic skills needed for top leadership roles Product Leadership
- 9. C O U R S E S Corporate Training Level up your team’s Product Management skills
- 10. Sean D. Mack & Larry Gordon T O N I G H T ’ S S P E A K E R S
- 11. @SeanDMackNYC @LaurenceMGordon @xOps ● What? ○ What does it mean? ○ What does it mean for Product Managers? ● How? ● Why?
- 12. @SeanDMackNYC @LaurenceMGordon @xOps SecTestxYourNoOpsDev The force multiplier for your operations.
- 13. @SeanDMackNYC @LaurenceMGordon @xOps So what is DevOps anyway?
- 15. @SeanDMackNYC @LaurenceMGordon @xOps Really it should be ProdDevTestSecOps
- 19. @SeanDMackNYC @LaurenceMGordon @xOps DevOps Timeline 2008 Shafer and Debois discuss “Agile Infrastructure” 2009 Allspaw and Hammond speak at Velocity 2010 First US Devopsdays 2013 “The Phoenix Project” by Kim, Behr and Spafford 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2014 Expansion of DevOps into enterprise environments. First DevOps Enterprise Sumit 2009 Debois launches the first Devopsdays event, in Ghent, Belgium 2016 Kim, Debois, Willis, and Humble publish “The DevOps Handbook”
- 20. @SeanDMackNYC @LaurenceMGordon @xOps DevOps People ● Collaboration! ● Transparency ● Empowering engineers ● Learning culture ● Ownership and accountability
- 21. @SeanDMackNYC @LaurenceMGordon @xOps DevOps Process ● Light weight ● Automated ● Trustful
- 22. @SeanDMackNYC @xOps DevOps Technology ● Collaboration - from documentation to communications ● Empowering - cloud platforms, deployment pipelines, self- service platforms ● Small batch deployment - CI/CD ● Automation - testing, infrastructure as code, automate management
- 24. @SeanDMackNYC @LaurenceMGordon @xOps But why does this matter to me? I’m a product manager.
- 25. @SeanDMackNYC @LaurenceMGordon @xOps “All product teams are ops teams now” - Dave Meyer, Atlassian
- 26. @SeanDMackNYC @xOps The “ilities” Usability Security Availability Reliability Scalability Maintainability Supportability Testability Interoperability Auditability / traceability
- 32. @SeanDMackNYC @LaurenceMGordon @xOps Value Stream Mapping
- 40. @SeanDMackNYC @LaurenceMGordon @xOps OK, but HOW?
- 41. @SeanDMackNYC @xOps Practical steps DevOps in Product Management ● Treat “Ilities” as part of the product ● Assess your capabilities ● Develop shared vision & goals ● Help the team get closer to the customer
- 42. @SeanDMackNYC @xOps Building Metrics Dashboards Defining what customer success is and building metrics Devops can more easily get this done than most teams, because of the available tools, skills, and mindset.
- 43. @SeanDMackNYC @xOps Grooming Sessions The product manager goes through the tech backlog Product managers give the devops team some kind of advance notice Not everything has to be in the next two-week sprint.
- 44. @SeanDMackNYC @xOps It Runs Both Ways Product managers to devops teams: 1. Collaborative mindset 2. Voice of the customer 3. Enabling workflows Devops to product managers: 1. Deep visibility into the health of a service. 2. Understanding technical debt 3. Building tools to help the product team innovate faster.
- 45. @SeanDMackNYC @LaurenceMGordon @xOps So why DevOps?
- 46. @SeanDMackNYC @xOps Why should Product Managers Seek to Practice DevOps ● Better prioritization of what should be built and where money and time should be spent ● Make it easier to innovate faster ● Build a better understanding of their product or service
- 47. @SeanDMackNYC @pmchrislee High performing DevOps teams 46x More frequent deployments 2,555x Faster lead time
- 48. @SeanDMackNYC @pmchrislee High performing DevOps teams 7x Lower change failure rate 2,604x Faster mean time to recover (MTTR)
- 49. @SeanDMackNYC @LaurenceMGordon @xOps Opsx Revolutionizing operations.
- 51. @SeanDMackNYC @LaurenceMGordon @xOps Get Involved Help us build the next generation of open source monitoring tools. Join our community https://www.facebook.com/xOpsArmy/ Contribute at GitHub github.com/xopstech Partner with us to try our software - free implementation and management for partner organizations.
- 52. www.productschool.com Part-time Product Management, Coding, Data Analytics, Digital Marketing, UX Design, Product Leadership courses and Corporate Training
Notas do Editor
- "As you checked in we sent you an email to join our online communities, events, and to apply for product management jobs. As members of the Product School community we'd like to provide you with these resources at your disposal."
- What DevOps Overview - So what is DevOps anyway? DevOps for Product Managers? How Practical steps for a DevOps in Product Why Benefits of DevOps Numbers
- Larry Intros
- My definition “A method of delivering value to the customer focused on collaboration and small batch sizes.” David Virtser, DevOps fan, leader Answered Jun 22, 2014 First of all DevOps is not a title/job/profession, DevOps is a culture. A healthy culture of organization's Dev and Ops guys to cooperate with each other. DevOps is talking about many aspects of Development and Operations processes while trying to optimize the engineering organization for growth and infrastructure for scale. DevOps culture is talking about: Engineers empowerment - by giving engineers more responsibility over the whole application lifecycle process. (dev -> test -> deploy -> monitor -> be on call) Test Driven Development - write tests before you write code. Unit tests, integration tests, system tests. This will help increase the quality of your service and give you more confidence to release faster and more frequent. Automation - automate everything that can be automated. Test automation, infrastructure automation (infrastructure as a code), deployment automation, etc.. Monitoring - monitor your apps, build monitoring alerts well. It should save your time, don't flood with metrics and alerts. Self service - provide a self service for any framework that you build or anything that you do. Don't be a bottleneck. People - but most importantly its talking about people culture that should be open minded, transparent, egoless, professional, with "can do" attitude.
- https://devops.com/surprise-broad-agreement-on-the-definition-of-devops/ “No, no it really should be Dev_____Ops” where the blank is filled in by their own specialty. Examples: DevQAOps, DevOpsSec, DevSecOps, BizDevOps and of course
- How many people are familiar with the waterfall method? DevOps as an anti-pattern
- 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). The focus is on all business value streams that are enabled by IT. In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service. The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming). Andon chords Shared goals Value stream analysis Cycle time - time to value Automated test 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. The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it. A/B testing Feature flags Swarming issues Customer contacts 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. We need both of these equally. Experimentation and taking risks are what ensures that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone. And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far. The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience. Chaos engineering Not just fault tolerant - but fault appreciative :) 20% time Hackathons Blameless culture/blameless postmortems From DevOps Institute The First Way – Flow • Practices include (but are not limited to): • Continuous integration – a development practice that requires developers to integrate code into a shared repository on a daily basis • Continuous delivery – a methodology that focuses on making sure software is always in a releasable state throughout its lifecycle • Continuous deployment – a set of practices that enable every change that passes automated tests to be automatically deployed to production © DevOps Institute unless otherwise stated Copyrighted Materials. • Value stream mapping – a lean tool that depicts the flow of information, materials and work across functional silos with an emphasis on quantifying waste, including time and quality • Kanban – a method of work that pulls the flow of work through a process at a manageable pace • Theory of constraints – a methodology for identifying the most important limiting factor (i.e., constraint) that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor The Second Way – Feedback Practices include (but are not limited to): • Automated testing • Peer review of production changes • Monitoring/Event Management data • Dashboards • Production logs • Process measurements • Post-mortems • Shared on-call rotation • Change, Incident, Problem and Knowledge Management data The Third Way – Continuous experimentation and learning Practices include (but are not limited to): • Experimentation and learning • The Deming Cycle • The Improvement Kata • Using failure to improve resiliency (e.g., the ‘Simian Army’ concept first adopted by Netflix) • ITSM improvement practices
- Larry - another model for defining DevOps is the CALMS model. CALMS is a conceptual framework for the integration of development and operations (DevOps) teams, functions and systems within an organization. The CALMS framework is often used as a maturity model, helping managers to evaluate whether or not their organization is ready for DevOps -- and if not, what needs to change. The acronym CALMS is credited to Jez Humble, co-author of "The DevOps Handbook." The five pillars of the CALMS framework for DevOps are: Culture - there is a culture of shared responsibility. Automation - team members seek out ways to automate as many tasks as possible and are comfortable with the idea of continuous delivery. Lean - team members are able to visualize work in progress (WIP), limit batch sizes and manage queue lengths. Measurement - data is collected on everything and there are mechanisms in place that provide visibility into all systems. Sharing - there are user-friendly communication channels that encourage ongoing communication between development and operations.
- Larry DevOps has been around for about ten years now but it is still very still in the definition stages. DevOps continues to grow especially in the Enterprise. https://www.ca.com/us/rewrite/articles/devops/a-short-history-of-devops.html 2008 Software developer Patrick Debois has a resume that reads like a map of IT nirvana. Over 15 years, the Belgian consultant has assumed different roles within large enterprises—developer, network specialist, system administrator, tester and project manager. Debois helps plant the seeds of the DevOps movement at the Agile conference in Toronto, where he thought there must be a better way to resolve the conflict between the software developers and the operations teams when it comes to getting great work done quickly. Debois soon became an influential early DevOps thought leader, and inspired others to take on these challenges. “In the IT industry, or perhaps to be more specific, in the software industry, particularly in the Web-enabled sphere, there’s a tacit assumption that projects will run late and [that] when they’re delivered—if they’re ever delivered—they will underperform and not deliver well against investment,” later wrote Stephen Nelson-Smith, a UK-based tech manager, in a guest post on Debois’ blog. “It’s a wonder any of us have a job at all!” 2009 At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—deliver a seminal talk known as “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The talk is an energetic presentation in which Allspaw and Hammond basically act out the classic “fingerpointy” conundrum of Dev versus Ops—“It’s not my code, it’s your machines!” (and vice versa)—to a roomful of developers. They make the case that the only sensible way to build, test and deploy workable new software is to make development and operations transparent and integrated. The talk becomes widely credited with showing the world what development-operations collaboration can achieve. Viewing the presentation from Belgium via streamed video, Debois is inspired to organize his own conference, called Devopsdays. The buzz continues long after the O’Reilly conference, and the name of the movement soon shortens to the portmanteau “DevOps.” Debois launches the first Devopsdays event, in Ghent, Belgium. Early supporters include John Willis, an enterprise system management expert, and Kris Buytaert, a Linux and open source consultant. 2010 The first US Devopsdays is organized, with the help of Willis as well as other early DevOps proponents like Damon Edwards and Andrew Clay Shafer. The events soon become a regular global series of community-organized conferences and a major force driving the DevOps community forward. The #DevOps Twitter hashtag becomes a rich and essential stream of information. 2011 With the growth of the new movement comes the emergence of leading analysts writing about it. Cameron Haight from Gartner, among others, predicts that by 2015, 20 percent of global 2000 businesses will embrace DevOps. Other important analysts who emerge around this time include Jay Lyman from 451 Research. The DevOps community starts to build open source tools like Vagrant (for creating and configuring virtual development environments) that work with existing configuration management tools like Puppet and Chef. 2012 The application development sector has grown fast, furious and increasingly focused on the enterprise. Total annual revenue reaches $53 billion, according to the London-based research firm VisionMobile. Like a desert abloom after a rain shower, various Devopsdays are suddenly popping up around the world, from Bangalore to Boston. They become must-attend events to check in on the latest smart and innovative thinking in the DevOps world. 2013 One important voice in the DevOps universe belongs to Mike Loukides, vice president of content strategy for O'Reilly Media. He, along with Debois, edits some of the most fundamental DevOps texts. In his report “What is DevOps?”, Loukides notes that “it is always easy to think of DevOps (or any software industry paradigm) in terms of any of the tools you use. In practice, this means that it is easy to think that if you use development programs like Chef or Puppet, you’re really doing DevOps.” Loukides sees DevOps as “an intimate understanding between the development and operations teams.” A flood of DevOps-related books begins to appear. Some of the essential texts include “The Phoenix Project” (by Gene Kim, Kevin Behr and George Spafford), “Implementing Lean Software Development” (by Mary and Tom Poppendiek) and “The Lean Startup” (by Eric Ries). They join key earlier and associated works like “Web Operations” (by John Allspaw), “Continuous Delivery” (by Jez Humble and David Farley) and “The Goal” (Dr. Eliyahu M. Goldratt) 2014 The ever-evolving tech world presents new challenges and opportunities to the concept of DevOps. The explosion of new devices, applications, content and transactions in the mobile environment brings new focus to both mobile apps and cloud computing. DevOps crosses into the enterprise, and established brands like Target, Nordstrom and LEGO embrace the movement. In a survey by Puppet Labs, IT Revolution Press and ThoughtWorks, 16 percent of 1,485 respondents say they are part of a DevOps effort within their organization. The “DevOps Enterprise: The Agile, Continuous Delivery and DevOps Transformation Summit”, the first industry event focused on helping enterprise software organizations accelerate quality software delivery is held in October in Burlingame, Calif. Read more at https://www.ca.com/us/rewrite/articles/devops/a-short-history-of-devops.html#s3sB8gT7wuEu4e1c.99
- People - but most importantly it’s talking about people culture that should be open minded, transparent, egoless, professional, with "can do" attitude. In addition to the organizational models there are several other key components of people working in a DevOps environment: Collaboration! Transparency - making work visible Empowered engineers Learning culture - blameless and fault tolerant (fault permissive?) Ownership and accountability
- DevOps and ITIL are not contradictory Automate change management
- What is a “DevOps” tool? There is no such thing. But if we think of DevOps as a culture of collaboration then we can consider a set of tools which enable collaboration A collaboration tool, like chat, can be used in a uncollaborative way Engineers empowerment - by giving engineers more responsibility over the whole application lifecycle process. (dev -> test -> deploy -> monitor -> be on call) Test Driven Development - write tests before you write code. Unit tests, integration tests, system tests. This will help increase the quality of your service and give you more confidence to release faster and more frequent. Automation - automate everything that can be automated. Test automation, infrastructure automation (infrastructure as a code), deployment automation, etc.. Monitoring - monitor your apps, build monitoring alerts well. It should save your time, don't flood with metrics and alerts. Self service - provide a self service for any framework that you build or anything that you do. Don't be a bottleneck.
- Larry
- Understanding non-functional requirements Reliability, Maintainability, Performanability “All product teams are ops teams now” - Dave Meyer, Atlasian Product Managers own the Product not just the features, this include how it performs Customer focus Value stream - it is all about delivering value to customer Everyone work in Support for a day (800 flowers has everyone deliver on valenties day) Feedback focus Rapid feedback loops Experimentation Feature flags Telemetry Metrics to drive business decisions Collaboration Breaking down silos Shared vision and shred goals How to handle releases? Shorter, and shorter, and shorter, and shorter delivery cycles Experience of constant changes all the time Experience
- For those of us working on digital products it is important to remember we are not delivering finished goods from the assembly line Gone are the days of building a product and delivering it on CD (or download). The service is part of the product, in many cases it IS the product.
- Non-functional requirement - Wikipedia Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities—that is non-functional requirements—can be divided into two main categories: Execution qualities, such as safety, security and usability, which are observable during operation (at run time). https://en.wikipedia.org/wiki/Non-functional_requirement Performance How quickly must the system respond to interactive operations of different kinds? Are there different classes of interactive operations that users have different tolerances / expectations for? Is there a batch window? What runs in it? Do the batches have their own performance constraints, e.g., to clear the batch window before it closes? Does the batch load influence any interactive users running at the same time? Is there data with a high read/write access ratio that can be cached in memory at different tiers in the architecture? What are the expected performance bottlenecks? CPU? Memory on client, server or intermediate nodes? Hard drive space on each node? Communications links? DB Access Searching Complex joins Interaction with other internal systems? Interaction with systems in other departments? Interaction with partner systems? Interactions with public systems? Scalability Peak load of how many users doing what kinds of operations? Ability to grow to how many records in which critical database tables without slowing down related operations by more than X Avoiding saturating a communication link that cannot be upgraded to a higher speed? What dimensions can be scaled, e.g., more CPUs, more memory, more servers, geographical distribution? Is the primary scaling strategy to "scale up" or to "scale out" -- that is, to upgrade the nodes in a fixed topology, or to add nodes? Availability What is the required uptime percentage? Does this vary by time of day or location? What is the current schedule of controlled outages? Is this acceptable, or is there a goal to improve it? Reliability Are there components with reliabilities that are known to be less than the required reliability of the system? What strategies are currently in place to build more reliable capabilities out of less reliable capabilities? What is the expected mean time to failure by failure severity by operation? How will reliability be assessed prior to deployment? Security What operations need to be secured? How will users be administered? How will users be given permissions to access secured operations? What are the different levels of security and how do these map Security by operation Security by type of object Security by instance of object Maintainability Are there concerns about the ability to hire appropriate technology skills, attract them to the area at reasonable prices? What kinds of changes are anticipated in the first rounds of maintenance? What are their relative priority? What sort of regression testing is required to ensure that maintenance changes do not degrade existing functionality? What sort of maintenance documentation is expected to be produced? When? Flexibility Is there system behavior that needs to be changed regularly without program changes? Can this be encoded in the database? Are there run-time rules that can be handled using a rules interpretation engine? Are there functions that should be user scripted? If so, how will these be QA-ed? Configurability What parameters need to be set on a machine-by-machine basis? Personalizability What aspects of the system can be customized on a per-user basis? How does the user change these settings? What is the strategy for defaults? Usability Are there operations that need to be done as quickly as possible, so that user gestures should be minimized?> Are there difficult or occasional-user operations that require non-standard presentations to help the user perform correctly? What is the balance between data integrity and the ability to stop in a "work in progress" state? What styles of validation are used in what situations? What metaphors from existing or parallel systems should be used? What sort of training deliverables are expected? What sort of on-board help system is expected? Portability Data portability between this system and other systems? Portability across different versions of a single vendor's DB? Ability to port to a different vendor's DB? Which one(s)? When? Browser portability? What browser versions? Historical and future? Operating system portability? Conformance to standards What legal standards apply? What technical standards apply? Other standards, e.g., 508.1 for disabled users? What development standards apply? Database naming standards Existing internal architectural standards (e.g., everything goes in an Oracle database) Language and coding standards Testing and review standards Presentation standards, e.g., use of standard colors, controls or other affordances? Lifecycle models or methodologies Internationalizability What languages? In what order? How translated? Single or multi byte character sets? Efficiency -- space and time Responsiveness What are the expected and upper limit response times per operation in the system? What is the trade-off between lower averages and wider variations in response time? Interoperability What systems will this system interoperate with immediately? What other systems are anticpated? What classes of internal and external systems might later be needed to interoperate with? What functionality from this system needs to be exposed as a service in a service oriented architecture? What functionality from this system needs to be exposed as a Web service or via a portal? Upgradeability Do the servers need to be upgraded while running? How many client stations need to be upgraded, and what are the costs and mechanisms for upgrading them? How often do different kind of fixes need to be distributed? Are there "hot fixes" that have to go out right away, but others that can wait? How often do each kind occur? Auditability / traceability What record of who did what when must be maintained? For how long? Who accesses the audit trails? How? Is archive to tape or other off-site storage media required? Is "effective dating" required? Transactionality What are the important database and application transaction boundaries? Is standard "optimistic" locking appropriate, or is something more complex required in some or all cases> Is disconnected operation required by any node? Administrability What live usage information needs to be displayed? To who? How? When? What "live" interventions are required? What ability to handle remote configurations are required? Are there existing application management consoles that will be used to manage this application? Lots of others -- what are your favorites? Source: http://www.softwarearchitecturenotes.com/architectureRequirements.html
- Product Managers own the Product not just the features, this include how it performs
- Product Managers own the Product not just the features, this include how it performs
- Product Managers own the Product not just the features, this include how it performs And Product Managers should be part of the delivery team
- Larry Customer focus - it is all about delivering value to customer Everyone work in Support for a day (800 flowers has everyone deliver on valenties day)
- Feedback focus Faster feedback loops Experimentation Feature flags Telemetry Metrics to drive business decisions
- Feedback focus Experimentation Feature flags Feature flags can be a great way to manage rapid releases Done right these also allow for A/B testing
- Shared telemetry Taking information radiators to the next level - Monitor’s Everywhere at Pearson Measure Everything at Etsy - Etsy also emphasized this concept. In his famous blog post Measure Anything, Measure Everything, Ian Malpass wrote “If Engineering at Etsy has a religion, it’s the Church of Graphs. If it moves, we track it.” I recall that, when Etsy moved into their new eco-friendly offices they even had a sensor and report for the levels in the rainwater cistern on the roof of the building
- Larry ThoughtWorks Collaboration - breaking down silos
- Larry Develop shared vision and goals - focus on the Customer
- Rapid Releases - Releases are getting faster and faster faster and faster Continuous Integration Continuous Deployment
- University of Southern California - Center for Systems and Software Engineering
- Google release calendar While we can release anytime we don’t necessarily want to Rapid releases reduce “inventory” and get value to customer quicker But rapid releases can also cause customer confusion Need to understand your customers and set expectations Note that, just because you do not release it does not mean you are not doing CI/CD as long as it is in a deployable state Feature flags also offer a great way to manage this - releasing to your early adopter group first
- Help technology teams connect with the customer - bring them to the technology teams
- Larry Benefits product managers can provide to the devops: Demonstrating a collaboration mindset; all project managers really do all day is collaboration, communication, and consensus—they are supergood at it and can generally be a good example for others. Bringing the voice of the customer into everything; devops is not a means in and of itself, but the goal is to really speed things up to ultimately delight the customer. For example, think about how the product manager can help justify and build the business case for a new CI server. Enabling work flows that allow the team to use its product or get as close to it as possible; a product manager can help champion dogfooding or rotations through customer service, both of which are super valuable
- It’s important to note that we don’t just do DevOps to do DevOps. We don’t do DevOps because it is a buzzword, we do DevOps because it yields results.
- Larry Deep visibility into the health of a service. This really helps when setting up success metrics and SLAs. For example, what uptime can you promise customers? Understanding technical debt and the potential implications (what needs to be addressed so the product can continue to scale without issues?). Building tools to help the product team innovate faster; how can new features get out to customers faster? This usually includes build automation, strong testing, etc. From: https://www.infoworld.com/article/3287093/product-managers-need-devops-too.htm
- Sean But let’s talk about some real numbers State of DevOps - 2018 Shows that DevOps teams move faster
- Sean DevOps teams are more stable State of DevOps - 2018
- Larry… get involved and thanks