Book Thoughts 1
Joy of Agility
15 May 2023
So I recently took up a larger reading and re-reading project, to help better organize my own thoughts, and engage with the broader conversation regarding software collaboration. Basically, I want to get better at drawing parallels between my own line-of-thinking and what others think or are doing these days.
With that in mind, I picked up a copy of Joshua Kerievsky’s Joy of Agility. Let’s rap about it!
First, this is a really easy-reading book. Its organized into a series of true business stories, each of which illustrates an aspect of a principle. The stories go quickly, and are pretty compelling for the most part. A number of them come from the world of Agile coaching in larger enterprises, which makes sense given the author’s background, but I found myself wishing that a few more of those stories connected to smaller companies. That’s not really a complaint, so much as a worry that some of this literature is a bit too focused on the world of large org charts and middle management.
Also, I’ve described Joy of Agility as a “book of books” to a few people I’ve chatted with about it - many of the sections generously reference other material worth picking up and reading. Given my current project… that’s useful! I’ve picked up a few books mentioned in here, and I’ll probably pick up a few more before my reading project is over.
Alright, that’s the overview. Here are some scattered thoughts related to content!
There’s an excellent story about making a customer experience “magical” - the lesson being that making intense personalization fast and easy creates a relationship with your customer that is hard to beat. That resonated with me and other lessons I’ve picked up from recent product work.
The author talks about how many organizations adopt a “strict Scrum” gloss on top of working the same way they always have. The author laments this, and I get it. Personally, I also sympathize with the teams in this situation, as I’ve met a few teams over the years that do this as an act of defense to survive middle-and-upper management administration changes. That’s a far cry from saying that this response is good! The author calls this “activity without achievement” - making changes without affecting the outcome. Its a big part of why so many people in the broader agile community have a “retch” response to the term “scrum”. Its not because it can’t be done well, but the version most people think of is a little debased.
Another section discusses the adversarial relationship many delivery teams have with their product owners. The author cautions the people in the product owner role to enlist the rest of their team in the product decision-making process. Its good advice! In my experience, I’ve run into this problem much less than the absentee-product-owner issue - when the nominal owner makes no decisions, and forces the team to make them on their behalf - so my thoughts are along the lines of “if only product owners seized their role a little more jealously!”. But, that said, I think its phenomenal advice for anyone in an executive role. Yes, you need to be in charge of the final decision! This is good. But to make the best decisions, you have to solicit information from your team. Picture Captain Picard asking members of his bridge crew for recommendations. He may not use all the recommendations, but pulling people into the conversation both give the leader better information, and also helps the team practice executive thinking - the practice of weighing tradeoffs and making a choice. The best product owners do this intuitively, without dithering or wasting time. Its good stuff.
The book has a ton of content related to management and “driving out fear”. It’s all excellent. To put my own spin on it, I’d sum it up as:
Software development is creative work, and creativity thrives on a sense of safety, and withers in a climate of fear. Therefore, the best management of these teams works to drive out fear, so that creativity can be maximized.
Obviously, this prioritizes the creativity of the team over other management concerns, such as cost. This is clearly the correct choice for teams that need agility to find the best solutions for the customer, so the challenge for management is to remember that these other valid concerns are secondary. Product is king, and creativity drives the best product. Therefore, above all: drive out fear.
The book draws the analogy between a software team-room and a writers room. Not in the sense of recent events - I hope the outcome of the recent writer’s strike meets the needs of all parties - but in the sense of both scenarios being creative-group-collaborations. I approve of this association so much that I’ve used it myself many times in the past! These things are profoundly similar, and I’ll pile on a third for the moment - a team-room is also like a jazz jam session. As long as you get a handle on some of the standards, you can join in, and play, and add some personal texture to a community creation.
A quick paraphrase from my notes - “the hard work is thinking and designing, not typing the code”. I can’t emphasize this enough. I’ve met so many people, so many people over the years that mistake raw APM (keyboard actions-per-minute) for productivity, and design every team optimization around this. Compounding this further, these people frequently end up… missing massive, low-hanging-fruit optimizations by hyper-focusing on using specific tools. They tend to fail at even being the fastest APM on account of this. Choosing the wrong game, and then still losing at it.
If you’re going to optimize your team, optimize for collaboration, feedback, and correction. That’s the work. Once you know what you want to code, you’ll naturally try to accelerate that process. Why? Because its busy-work, getting in between you and the real work. And if you have a partner to bounce ideas-off-of, you can usually find an order-of-magnitude optimization faster.
A chapter focuses on distinguishing “safety” from “playing it safe”. This is good, as the general conversation around “safety” gets pretty muddled, and this is a real concern. My takeaway was basically “team safety means people can experiment in the team-space freely”, which is different than “no one is challenged in the team-space, ever”. In fact, part of confirming your team-space is safe, is asking yourself how often constructive-conflict happens.
“Playing it safe” on the other hand, is a negative. Your product should balance incremental small improvements with audacious plays. Obviously, the best audacious plays are tempered with rapid feedback. Taking risks is an important part of product development, and one should be concerned if there aren’t any risks being taken. Otherwise… what do you need all this agility for anyway?
The book included a section on “Satir’s change model” - a pretty solid structure for understanding the integration of changes. I dig it.
I have two more notes related to the book that will always be relevant. The first is… if you want to become significantly better at something, be prepared to get worse while you learn better technique. The “tennis” story that delivered this lesson is delightfully illustrative. The second?
Making problems visible lets others help with the problem.
That’s my painful paraphrase, but its a deeply important observation. So much of the value of Agile principles and derivative processes boils down to “let group knowledge have a shot at the problem”. Leaders, executives, management, and loudmouths tend to forget this, preferring to “shield” the team from distractions. In practice though… this leaves us alone with these tough problems, when we need help the most.
So lets make those problems visible - with care - and see how we can solve it together.
I’ll happily recommend Joy of Agility. It moves fast, has some wonderful stories, and will give you some principles to chew on for yourself.
Image generated by Bing Image Creator, from the prompt ‘medium image for a book review of “Joy of Agility”’.