Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Destroying DevOps Culture Anti-Patterns

426 Aufrufe

Veröffentlicht am

A talk on the behaviors a team should display when undergoing a successful DevOps journey and transformation.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Destroying DevOps Culture Anti-Patterns

  1. 1. June 1, 2018 DevOps Culture Anti-Patterns DESTROYING
  2. 2. AGENDA 00 01 02 03 04 05 06 Who am I? Is this a DevOps? What is a “good culture”? An agile culture and correlating performance Changing behaviors, not minds The Anti-Patterns Summary
  3. 3. 00 INTRODUCTIONWho am I and why should you listen?
  4. 4. Introduction Colgate, Hershey’s, Premier League, Korean Air, Kellogg’s, Wendy’s, MasterCard, BridgeStone, Sprint, Ford, and many others. Clients Java (AEM, Tomcat, WebSphere) .NET (Sitecore, Umbraco) PHP (Wordpress, Drupal) And whatever else the client asks us to do… Tech Stacks 2004 University of Nebraska-Lincoln Bachelor of Science in Computer Engineering Education Systems Architect, VML TOM CUDD
  5. 5. 01 DEVOPSIs this a DevOps? How can I get one?
  9. 9. A CULTURAL and PROFESSIONAL movement, focused on how we build and operate high velocity organizations, born from the experiences of its practitioners. http://chef.github.io/devops-kungfu/#/ DevOps is …
  10. 10. 02 CULTUREWhat is a “good culture” in an organization?
  11. 11. Culture is not a spectator sport, something in which we are bystanders. Culture is an active, inclusive process. Culture
  12. 12. From: “A Typology of Organisational Cultures” WESTRUM CULTURES
  13. 13. • Fear-based • Information hoarded, withheld, distorted • Power-focused • Departments protected • Turf maintained • Rules-based • Focus on the mission • Performance-oriented Pathological Bureaucratic Generative
  14. 14. Think Apollo 13: Actionable information was provided to everyone to test at all times. “Houston, we’ve had a problem”
  16. 16. Individual employee optimization isn’t enough to bring success. Google team analysis
  17. 17. How teams interact, work together, and see their work is more important than who is on the team. Google team analysis
  18. 18. • Psychological safety • Dependability • Structure & clarity • Meaning of work • Impact of work Google team analysis, five keys to success
  19. 19. 03 PERFORMANCEAn agile culture correlates to high performing teams and a high performing organization
  20. 20. Lean Enterprise
  21. 21. “It was the system that made it bad, not the people.” – UAW negotiator Bruce Lee on the NUMMI plant (but probably not that Bruce Lee) Lean Enterprise
  22. 22. “A bad system will beat a good person every single time” – W. Edwards Deming Lean Enterprise
  23. 23. Accelerate
  24. 24. 04 BEHAVIORSChanging behaviors, not minds
  25. 25. “... the way to change culture is not to first change how people think, but instead to start by changing how people behave-what they do” -- John Shook episode 561WBEZ (This American Life 2015) About NUMMI -- quote in 2010 Lean Enterprise
  26. 26. Changing culture is achieved by the deliberate, repeated, mindful practice of everyone in the organization. Lean Enterprise
  27. 27. Think like Amazon: • Loosely coupled teams and systems lead to autonomy • Focus on testability and deployability • Encourage experimentation and learning Accelerate
  28. 28. Architecture and Leadership should focus on: • Coaching Engineers • Outcomes • Eliminating Blockers • Delegating authority and autonomy • Investing in technical management Accelerate
  29. 29. You can act your way to better culture by implementing these practices in technology organizations Accelerate
  30. 30. • Practice your form • Beginners seem uncomfortable, choppy • Experience makes it seem smooth, simple Example: http://codekata.com/ Kata
  31. 31. 05 THE ANTI-PATTERNSThe worst of what we do and how to stop them
  32. 32. • Increased Collaboration • Shared Responsibility • No Silos • Autonomous Teams • Building Quality into the development process • Feedback • Automation Markers of a Generative, DevOps culture
  33. 33. • Tribal Knowledge • Super Hero Culture • Silos • Centralized Decision Making • Quality at the end of the development process • Information Hoarding • Manual processes DevOps Culture Anti-Patterns
  34. 34. Tribal Knowledge vs. Increased Collaboration
  35. 35. Look For: • Blocking resources • Tickets with “status please?” • Tickets with resolution requests (not problem descriptions) Do Instead: • Use a wiki (or other knowledge repository) • Answer questions to as wide an audience as possible • Let someone else “drive” Tribal Knowledge vs. Increased Collaboration
  36. 36. Super Hero Culture vs. Shared Responsibility
  37. 37. Look For: • Many odd-hours, off-hours communications • Stress-APGAR (Appearance, Performance, Growth Tension, Affect Control, Relationships) – from Harvard Business Review • Other teams circumventing process to get to the “get things done” person Do Instead: • Monitoring use it or lose it vacation time • Monitoring hours over 40 worked • Rotate people on projects • Collaborate • Push rote work out of the system Super Hero Culture vs. Shared Responsibility
  38. 38. Silos vs. No Silos
  39. 39. Look For: • Look for arbitrary or intentional limiting of different team access to data or tools • Ops work planned “in sprint 0 or 1” • QA work planned “in the last sprint” • Teams not co-located (physical or virtual) Do Instead: • Combined source control • Combined document repositories • Combined standups/statuses • Proactive cross-team problem solving Silos vs. No Silos
  40. 40. Centralized Decision Making vs. Autonomous Teams
  41. 41. Look For: • Work has to “go through someone” for approval • Arbitrary reprimands for “not following process” or “governance” • Fear based rule of law • Senior contributors hoard information to increase their importance to the projects • Command and control structure Do Instead: • Trust people • Team filled with both Junior and Senior resources, requiring training and working together • Delegated decision making (caring about outcomes, not the how) • Pull based versus push based work (Kanban) • Mission command Centralized Decision Making vs. Autonomous Teams
  42. 42. Quality at the end of the development process vs. Building Quality into the development process
  43. 43. Look For: • Bug/issue tracking late into projects • Development in spurts based on QA response • Hours, budgets burned more as launch approached (really a waterfall project) Do Instead: • QA teams and Ops teams building automation together (with Devs, too!) • As many technical resources from different teams sitting together (Dev+Sec+QA+Ops) • Bugs tracked through the whole projects with a centralized queue for Dev, QA, Ops work Quality at the end of the development process vs. Building Quality into the development process
  44. 44. Information Hoarding vs. Feedback
  45. 45. Look For: • Who “owns” systems, tasks, processes • Overly focused on “right way” vs. DONE • Lack of trust or empathy (RTFM!) • Trying to reduce or limit change to systems, not information about critical changes Do Instead: • Task tracking for issues, documented release notes for builds • Feedback on blocking resources • Reaching “across the aisle” • Expect information to be shared • Direct radical candor in person or via video chat (not email) Information Hoarding vs. Feedback
  46. 46. Manual Processes vs. Automation
  47. 47. Look For: • “It’s faster for me to do it” than show someone or document it • “I don’t trust the machines to do it right” • “It will take too long to automate” or “You can’t automate that” Do Instead: • Pair engineers to document processes • Automate something small rather than nothing (tie small steps together later) • Buy back any time through optimizations or saved steps Manual Processes vs. Automation
  48. 48. 06 SUMMARYWords to live by
  49. 49. ADAPT OR DIE
  50. 50. Lack of urgency will kill organizations with bad culture (eventually) Adapt or die
  51. 51. CARE AND ACT
  52. 52. Care about people, help others, and act upon those feelings and emotions Care and act
  53. 53. CHANGE
  54. 54. When we can’t change other people, teams, organizations, we change ourselves instead Change
  55. 55. SUCCESS
  56. 56. A successful org has good culture, teams, people, trust, relationships, positive actions Success
  57. 57. “Everyone thinks of changing the world, but no one thinks of changing himself.” - Leo Tolstoy
  58. 58. THANK YOU
  59. 59. • https://hbr.org/2017/04/an-early-warning-system-for-your-teams-stress-level • http://partnersforlearning.com/instructions.html • https://q12.gallup.com/ • https://martinfowler.com/bliki/DevOpsCulture.html • https://www.nasa.gov/mission_pages/apollo/missions/apollo13.html • https://www.nasa.gov/multimedia/imagegallery/image_feature_305.html • http://chef.github.io/devops-kungfu/#/ • https://medium.com/@josef_89142/big-it-rising-b98826b68364 • https://langerman.co.za/a-step-by-step-curated-reading-list-an-introduction-to-new- ways-of-working-lean-agile-and-devops/ • https://hbr.org/2015/11/how-company-culture-shapes-employee-motivation • http://qualitysafety.bmj.com/content/13/suppl_2/ii22 • http://qualitysafety.bmj.com/content/qhc/13/suppl_2/ii22.full.pdf • https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its- quest-to-build-the-perfect-team.html • https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/ • https://rework.withgoogle.com/guides/understanding-team- effectiveness/steps/identify-dynamics-of-effective-teams/ • https://hbr.org/2014/03/googles-scientific-approach-to-work-life-balance-and-much- more • https://rework.withgoogle.com/guides/understanding-team- effectiveness/steps/help-teams-determine-their-needs/ Links
  60. 60. • W. Edward Deming • Martin Fowler • Nichole Forsgren, PhD • Gene Kim • Jez Humble • Barry O’Reilly People to know
  61. 61. • Twitter: @tomcudd • Website: https://tomcudd.com • Carrier Pigeon: Roberto Thanks!