Tech Lead sharing practical insights on software craftsmanship, TDD, leadership, Bitcoin, and AI. Blog posts, book summaries, and conference talks.Zola2024-05-31T00:00:00+00:00https://chemaclass.com/tags/devops/atom.xmlA Novel About IT, DevOps, And Helping Your Business Win2024-05-31T00:00:00+00:002024-05-31T00:00:00+00:00 Gene Kim Kevin Behr George Spaffordhttps://chemaclass.com/readings/the-phoenix-project/

This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive.

<p>This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive.</p> <span id="continue-reading"></span> <blockquote> <p>If IT fails, the business fails.</p> </blockquote> <p><strong>DevOps Principles</strong>: Flow, Feedback, and Continual Learning and Experimentation. These guiding concepts promote advancements in responsiveness, dependability, and teamwork.</p> <h4 id="summary">Summary</h4> <p>The book starts with the promotion of Bill as VP of IT, and with that the responsibility of delivering an imposible (Phoenix) project. The CEO warns him that if the project does not deliver in time, then the entire IT department will be outsourced and the current IT employees will be fired.</p> <p>Bill tries to understand the status quo, and finds out that the people are too busy firefighting constantly and dealing with too many responsibilities (in addition, they are understaffed). Everything is urgent and needs to be done asap. The deadline was already setup from above, and there is no planning or discussions with other departments. TL;DR: Corporate chaos, politics and bloodbath meetings.</p> <p>However, Bill gets to know one person in the company that helps him improve the status quo, not by telling him what to do but by asking him questions to help find the solution.</p> <p>For example, the first question: “What are the four types of work that IT does?” which is not answered immediately but during the story:</p> <ol> <li><strong>Business projects</strong>: these are the projects that directly affect business goals. They generate revenue and deliver value to customers.</li> <li><strong>Internal projects</strong>: these are regular tasks that keep the system working. Like system upgrades, security patches, etc. It tends to be invisible and can become a bottleneck for IT departments.</li> <li><strong>Changes</strong>: the result of the previous business and internal projects, to know what to change with and within them.</li> <li><strong>Unplanned work</strong>: this is the real productivity killer. This is related to all operational issues resulted from the previous three types of work.</li> </ol> <hr /> <div style="position:relative;aspect-ratio:16/9;width:100%;"> <iframe src="https://www.youtube-nocookie.com/embed/6QNdL1I7OTM" title="YouTube video" width="560" height="315" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;inset:0;width:100%;height:100%;border:0;" allowfullscreen> </iframe> </div>Building and Scaling High Performing Technology Organizations2023-03-19T00:00:00+00:002023-03-19T00:00:00+00:00 Nicole Forsgren Jez Humble Gene Kimhttps://chemaclass.com/readings/accelerate/

The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

<span id="continue-reading"></span> <p>Accelerate explores how software development teams using <strong>Lean Software</strong> and <strong>DevOps</strong> can measure their performance and the performance of software engineering teams impacts the overall performance of an organization.</p> <blockquote> <p>Note: DevOps is about integrating and automating software development (Dev) and IT operations (Ops), focusing on improving (and shortening) the systems development life cycle.</p> </blockquote> <h2 id="key-capabilities">Key Capabilities</h2> <h3 id="continuous-delivery">Continuous Delivery</h3> <ul> <li>Use Version Control for all Production Artifacts</li> <li>Automate Your Deployment Process</li> <li>Implement Continuous Integration</li> <li>Use Trunk-Based Development Methods</li> <li>Implement Test Automation</li> <li>Continuous Delivery (CD)</li> </ul> <h3 id="architecture">Architecture</h3> <ul> <li>Use a Loosely Coupled Architecture</li> </ul> <h3 id="product-and-process">Product and Process</h3> <ul> <li>Gather and Implement Customer Feedback</li> <li>Make the Flow of Work Visible through the Value Stream</li> <li>Work in Small Batches</li> <li>Foster and Enable Team Experimentation</li> </ul> <h3 id="lean-management-and-monitoring">Lean Management and Monitoring</h3> <ul> <li>Have a Lightweight Change Approval Processes</li> <li>Monitor across Application and Infrastructure to Inform Business Decisions</li> <li>Check System Health Proactively</li> <li>Improve Processes and Manage Work with WIP (Work-In-Process) Limits</li> <li>Visualize Work to Monitor Quality and Communicate throughout the Team</li> </ul> <h3 id="cultural">Cultural</h3> <ul> <li>Support a Generative Culture</li> <li>Encourage and Support Learning</li> <li>Support and Facilitate Collaboration among Teams</li> <li>Provide Resources and Tools that Make Work Meaningful</li> <li>Support or Embody Transformational Leadership</li> </ul> <h2 id="four-key-metrics">Four Key Metrics</h2> <ul> <li><strong>Change Lead Time</strong> <ul> <li>Time to implement, test, and deliver code for a feature</li> </ul> </li> <li><strong>Deployment Frequency</strong> <ul> <li>Number of deployments in a given duration of time</li> </ul> </li> <li><strong>Change Failure Rate</strong> <ul> <li>Percentage of failed changes over all changes (regardless of success)</li> </ul> </li> <li><strong>Mean Time to Recovery</strong> <ul> <li>Time it takes to restore service after production failure</li> </ul> </li> </ul> <div style="position:relative;aspect-ratio:16/9;width:100%;"> <iframe src="https://www.youtube-nocookie.com/embed/_d9cws_T9qk" title="YouTube video" width="560" height="315" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;inset:0;width:100%;height:100%;border:0;" allowfullscreen> </iframe> </div>From introduction to advanced concepts2022-04-29T00:00:00+00:002022-04-29T00:00:00+00:00 Fran Ramírez Elías Grande Rafael Troncosohttps://chemaclass.com/readings/docker-secdevops/

