For me, this was a "Casablanca" book. By that, I mean it reminded me of my experience watching the movie "Casablaca." I kept thinking Big deal, I've seen all this before. But of course, that's because the ideas of this book have percolated far throughout the nerdsphere since this book appeared. You know how Extreme Programmers plan their software releases by moving around index cards? This is the book that taught the world how to plan software development cycles by pushing around index cards.
But I learned things from this book. I found out I was wrong about some Extreme Programming methodology. I knew that Extreme Programmers planned which features to put in a release by writing features down on index cards and moving them around. But I wrongly thought that each index card represented about the same amount of time. It turns out that one card can have the 1-hour "check for cosmic ray corruption and throw a fit" task or the 1-week "set up watchdog timer monitoring on global fleet" task.
I guess I wasn't the only one who thought that "area of index cards" should somehow correspond to "size of effort". The book mentions a team that used different sizes of index cards for different-sized tasks.
The book also mentions a partner complaining that this planning process was an excuse to take out features. To me, it sounds like an organization that had used fake plans before. That is, everyone agreed to a schedule, but nobody really thought that the schedule was real. The very idea that the engineers would, instead of saying "Oh, hey, it's June 28th and we just realized we're not going to be ready in July after all; can we do August?" would be replaced with "Happy Groundhog Day. We sketched out the schedule ahead of time and by July, not all the features can be ready; which should we drop?" Like, the organization was willing to make priority decisions, but only in the face of an imminent crisis.
Back when I worked at phone software companies, we had schedules. We tried to stay in sync with phone product cycles. Get the software ready for the manufacturers in time so that that the manufacturers can make phones in time so that people can buy the phones as Christmas gifts. Nowadays, I document infrastructure-y stuff deep within a web services company, nothing that gets announced to the outside world. If something isn't ready quite on time, that's probably OK; probably not many people knew what day "on time" was supposed to mean.
This book reminded me of software scheduling. Wow, I really don't miss those days.
