Over the years we have explored a wide range of books on Saturdays. Sometimes our re-reads reflect the real world outside software development. For example, in 2018 we re-read Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou, the story of Theranos and Elizabeth Anne Holmes. This year Ms. Holmes went to prison. While I don’t expect prison sentences for the subjects in the books we read in 2022, I expect the knowledge in the books we tackled to have a broader impact on the world.
In the past year, we have re-read 3.4 books – 40% is the progress on the current book according to Kindle. Links to all of the read entries can be found in the show notes.
This week we also have a visit from Susan Parente and her Not A Scrumdamentalist column. Susan and I discussed how a newly minted Scrum Master can get up to speed quickly.
A funny thing happened on the way to the essay this week. I was distracted by feedback from a colleague on a workshop Jeremy Willets and I developed and delivered this week. We discuss why the phrase work entry describes how work gets to teams and organizations, and why “work intake” masks problems in the real world.
We also have a visit from Susan Parente and her Not A Scrumdamentalist column. This month Susan answers a listener’s question about whether it makes sense for a Scrum Master to also play other roles on a team.
Do you have questions that you would like Susan, Jon, Jeremy, Tony, or myself to answer? Leave a voice message at 01.440.668.5717 or an email at spamcastinfo@gmail.com.
This week we make a quick side trip. Earlier this week I was asked why I “did” the Re-read Saturday column. Today, I offer a short explanation and highlight the experiments I am running as part of our re-read of Coaching Agile Teams by Lyssa Adkins.
We also have a visit from Jon M. Quigley. In this installment of his Alpha and Omega of Product Development, Jon and I discuss the role of the team lead in agile teams that have coaches, scrum masters, and just might be self-organizing. There is a role but it is not the classic version that is in common use.
Why Do I “Do” Re-read Saturday.
Re-read Saturday is a long-running column featured on my blog (tcagley.wordpress.com) and at tomcagley.com. The books selected for the column are nominated and then voted on by readers. Because most books are selected by the acclaim from readers of the blog, the re-read is sometimes actually the first read for me. During the re-read we read, discuss, and highlight concepts chapter by chapter.
There are three major reasons for the column. One, the column draws eyes. A blog without readers is a diary. Over the years, many of the top 10 annual posts have been from the re-read feature. A second reason, and perhaps the original reason was that I had not read some of these books before and really needed to read them. For some of the other books we have re-read, the re-read drove home the point that memory erodes over time. For example, I am embarrassed to say I had forgotten the story of Herby (check out the re-read of The Goal). Reason two is that the re-read is a forcing function to guide behavior. The books we read and re-read help shape how we behave. The third reason is that the column generates a lot of interaction. I have heard from readers and authors with ideas and opinions. The interactions have certainly improved my understanding of how work is done and how to improve. The level of interaction suggests that the readers get similar benefits.
Recently, I decided to run weekly experiments based on the chapter I am reading. The weekly experiment is another forcing function. Doing the activity drives home a point so it is harder to forget. For example from the re-read of Chapter 2 of Coaching Agile Teams by Lyssa Adkins titled Expect High Performance I am focusing on using metaphors to guide behaviors. As an experiment, I am establishing a metaphor for myself. The goal is to see whether having a metaphor changes my behavior. The concept of the weekly experiment might end up being the best reason for me to “do” Re-read Saturday and perhaps the best reason for you, the reader, to participate.
PS — I am not convinced that the person that asked was really looking for this much information. I actually think they we asking why read books at all when you watch videos which lead us to a different discussion which I will share another day.
Finally, have you downloaded the book referenced in last week’s interview? Check out Seeing Money Clearly at www.agileagonist.com
Re-read Saturday News
This week, Chapter 2 of Coaching Agile Teams by Lyssa Adkins (SPaMCAST Amazon affiliate line https://amzn.to/38G0ZD3 – buy a copy). The chapter’s title is Expect High Performance. As a coach, you need to have high expectations of yourself and those you are coaching.
In the SPaMCAST 705 we stay with the basics and define the term flow. I recently listened to a conversation where the term flow was used 30ish times in 30 minutes. Each use of the term meant something different. Today we draw a line in the sand to improve communication.
We also have a visit from Jeremy Berriault from the QA Corner. Jeremy and I discussed the mistaken belief that Scrum Master and Coach can be translated to administrative assistant.
I deviated from the plan this week and recorded a conversation with my colleague, mentor, and friend Anthony Mersino (Anthony was last on the podcast SPaMCAST 583 http://bit.ly/3aJMw51 ). Our chat, titled, “Is Your Scrum Master The Problem?” Our conversation looks at transactive memory from the point of view of teams and Scrum Masters. Is it a boon or a train wreck? Anthony has also published a version of the conversation at https://bit.ly/3ux0Fge
We also have a visit from Susan Parente who brings her I’m Not A Scrumdamentalist column to the cast. I have titled this conversation, “I Have A WIP Problem”. Ok so maybe both Susan and I have a lot on our plates, but we have the tools to tackle the problem. We talk about how to get your WIP under control.
We have read or re-read Fixing Your Scrum: Practical Solutions to Common Scrum Problems by Todd Miller and Ryan Ripley cover-to-cover, if you don’t count the index at the back of the book (and I certainly do not). As a wrap-up, I want to briefly consider three points.
Chapter 15 is the final chapter in Fixing Your Scrum by Todd Miller and Ryan Ripley. Next week I will sum up my thoughts on the book and the lessons I have derived during the re-read. We will also announce the next book in the Re-read Saturday series. Right now Monotasking by Staffan Nöteberg is in first place in our poll. Make sure to make your voice heard; vote now below.
I have heard the sprint review called everything including a demo, demo day, show and tell and sprint review. If teams and organizations do the sprint review well, I don’t care if you call it jello. Scrum defines the sprint review as a mechanism for the team to inspect what has gone on during the sprint and what was delivered in the increment with all involved stakeholders. The event is collaborative with stakeholders to generate acceptance and feedback. It is also a critical path for change management and decision-making. Sprint reviews are a powerful tool for the team and organization to ensure that what is being built, assembled, and/or configured delivers value.
Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. This week we talk about five common patterns. On Tuesday I will include the PDF in the feed to see if I can spur a discussion about other patterns.
At the end of every sprint, a team should have a deployable product increment. There are a ton of ideas packed into that single phrase. In this chapter, Mr. Ripley and Miller focus on the concepts of deployable and done. Anyone that has more than an academic knowledge of Scrum knows all the reasons and rationalizations for why having a deployable product increment doesn’t always happen. What is worse, many practitioners believe having something deployable is beyond the realm of possibility in their environment. This is almost always a fallacy.
Software Process and Measurement 