"All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer." We call it Software Teaming, also known as Mob Programming. With large monitors, one computer, one keyboard, and a very collaborative approach, we use this method to supercharge our development efforts and deliver high-value software quickly.
In this book, we share our "Software Teaming" style. We cover the techniques we use in our daily work, how we discovered this way of working, the benefits we see from Software Teaming, and the problems we've overcome. We also show how you can incorporate some of our ideas even if you don't have a way to adopt Software Teaming full-time.
In this second edition, we include new material on teams, the power of flow, remote Software Teaming, and more.
This book is by far one of my most favourite programming books.
It is not just its contents but also the way the author chose to write the book. He proposes ideas and leaves it up to us what we will do with it. While I believe that the practices and the principles described in this book are highly valuable, he communicates them with a huge amount of humility which makes it very nice to read.
Software Teaming is about everybody working together at the same time in a Software Team. 'All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer" - We call it "Mob Programming'.
This goes beyond only working with developers and includes having Product Owners, Designers or whatever comes to your mind. The expected positives are something like better knowledge sharing, higher quality of work, reducing the amount of meetings and better and more effective communication.
While I was very skeptical that a practice of having 5 people work at one thing instead of 5 people working at 5 things, I am now curious and think it is worth the try. The book addressed common thoughts and concerns of this thought in an own chapter 'Won't this cost too much?'.
The book is about more than Software Teaming. It leads us to question what enhances the quality of our work and what reduces it. This is a good thing to think about. And maybe Software Teaming could provide ways to solve these problems and make our work more *effective*.
'It’s not about getting the most work out of each person. It’s about getting the best of everyone into everything we do.'
I may not be a dedicated fan of MP, but I have to appreciate this book as it truly does best to describe this technique (& mindset behind it) with minimum bias & maximum candor. It doesn't try to pretend MP is perfect, fits everyone, everywhere & always - no bullshit, just raw & honest description of own experiences with both bright sides & risks.
What is equally important - this discription is not restricted to shallow / idealistic observations of visible effects / obvious constraints. Frankly speaking author has covered almost all of my doubts / questions & remarks - "covered" doesn't mean "answered" or "fully clarified", but at least acknowledged & clearly indicated to others.
Cons? Few of them - editing has failed a bit in a beginning - some repetitions are truly annoying. Chapter about cost calculations is hard to follow - no tables, no pictures, just raw, unformatted text - looks almost like obfuscated.
But in general, it's a good starting point if you're interested in MP. Even if you're not going to try it, it's always good to broaden the palette of options available, isn't it?
It was really an unexpected surprise: I wanted to read it for a long time since I've been a big fan of pair programming and I suspect that mob might be "even better". I felt too lazy though to read it, until recently: we started as a new team doing mob during the first weeks, so I felt a special motivation to do it.
What I loved about this book is that it goes far beyond of the surface: since everything is connected, it touches all the different pieces that somehow affect and are affected by the level of collaboration when we work.
A special mention to the chapter with cost analysis (to take with a pinch of salt anyway) and the one with the personal experience of an introvert in the context of a continuous mob team.
The book was revolutionary for me! My favorite quote was, “for an idea to go from your head to the computer, it must flow through someone else’s hands.” Delta Air Lines is going to do their first Mob Programming pilot next week and this book as well as Woody Zuill, the author helped make it happen! Recommended to any development team that wants to improve their process.
I've been aware of Mob Programming concept and Woody Zuill's brilliant contributions in the community for a long time, but only now did I get to read his book Software Teaming (as he now prefers calling it).
Woody puts my thoughts and doubts into words, with powerful one-liners that are hard to disagree with, even if he says he can't prove 100% what he says :) The book includes too many useful quotes to mention them all here, but here comes a few:
💡 "Orchestras are structured deliberately to optimize the flow of the music, not the busyness of the individual musicians."
💡 "Most challenges in modern software environments are too complex for an individual, so we assign them to teams. Paradoxically, we then separate the team members and ask them to solve the problems individually. How can we be effective if we separate the people who should be working together?"
💡 "Software Teaming is not about getting the most work out of each person. It is about getting the best of everyone into everything we do."
I also like Woody's down-to-earth writing style, focusing on what has worked for his teams in practice, while sneaking in several lean and agile principles to back it all up (queues, inventory, flow vs. resource optimization, "maximizing the amount of work not done", etc.).
Even if you're not a programmer, you should still read this book if you work in a team doing any kind of collaborative work - including if you're a manager or leader helping these teams become effective.
An inspiring book, which makes us reconsider the ways we develop software and what "teams" really mean. Very inspirational, a lot of practical advice. The only reason I gave four stars (not five) - it is rather repetitive. The same concepts are repeated again and again, with a bit different flavour. If you have seen a talk by Woody, you probably won't get much new from the book. Still, you will get more details and a "paper reference" you can come back to.
The authors are careful to highlight that this way of working is not a perfect fit for every environment. They highlight the process of discovering teaming and try to encourage the creation of an environment that could foster similar innovations that fit their context. The ideas are solid, helpful, and encouraging, though there are questions left unanswered and a fair amount of repetition (IMO many of the unanswered questions amount to "you have bigger problems to work on first that are outside of the scope of this book", so it's fair that not everything I'd like answered gets addressed).