The first principle of the Agile Manifesto is about “valuable software”. Value is subjective; it’s the perceived benefit we get from something.
Imagine you are working for an IT department in a large organization. You want to deliver valuable software with iterative delivery. There might be dozens of stakeholders with dozens of definition of value. How do you ensure you are both “building the right thing” and “building the thing right”? Suppose you are increasing your productivity, you might be building the wrong product faster.
This book describes how a large organization uses techniques to focus on the right product and to deeply anchor the idea that less output can deliver more outcomes.
Nicolas Gouy is an independent software consultant in enterprise-level adoption of agile principles and practices. He helps large companies (such as Michelin for their large-scale transition to agile) and startups (such as Catopsys for their innovative product development process involving optical, mechanical, software experts and digital artists).
As much as I like reading in general, I positively abhor being made to do it. It's probably the reason for my dislike of so many classical novels and poetry. What was the point of doing it, when in the end I would be forced-fed the ministry-approved interpretation?
Even though I was assigned this book as part of my work evaluation goals, Agile with Guts actually surprised me from the get-go with a very relatable phrase: "I’ve long held the belief that accurate fortunetelling is the single most important skill to look for when interviewing anyone involved in software delivery". Let me tell you, that to this day I break out in cold sweat when I get asked for a time estimate for most of my tasks; and I've been working as a computer programmer for several years now.
What I appreciated most was the understanding this book gave me regarding the agile workflow. For the longest time, being agile would mostly equal daily stand-ups to me: everyone would drone on about his/her task, until someone finally spoke up about "taking the rest of the monologue offline".
Dilbert's illustration of misunderstood daily stand-up meetings
After reading this book, I actually ended up feeling incredibly guilty for all the concepts that I've been holding on to with my teeth. Being agile means the possibility of having to contend with constant change. You worked for 3 months on this awfully complex feature? Though luck, Google just released a free alternative to it. Also, you should start getting conscious of that sense of urgency looming above you, or your next project will bite the dust as well.
Another excellent topic was the difference between "goal oriented" and "feature oriented" prioritization. As a developer, you might feel strongly about having a mobile-friendly version of your app, but customers might be more interested in the ability to delegate some of their work to a 3rd party (eg: delivery).
Score: 4.2 / 5 stars
There was a lot more that I found interesting, intriguing or even just guilt-inducing, but I still ended up rushing through this book in about 2 hours. I had my yearly evaluation the following day, and didn't really have a valid excuse for not having finished the book. And didn't my pride just swell when my boss remarked, that I had actually done the assigned reading?
I wouldn't necessarily say that this book has changed my professional life, but I will definitely have to read it again (more slowly) and take notes. Also the next time someone mentions instilling a sense of urgency in the team I will fight the urge to roll my eyes... too much. :P