When I was asked to write a book about GitHub, I first came up with an outline that had an introduction to DevOps with nearly 200 pages and then covered all GitHub Features in a logical order. “Nobody wants to read a 200-page introduction” was the the response from my editor that made me completely rethink what I wanted to write about and how I should structure it.

The story

Telling a story is hard – finding a story worth telling is even harder.

I wanted to give my readers a practical guide to DevOps. There are many books and research about DevOps – but the books are often very theoretical, and people still fail to apply DevOps in their organization.

DevOps is like Kitesurfing. If you see people doing it, it looks so easy. But if you try, you will experience many external influences that cannot be controlled: the wind strength, gusts, and directions, waves, sea current, the tides, rocks, and other kiters. This makes it hard, and you must master kite and board control before being able to ride and make it look easy. But once you master the basics and can rely on your trained muscle memory to do the right movements it becomes easy, and progression and the first jumps are easy.

And the same is true for DevOps. You see companies like Google and Microsoft doing it and it looks easy – you try it yourself and you will find a lot of challenges and external influences that you cannot control. DevOps only works if you apply it to all aspects of your engineering organization – and yet you must train each capability separately.

So how do we coach organizations to accelerate their software delivery and progress in their DevOps journey? The answer is exactly the story I want to tell in the book. I want to explain WHY we do certain things in a given order to continuously improve, but also with hands-on practical guidance on HOW to do it.

Finding the right balance between WHY and HOW is not easy. I have an awesome team of technical reviewers (Thanks to Mickey Gousset, Unai Huete Beloki, and Stefano Demiliani). And one of them really loves hands-on, practical stuff with a lot of screenshots – and he always complained that the theoretical part is boring and too long. But I also believe a book should not be solely a product documentation. If you want documentation on GitHub, you can go to https://docs.github.com/. It’s their always up-to-date documentation website with more content than would fit into a book. Finding a technical book with the right balance between WHY and HOW – between theory and practical content – for your taste is probably the most important factor that influences how much you like the book.

The book outline

With this story in mind, I created a completely new outline. The first thing we do when we start working with customers is have a look at the metrics and KPIs they measure. We measure the customer’s DevOps metrics (Delivery Lead Time, Deployment Frequency, Mean Time to Restore, and Change Fail Percentage) to identify bottlenecks in the value streams and to prove that our changes yield the expected results. Once the right metrics are in place, we pick – or put together – one or more pilot teams. The pilot teams will be moved to the new platform – in this case GitHub – and work independent from previous metrics and restrictions. This is the first chapter. To better illustrate how theory and practice go together I added a case study that explains how we do DevOps transformation projects with customers.

Part 1: Lean Management and Collaboration

The rest of Part 1 is all about lean management and how to reduce ballast from your development process. I explain how to manage work with GitHub Issues and GitHub Project’s Kanban Boards, how to establish pull and limit WIP, how to collaborate effectively with pull requests, and how to work asynchronously in distributed and remote teams.

Part 2: Engineering DevOps Practices

Part 2 explains the most important engineering practices for effective DevOps. I explain how to use GitHub Actions to automate build and release pipelines – but also other engineering tasks. This part also covers trunk-based development and feature flags. These are the most important engineering capabilities that teams have to master on their journey – and they are the most powerful tools that yield quick results.

Part 3: Release with Confidence

Part 3 goes deeper into optimizing pipelines and making release more stable and more secure. This includes concepts like shifting left testing and security, testing in production, chaos engineering, DevSecOps, securing your software supply chain, and ring-based deployments.

Part 4: Software Architecture

Part 4 is about the correlation of software architecture and communication in an organization. I explain how to transform your monolith gradually to a loosely coupled, event-based architecture.

This is also where I go deeper into the optimal size and structure of teams. I explain Conway’s law, the two-pizza team, and the Inverse Conway Maneuver.

Part 5: Lean Product Management

In Part 5 I explain the importance of lean product management, how to integrate customer feedback into your flow of work, and how to combine hypothesis-driven development with OKR. Part 1 was focused on HOW we build things – the work part. Part 5 is finally about WHAT we build. Experimentation and A|B testing require all the other engineering capabilities and a high cultural maturity.

Part 6: GitHub for your Enterprise

With this book structure, there are some topics left that normally a technical book would start with: hosting and pricing, migrations, roles and permission, and best-practices to structure content. These are the topics in Part 6.

The last chapter of the book is about enterprise transformations. I explain why many transformations fail, data-driven transformations, and the Theory of Constraints. It basically sums up the book and gives you guidance on how to use the content of the book to drive a successful enterprise DevOps transformation.

Value streams

Many books about DevOps start transformations by analyzing the value streams and optimizing product management alongside the engineering practices. In my opinion, this results in too many moving pieces. And it is also a chicken and egg dilemma. If you are not able to deliver frequently in small batch sizes, it is hard to apply lean product management practices. That’s why I start with just optimizing work and add lean product management practices later in the transformation.

Definition of DevOps

I don’t start the book with a Definition of DevOps, and it is in the last chapter that I really explain the term. And that is by design. Either you already know what DevOps is – or the meaning you attach to that word will be completely different at the end of the book.

Summary

I’ve learned a lot while writing the book. I hope you like the book and I’m very interested in getting feedback on what you liked and what you think can be improved. If you are interested in buying the book, you can order it now on Amazon.

---