A great book about Docker, from introduction to advanced concepts all covered by easy-to-follow examples.

<span id="continue-reading"></span> <p>A great book about Docker, from introduction to advanced concepts all covered by easy-to-follow examples.</p> <p>Best practices about how to build docker images and keep a good security layer when running containers as well, from the docker daemon and all tech behind docker.</p> <blockquote> <p>The book is available only in Spanish: <a rel="external" href="https://0xword.com/es/libros/103-docker-secdevops.html">0xWord</a></p> </blockquote>Organizing Business and Technology Teams for Fast Flow2022-03-31T00:00:00+00:002022-03-31T00:00:00+00:00 Matthew Skelton Manuel Paishttps://chemaclass.com/readings/team-topologies/

Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery.

<span id="continue-reading"></span> <p>Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery.</p> <h2 id="team-structure">Team structure</h2> <ul> <li>High cohesion: Group related things together.</li> <li>Loose coupling: There must be clear boundaries between the teams.</li> <li>Cognitive load: It’s like the RAM of the team. The team can burn down if you load with more than the team can handle.</li> </ul> <blockquote> <p>In order to avoid bottleneck teams, you need to make sure their cognitive load is not very high.</p> </blockquote> <h2 id="conway-s-law">Conway’s Law</h2> <ul> <li>The organization structure will influence the architecture of the team.</li> <li>Conway’s Law says that organizations will design systems that copy their communication structure.</li> <li>In other words, there will be no focus on the optimal architecture for the project.</li> <li>First you need to define the architecture of the project, and then form the teams.</li> </ul> <h2 id="team-first-thinking">Team-First Thinking</h2> <ul> <li>Who is in the team matters less than the team dynamics.</li> <li>When measuring performance, teams matter more than individuals.</li> <li>Team = group of 5-9 who work towards a shared goals as a unit. <ul> <li>Check <a href="/blog/dunbar-number/">Dunbar number</a>.</li> </ul> </li> <li>Forming a team takes from 2 weeks to 3 months.</li> <li>Cognitive load is the total amount of mental effort being used in the working memory.</li> <li>3 Types of cognitive load: <ul> <li>Intrinsic: Fundamentals of the problem space. Example: programming language.</li> <li>Extraneous: Environment related. Example: how to deploy.</li> <li>Germane: Special attention is required. Example: business domain.</li> </ul> </li> <li>Heuristics: <ul> <li>3 types of domain: Simple, complicated, complex.</li> <li>If the domain is too big, split it into subdomains.</li> <li>One team, either: <ul> <li>2-3 simple domains.</li> <li>1 complex domain.</li> <li>Avoid 2 complicated domains, better split the team.</li> </ul> </li> </ul> </li> <li>Define a Team API: <ul> <li>Code: endpoints, libraries, clients, …</li> <li>Versioning.</li> <li>Documentation.</li> <li>Practices and principles.</li> <li>Communication tools.</li> </ul> </li> </ul> <h2 id="team-topologies">Team Topologies</h2> <blockquote> <p>Instead of structuring teams according to know-how or activities, organize teams according to business domain areas.</p> </blockquote> <ul> <li>Success of topology depends both on team members and surrounding environment, teams and interactions.</li> <li>Split responsibilities to breakdown silos.</li> <li>Types of dependencies: Knowledge, task, and resource.</li> <li>Four types of teams: <ul> <li>Stream-aligned: deliver features, projects, products to the market asap.</li> <li>Enabling: grow the capabilities for the Stream-aligned team(s).</li> <li>Complicated-subsystem: reduce the cognitive load of the Stream-aligned team(s).</li> <li>Platform: make the Stream-aligned team(s) autonomous.</li> </ul> </li> </ul> <h2 id="team-interactions">Team Interactions</h2> <ul> <li>Collaboration. Work closely between teams with different skill sets.</li> <li>X-as-a-Service. Clear ownership, small cognitive load.</li> <li>Facilitation. Helping to clear impediments, focus on quality interactions between other teams.</li> </ul>