If you’ve read much of Gene Kim’s work you’ve heard of the transformation that HP Printers made to their firmware development process. Kim cites it so frequently because it is an example of one of the oldest software development groups around making software that’s some of the hardest software to test (printer emulators anyone?) transforming from a waterfall development process to an agile one. Gruver and Mouser are the executives behind that transformation and this book is full of great lessons that everyone who’s had an IT department for longer than Amazon’s been a bookstore can learn from.
Let me give you three of my favorite things about this book, and I encourage you to read it and come up with your own:
- In the very first chapter they talk about how many companies make the mistake of trying to start an enterprise agile transformation by just having one team transform. It doesn’t work because, at least in most companies, a meaningful development team can’t go to production on its own. You have that one transformed team running scrums and using whiteboards full of sticky notes to deliver code to an integration test environment where it will sit for 6 months. The key is to find ways to iteratively improve the whole organization (or at least ALL the parts that have to develop together) towards agile.
- Having worked in technology all my life, I had never really considered why software development should be managed so much differently then your other cost centers. I really liked their point that what makes software development so hard to plan for is that it’s hard to see and often changes from looking 80% done to looking destined for the trash heap overnight. That ever-changing aspect is also what’s great about software. It’s hard to predict where you’ll be in 6 months in a software dev project, but it’s much much easier to change your mind today about where you want to be tomorrow. Doing agile software development makes so much sense because it’s just using the inherent strengths of software rather than trying to mold it in to a waterfall techniques.
- Finally, this book isn’t afraid to make the tough point that executive teams must understand technical concepts like continuous delivery to be successful. They can’t just be great people managers or inspirational leaders. They have to know when to make exceptions to the “no branches” rule and when to require automated tests. These are things that reasonable development managers can disagree on, but a knowledgeable executive must set a standard for.