I got this book, War and Peace and IT by Mark Schwartz for $0 at Amazon.com. I think IT Revolution was holding some promotions which is how I got it for free back then so I was spared from shelling out $12.99. I bought it last May, but didn’t come around to actually opening it until this June.
We had a rocky start. The author pretending to be Napoleon Bonaparte in the Foreword section was something I found a bit too corny for my taste. So that made me put off reading it for a few more days or so. When I eventually reopened the book, I reached the section in the introduction sharing who the book is for.
- non-IT CXO
- CIO or IT leader
- Any category of business leader
And finally me: “For others in the business and IT community”
So mmmkay, I’m definitely not the main audience for this. I read it anyways. And it actually wasn’t so bad after I got over those hurdles. What I particularly like is that there’s a chapter summarizing suggested actions. So if you’re looking for one chapter to read in the whole book, go for Chapter 10: “Action Plan”.
I’ve listed out some bullet points from Chapter 10 below. For the full context though, you’ll still need to read the book. But at least this can give a starting point on whether you find the suggestions interesting enough to push through with checking out the $12.99 book.
Tie IT initiatives to business outcomes.
- Choose a few objectives for trial.
- Assign each to a cross-functional business/IT team that is fully empowered to execute.
- Use impact mapping to brainstorm with the team.
- Remove impediments.
- Review progress often and make adjustments.
- Celebrate success.
Shorten lead times.
- Emphasize urgency and fast delivery.
- Your goal is not to make people work faster or harder, but to improve workflow. Make that clear.
- Take advantage of the cloud.
- Ask IT to speed up the portion of delivery that is technical. This will probably involve implementing DevOps, creating reusable components, and designing secure “landing zones” in which new work can safely be done.
- Find bureaucracy that isn’t adding value or that could be made leaner with Occam’s turkey carver. Often this includes sign-offs required from people who have no good basis for making the sign-off decision, forms that ask for unnecessary information, or controls that could be automated.
- Becoming lean means reducing calendar time. Wait time, for example, should be eliminated, even though no effort is being spent.
- Task switching is a source of waste and defects. Organize work so that everyone can focus. You can make this easier by keeping tasks small so they can be finished quickly.
Emphasize delivery and results.
- Ensure that work is organized into very small units, work toward minimum viable products, and experiment to learn and test ideas.
- Monitor results starting immediately.
- Remove organizational impediments that resist quick shipping.
- It may be easier to begin “working small” by modifying an existing system.
- “Shipping” means that people start using the product. Prototypes and demos aren’t shipping (although they might be valuable steps on the way).
- Don’t be afraid of disruption from shipping quickly. The idea is that by shipping quickly and frequently, each shipment is very small, and is consequently low-risk.
Treat requirements as hypotheses.
- Read the Side Glance on humility! [this is another chapter in the book]
- Question assumptions by asking how they can be tested.
- It’s better to put effort into testing an idea than to risk not testing it.
- A/B testing (where some users are shown version A, some version B, then the results are compared) is very effective and might be easy to set up.
- Be sure that the test subjects are the same people who will be using the product—not, for example, managers or people within the product team.