Process reading recommendations

The Goal

The Goal is a fable about Alex Rogo, a plant manager trying to improve performance. Alex has 90 days to save his plant by improving efficiency before HQ closes it.

Alex’s initial efforts don’t go well. Fortunately, Alex bumps into Jonah, an old friend who advises him to break out of conventional thinking methods to tackle problems. Throughout the narrative, Alex learns how to improve processes in his plant through lean principles.

Lean principles helped many of the most innovative manufacturing companies make products efficiently. It’s a tale of how to apply fundamental lean principles - like value streams, flow, waste, global efficiencies, and the theory of constraints - to a real setting.

The Goal is not about software development but manufacturing, so the reader doesn’t need any IT knowledge. The Goal still has a lot of value to people in IT because many of the foundational lean principles influenced DevOps.

Implementing Lean Software Development

Lean manufacturing is a management philosophy focusing on the reduction of seven wastes:

• Over-production
• Waiting time
• Transportation
• Processing
• Inventory
• Motion
• Scrap

Practiced by many innovative companies, including Toyota and 3M, lean principles revolutionized manufacturing. Now it’s doing the same for software.

Implementing Lean Software Development is a follow-up to 2003’s Lean Software Development: An Agile Toolkit. The original book showed developers could apply lean manufacturing philosophy to software development. After observing its adoption in the real world, Implementing Lean Software Development delivers the lessons learned as a hands-on implementation guide.

Implementing Lean Software Development contains case studies from companies like Google to make a case for lean practices in software development. Google applies four fundamental principles:

1. Value — Focus on the user, and all else will follow
2. Excellence — It’s best to do one thing really, really well
3. Democracy — Democracy on the web works
4. Speed — Fast is better than slow

Implementing Lean Software Development introduces several key ideas and philosophies companies should focus on when delivering software. These ideas form the basis of DevOps as we know it today. This book is helpful for those interested in the origins of modern software delivery and managers wanting to use best practices in their company.

The Pragmatic Programmer

The Pragmatic Programmer is an essential book for developing code well. The book calls software developers to care about their craft.

Why spend your life developing software unless you care about doing it well?

The Pragmatic Programmer teaches software developers to take a requirement and produce working, maintainable code that delights its users. The book has self-contained sections covering many software development aspects. Each presents best practices and pitfalls to avoid. This book applies to new coders, experienced coders, or software managers.

Throughout the book, several tips provide a philosophical idea that guides readers in how to think about software development. For example:

• Don’t live with broken windows: Fix bad designs, wrong decisions, and poor code when you see them.
• Prototype to learn: Prototyping is a learning experience. Its value lies not in the code you produce but in the lessons you learn.
• Always use source code control: Source code control is a time machine for your work – you can go back.

The Pragmatic Programmer is a tool developers can use to hone their craft through proven mastery methods. The book has a 20th Anniversary edition to include best practice modern development principles.

Kanban

Kanban is a way of structuring work in software development. According to the book:

A Kanban system is a system were a number of cards equivalent to the agreed capacity of a system are placed in circulation. One card is the equivalent of one piece of work. Each card acts as a signaling mechanism. A new piece of work can be started only when a card is available. This free card is attached to a piece of work and follows it as it flows through the system. When there are no more free cards, no additional work can be started. Any new work must wait in a queue until a card becomes available. When some work is completed, its card is detached and recycled. With a card now free, a new piece of work in the queuing can be started.

The value of Kanban is to focus efforts on the tasks in progress. Kanban practitioners can’t start more work without completing an existing card. The key properties of a Kanban system are:

• Visualize the workflow (using a Kanban board)
• Limit work in progress
• Measure and manage flow
• Make progress policies explicit
• Use models to recognize improvement opportunities

The central concept in Kanban is continuous improvement. Due to the transparency of the work philosophy, challenging interactions will happen, promoting continuous improvement.

The last part of the book provides a practical implementation guide on Kanban in your company. Kanban touches on many aspects of software delivery, product, and management.

Personal Kanban

Building on the principles of Kanban, Personal Kanban is about applying Kanban from an individual perspective. Kanban is about understanding our work in progress. By visualizing our work in progress, we can understand what to:

• Prioritize
• Take on
• Say no to

Personal Kanban has two essential rules:

• Make your task list visual
• Limit your work in progress

The use of Kanban can help us manage our work in progress to complete what we started. By limiting tasks that are works in progress, we can minimize the fatigue that comes from managing too many tasks at once.

Personal Kanban provides an actionable framework to understand our work and its context. This book can help individuals structure their tasks, but it can also apply to a team practicing Personal Kanban.

Team Topologies

Team Topologies provides a practical, step-by-step organizational design and team interaction model. The book introduces Conway’s Law to say that the communication pathways in an organization restrict the solutions it can come up with.

The book introduces four fundamental team types:

• Stream-aligned
• Enabling
• Complicated-subsystem
• Platform

And three team interaction patterns:

• Collaboration
• X-as-a-service
• Facilitation

You can build a map of how teams interact based on the team type and interaction modes. Based on the results, reteaming may be necessary to improve team functions.

The book suggests that for any team structure change, existing software will push back against new team structures. Managing the changing topology of teams in software organizations is crucial to organizational maturity.

Domain Driven Design

Software projects solve a particular problem. These projects are complex and need different stakeholders to offer their expertise, so collaboration is a must. Domain Driven Design aims to help the delivery of projects by:

• Taking care to define the core domain of the project and the problem it solves
• The collaboration of stakeholders in the project
• Forming a shared understanding and language that stakeholders can use to communicate

Domain Driven Design offers readers a systematic approach to domain-driven design. It presents:

• An extensive set of design best practices
• Experience-based techniques
• Fundamental principles that help the development of software projects facing complex domains

The book aims to help readers produce a domain model their teams can use to deliver complex software projects.

Topics include:

• Getting all team members to speak the same language
• Connecting model and implementation more deeply
• Sharpening key distinctions in a model
• Managing the lifecycle of a domain object
• Writing domain code that is safe to combine in elaborate ways
• Making complex code obvious and predictable
• Formulating a domain vision statement
• Distilling the core of a complex domain
• Digging out implicit concepts needed in the model
• Applying analysis patterns
• Relating design patterns to the model
• Maintaining model integrity in a large system
• Dealing with coexisting models on the same project
• Organizing systems with large-scale structures
• Recognizing and responding to modeling breakthroughs

Joy of Agility

This book uses lots of short chapters to show real-world examples of agility.

Each chapter highlights a different aspect of agility, whether that’s:

• Making sure there’s slack time in the work system
• Reducing wait times
• Removing fear in the workplace.

This contrasts with prescriptive books on Lean and Agile, as it instead provides small, easily relatable moments.

You’ll find parts familiar if well-versed with the Agile back catalog, but you’re sure to find something new as there are so many examples to draw from. Even the more recognizable chapters offer neat mental models you can use to share knowledge.