What if your software development team's job was to make your business more money? And, what if, by doing so, they started truly enjoying their work once again?
Rolling Rocks Downhill, a business novel in the tradition of Eli Goldratt's "The Goal", introduces Cash-Flow-Driven Development - the combination of Lean, Agile and Theory of Constraints thinking to software development.
Would your business make more money if you shipped more software projects, faster? Do you projects almost always run late? Do you spend weeks or months fixing bugs before you ship your product? Do your customers still find bugs once they start using it? Do your developers and testers work in silos? Are they happy? Are they at war? How bumpy is your cash-flow? Do you envy your competitors' speed and flexibility?
Does life ever feel like you are pushing big rocks up hill?
Why work against gravity when you can so easily harness it and roll rocks downhill instead?
---
This is the high-quality late-BETA version of RRD - nearer to a gmail-style beta than a traditional beta. It's a rough cut - unpolished and missing features but readable and very, very useful. You will learn stuff. And, hopefully, so will I from your feedback.
If the idea of reading a book with spelling mistaeks (did you see what I did just there?) turns your stomach ... then please wait until the final version is out next year.
Thank you, Clarke Ching Watt's Bridge, Scotland.
* Visit rollingrocksdownhill.com to read the book's first 8 chapters free. You can also sign-up to receive the remainder of the book by email, one chapter per week, for free, over the following year.
A very fun read, that does a better job explaining agile and the way we can implement it than a lot non-fiction books on the topic. A definite must-read for anyone working with an agile team, especially if they're not part of the development process. Not going to give away anything from the book because honestly you just have to read it.
Oh and it's very well written as well, which makes it well worth the time invested, even for people familiar with the subject matter.
Excellent “textbook” teaching you a lot about (agile) project management and software development without ever mentioning word agile and written as a novel rather than a school textbook. More of these please!
This is a great engaging story that teaches anyone in the software business some valueable things.
For me, except the great writing, this stands out; - cutting scope is the best way to meet deadlines. Period. - look for the bottleneck before optimizing the system. Or you might only be making the value chain heavier. - focus on flow of finished features
This is a great business novel. OK, the genre is very specific. I loved it. I knew the theory of constraints through the Goal and Critical Chain but this is a revised modern approach that sounds so real. It got me thinking as it is meant to be !!!
Firstly, I don't understand how his analyst leaving for the competitor and sharing everything can actually happen. Didn't she sign an NDA, or any kind of other contract that permitted her to do that. This book is about how to handle the problem if it happens, but not about how to not have the problem happen at all. An NDA could've fixed everything.
Secondly, I really dislike how everyone handled it once it occurred. If a competitor's product ends up launching around the same time as me, I would try a lot more things before saying "everyone does overtime and holidays get cancelled". Was there even a conversation regarding acquisition between the competitor? Besides, working overtime for 6 months in a team of lets say 40 people will be the same as not working overtime at all. This is because half the people will quit, and the 20 which will remain will be too burned out. So actually, if they didn't work overtime at all, they would have still worked as much, only now you don't have to spend months onboarding new team members to replace the one that you've lost. I just felt like the "bosses" were college kids who have just graduated and have never had a job in their life before. These are supposed to be 50 year old people with 25 years worth of experience that are making these terrible decisions.
Thirdly, if I am a customer and I see 2 products, one that came out lets say 2 months ago and one that came out now, I would use the one that's better, not the one that came out first. Meaning, I would first use the first product because I have no choice, since there isn't a replacement, but once a far more superior product comes, because it actually didn't rush everything and took its time, I would switch onto that one. So, basically, in my head, they rushed for nothing. They slashed about 70% of the features they wanted to deliver because they wanted to beat the competition, and in the end came up with the bare minimum of the product.
Also, I feel like the main guy whose POV we were reading did absolutely nothing. There was a consultant who was hired by the CEO to assist him and tell him how to do his job. The main guy listened to what the consultant told him and did every single thing. He didn't think of anything new, he only followed the instructions he was given by a paid third party. And not only that, but he had the audacity to think that he actually invented delivering things in smaller batches.
This entire review has been hidden because of spoilers.
Solid IT management book wrapped around an engaging story
This book about software development joins the Phoenix Project, which is about IT operations, as key readings for all IT managers and all business leaders whose success depends on effective IT. This book consciously adapts Goldratt's "The Goal" for an IT setting. Where it has particular value for me is in clarifying how to use Goldratt's rather mystic "thinking cloud" concept, and Ching's use of a pro-con approach to really get at the choices. That insight alone is worth far more than the price of the book. Plus it is a fun read!
I loved this book. It was the first business novel I have read and I appreciated the concepts taught throughout it. Reminded me a great deal of what I studied in school so that made me a bit nostalgic as well. I loved seeing the way that problems could be solved and what went into each decision. It was simple and concise when it came to the concepts so even someone unfamiliar with the manufacturing and process ideas could keep up
Well written, easy to read. There are some similarities with The Phoenix Project, the concept of the project itself, Phoenix / FFP, the “spiritual guide” - Erik Reid / Craig Lally, Theory of Constraints, but apart from that, it is a totally different story. The story is very realistic. For anyone who has worked on a mid to large software project, the whole thing will be very familiar.
Entertaining. Makes the case for agile development methods without being too preachy. Might be worth giving to someone who is skeptical of anything but the waterfall, but more as a conversation starter than a definitive argument for agile because that’s not what the book is.
Good book. Realistic; conforms to actual software development problems. Less TOC than I expected, and also less Agile than I expected. But the story moves along (I read it one evening), and left me with some valuable thinking to do.
I really enjoyed the story line about turning a project around using Agile & TOC together! I am a true believer in using TOC with Lean and 6 Sigma but I didn't know much about Agile to know how they would fit.
The book doesn't go into a lot of detail about the details of Agile or TOC but much like the Goal it makes you go out and think how the problem could be solved. What I enjoyed most was the coach, didn't tell our protagonist what to do. Stories like this really help enforce how a coach is supposed to act. He listened - He asked questions - He let our manager think and discover on his own.
I listened to the audiobook and was quite pleased with the content of both the story, it was entertaining, and the power of the learning, it was educational. I found myself staying in the car for a few minutes when I got to my destination to hear the end of the chapter. The chapters are short (< 15 minutes if you are listening) but packed with inspiration. In the spirit of Dr Goldratt, Mr. Ching leaves the ending open for sequal.
I have read many of Dr. Goldratt's novels and I think would be proud of Rolling Rocks Downhill.
I read this book because it was presented to me as an updated and easier to read version of "The Goal". I can relate a big part of it with "The phoenix Project" which is more comprehensive, but admittedly a longer read. The Phoenix Project includes concepts from devops and lean manufacturing.
Back to the review: It was funny to see that all the problems Steve had were solved at the managerial level and the culture change was so easy and straightforward (basically everyone started working in "the new way" immediately and there were no problems there). There were a couple of arguments here and there, but all the stakeholders were more than happy to listen to Steve's orders. I wonder if it is the same in reality. But it's a novel and the author wanted to explain the principles behind "The goal" and that purpose was definitely achieved. It became very clear to me how every process can be improved by breaking it down into parts and looking for the bottlenecks. This was a major takeaway for me.
To sum up, the book is easy to read, ITers will relate to it easily and it explains well the bottleneck theory. But don't expect to get a lot more than that.
This entire review has been hidden because of spoilers.
I would recommend this book to anyone who’s looking for complimentary reading to The Phoenix Project, specifically anyone looking for a more Development Manager view of things.
There are some great analogies - the story about soup for me is one of the best metaphors for low risk releases that I’ve come across and I’ll never forget The French Fry Revolution!
As an added bonus I even laughed in a couple of places... dude. The dude, in case you were wondering, was ironic!
Clarke Ching's "Rolling Rocks Downhill" is a great business novel, primarily about TOC and Agile. I like how it combines a number of perspectives and shows how real value can be obtained in surprisingly short time horizons. That said, it helps when there is outside pressure.
I am fond of using analogies to explain things. What struck me most about what Clarke has done here is wrap up a powerful idea in an accessible, engaging story with lots of insight on offer. I will be recommending it to colleagues and of course I loved the cafeteria analogy ☺
Lot's of good advice packed in an interesting business story. I xould easily recognize the problems the characters are faxing, despite having worked in small companies most of my carreer. Recommended.