Book: A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware

Notes and thoughts on the book with one of the longest titles ever, so I'll refer to it as "HP Laserjet" from now on.

BY the time I got to read it, I had been aware of this book for a while as it's not exactly new. It never really attracted my attention as it focuses on systems that I was never involved with. This changed recently (past two years) and after purchasing Industrial Devops I made the connection to this book again due to a mention in a promotional post for Industrial Devops.

The TL;DR for this book is that it's worth a read: it reinforced some convictions I already had, and went a bit in more depth on others. In both the HP Laserjet book and Industrial Devops I felt the part about certifications was notably absent. Since that's usually an expensive, delicate part of physical products design, I am perplexed at the fact that it's not covered in more depth.

Another remark is that some aspects that are strongly highlighted in this itrevolution newsletter entry are not (IMHO) pushed as strongly or described clearly in the book. I felt instead as if hey were left for me to read in-between lines.
This is perhaps my biggest gripe with the book, as I certainly feel these two approaches (one code base without #ifdef, and the extensive use of emulators/simulators) are exactly the engineering ingredients that allowed the HP team to engineer a solution to their productivity problema, as opposed to hiring their way out of them. I find that not covering them in more details makes a disservice to the engineers first, and the book second.

Anyways, here are the parts of the book that I felt were worth highlighting and writing down so that I could better interiorize them.

Notes

Don't hire (spend) your way out of a problem, engineer a solution!

6 principles:
  1. KISS/reduce overhead or waste
  2. don't overfill your plate
  3. cater tot the bottleneck
  4. integrate early and often
  5. find your planning rythm (sprint length)
  6. practitioners should define agile/lean practices
Always demo code that has been fully integrated into trunk (if it's not into trunk, it's not done)

Don't manage by metrics, instead use them to have conversations

Simple, clear priorities:
  1. P1: drop everything
  2. P2: next sprint
  3. P3: whenever
Align with marketing/sales

When making changes, work to minimize the disadvantages. The advantages will be naturally delivered by the change anyways, but the disadvantages might kill the change.

Focus on developer productivity:
  1. common dev environment
  2. simulator
  3. common test framework
  4. best HW you can afford, i.e.: 30" display, headsets, fast computers, etc