Got a recommendation to read Nature by Ron Jeffries and I did. What a read! I loved it from the get go.
My short review is quite simply;
“This book made me think. It left me with more questions than I had going in. But better more concrete questions. Seeking simple(r) answers. Also it’s sprinkled with challenges and gentle provocations of the current state of mind and process.
The underlying principle ‘Simplify it’ is something that resonate very deeply with me. I recommend anyone doing, struggling to do or thinking about doing this thing we call ‘agile’ to read this book.
And then give a copy to every important person in your organization.
Thank you for a great read!”
I’ve been following Ron Jeffries (not only on twitter, but that’s a good start) for a long time, not only on twitter. The first thing I read from him was actually a take on the bowling ball kata. I’m happy I did follow him although it can be quite challenging from time to time. He has a way of putting things that is challenging and sometimes provoking.
This book is not exactly like luckily, I think that would have been tiring. But as he writes:
[This is] not a book of recipes. It's not about one way to do something. That's not our purpose here. We're here to think about how things work, to ready ourselves for whatever may happen. There are many ways to accomplish what you need. I trust you to find ways, think of ways, and select among them.
This books always brings our minds back to simple things. Simple as in “not complex”, but maybe very hard to do or get done. Here’s a few highlights;
- Show coded, tested, deployed, finished, valuable software features at end of short iterations
- Build feature by feature rather than in phases
- Have a self-organized, cross functional team organized by feature that is given intent / purpose by a product “champion”
- Organize and plan by feature
- and many others that you’ll find in the book
If you’ve read anything about agile this should all sound familiar to you. And of course it is. It’s simple. To say. Proven very very hard to do. Especially in companies that does software development in another way today.
Because agile, when done right, will transform everything in your company. And that’s why it’s seldom done right. For me at least, most companies I’ve visited are not prepared to do that. I wished I have had this book to give them before I started to do any work there.
I could write comment, praise and thoughts that popped into my head, about almost every single page in the book - but that would defeat the purpose of a book that is written to make you think.
Instead I’ll wrap this review up with one of those thoughts.
An example: scaling agile
At the end of the book Mr Jeffries gives some thoughts on scaling agile. He’s basic argument is that if we can get a single team to “do agile properly” then scaling might not be needed (for that one product). One team, work in a fluent agile way, would probably be enough.
I tend to agree with that thought, but in many organizations I’ve been working in there’s a structure in place already, not around product but rather around specialties and … “how we used to do”.
Now, this chapter gave me a thought that I’d think would hold up for at least the organizations I’ve been in.
If we can get a single team to work in a fluent agile way - then getting more teams doing the same is a piece of cake
That first team would pave the way, challenge the organization, challenge our preconceptions and current ideas, change the infrastructure etc. etc. and etc. Once that works for a single team - then getting another to follow is EASY.
So what is “fluent agile” then? According to Mr Jeffries (and I agree 100% to all of these):
- It’s simple or it’s not agile
- Teams work according to the principles of the agile manifesto
- Daily with their business stake holders
- Deliver working software often (every other week at tops)
- Progress is measure in working software
- Continuously works of technical debt to be able to move faster
- and more great stuff
- that you can
- read in the principles
- of the agile manifesto
- Can keep a consistent pace and quality sustainable over a period of time
Well… if we can get one team to do that then the next team will be easy. We have changed a lot about how you work in order to get that to work. Or we have not done it properly.
But that is also showing the intent and principle of agile in general and this book specifically; get something simple to work first and then do the next simple thing until all the simple things makes up what you need. Maybe what you needed was not complex after all.
Summary
Get this book. Read it. Think. Share your thoughts. Change the way you work today. Yes I said: “Improve how you work today”. In small, simple steps.
I could not give warmer recommendations to a book. Loved it!
Thank you Ron!