I’ve managed projects and programs for over forty years. I’ve seen the effects of both good and bad systems on the people who try to do their best work. These books help managers and teams see their systems. How long does a team need to deliver work that fulfills a good objective? Are there systemic blockages that prevent people from doing a good job? These books represent my philosophy: People want to do a good job. When they have clear objectives and know the principles of flow, they can succeed. That’s how I’ve succeeded in my career. You can, too.
I wrote...
Agile and Lean Program Management: Scaling Collaboration Across the Organization
When I read the very first page, I had an “aha!” moment. Singh explains that scaling flow, the flow of work through the teams, is the single most important idea in “scaling” agility. That means each team optimizes for their challenges, not a specific process.
I loved this book because Singh makes the principles of flow easy to understand and apply. That’s the “secret” to scaling agility.
If you are a large organization that has seen the benefits of Agile approaches on teams, you have either attempted to or talked about scaling Agile. Scaling has become synonymous with overburdened and cumbersome frameworks that create more problems than they solve. We need a simpler solution to the problem of scaling Agile. We need to break this problem down to its basic tenet - Optimizing the flow of value to customers. The strategy of Kanban can be applied to do exactly that. In doing so, we can discard the practices proposed by common Agile scaling frameworks and go to…
I used to wonder why I “always” chose the wrong line—at the gas pump, the grocery store, and airport security. Then, I read this book and learned about Little’s Law. That changed how I saw the world. Instead of always looking for the shortest line, I learned to look for the line with the fastest throughput.
Seeing the world differently matters even more if we want effective product development—especially when the problem requires multiple teams to collaborate. The more collaboration we need across teams, as in a program of work, the more we need to look for throughput.
Read this book, and you, too, will see the world differently.
“When will it be done?” That is probably the first question your customers ask you once you start working on something for them. Think about how many times you have been asked that question. How many times have you ever actually been right? We can debate all we want whether this is a fair question to ask given the tremendous amount of uncertainty in knowledge work, but the truth of the matter is that our customers are going to inquire about completion time whether we like it or not. Which means we need to come up with an accurate way…
I love goals that tell me where the product needs to go now and help me see the big, audacious goal at the end. While many other OKR books focus on the now, Kelly’s book also helps me see that end goal.
Kelly’s approach to OKRs supports larger efforts, such as programs, with this pragmatic idea: “Bigger team, fewer OKRs.” Why fewer? Because that focuses all the teams on one big goal at a time. The more we consider flow and Little’s Law, the more we realize one goal is the right number for an agile program.
Get aligned, work seamlessly and hit goals efficiently - what are you waiting for?
“This book is full of great insights and guidance around OKRs backed by multiple real examples that will be helpful in a number of domains" Nicolas Brown, Agile Coach
OKRs are about goals bigger than the next story, or even epic. They prioritise purpose and strategy over the ever looming, high maintenance backlogs we all know too well.
OKRs are important to agile teams because they deal with the big things, they inspire forward thinking, encourage engage senior leaders, and help debug strategy.
I read the first edition of this book when I was in college after a disastrous “team” project. (We weren’t a team—and we didn’t finish the project.) I was just about ready to quit Computer Science. Then I read this book.
Programming—and all product development—is a human activity. How do people learn to work together, to collaborate, to create teams, and to release useful work? Those are the topics in this book. From egoless programming to personalities such as the Mad Bomber, Weinberg addresses how we could collaborate, from small efforts to large.
Every time I read (or re-read) a Weinberg book, I learn a little more. I bet you will, too.
This landmark 1971 classic is reprinted with a new preface, chapter-by-chapter commentary, and straight-from-the-heart observations on topics that affect the professional life of programmers.
Long regarded as one of the first books to pioneer a people-oriented approach to computing, The Psychology of Computer Programming endures as a penetrating analysis of the intelligence, skill, teamwork, and problem-solving power of the computer programmer.
Finding the chapters strikingly relevant to today's issues in programming, Gerald M. Weinberg adds new insights and highlights the similarities and differences between now and then. Using a conversational style that invites the reader to join him, Weinberg reunites…
While I always knew there was something else that reflected true organizational efficiency, I didn’t know what it was until I read this book. This book introduced me to the idea of “flow efficiency,” instead of “resource efficiency.”
Too often, managers think the world is more efficient if they slice the work and create handoffs from one expert to the next. But that creates delays and waste in the system. Worse, when we try to “scale” efforts, all those handoffs get larger and larger. Read this book to start seeing the world differently and consider what you can do to create real efficiency in your organization.
If you’re trying to use agile and lean for complex products with programs, you’ve heard of several approaches, all about scaling processes. However, since every team has different challenges, the same agile approach doesn’t scale for the rest of the teams. That leads to bloat, not delivery. Instead of scaling the process, scale everyone's collaboration.
With autonomy, collaboration, and exploration, teams and program-level people can decide how to apply agile and lean thinking to their work. Agile and lean program management creates an environment of servant leadership and small-world networks. Learn to enable autonomy, collaboration, and exploration across the organization and deliver your product.
