SPaMCAST 793 – Value Streams Analysis, Work Intake, Who Can Be A Scrum Master, Essays and Conversations

As you would suspect, I have recently been talking up Mastering Work Intake which Jeremy Willets and I co-authored. One conversation turned to the topic of whether value stream analysis was useful in controlling work intake. The simple answer is YES across the whole value stream and up and down the hierarchy.

We will also have a visit from Kies Kostaqi who brings her “You Are Not Alone” column to the podcast. In this installment, we discuss whether anyone (within reason) can play the Scrum Master role. 

 

SPaMCAST 790 – It’s All About The People, A Conversation With Stefan Wolpers

SPaMCAST 790 features our interview with Stefan Wolpers. Stefan and I talked about the Scrum Master’s role in the 21st Century, his new book The Scrum Anti-Patterns Guide (buy a copy), and remembering that it’s all about people.

 

SPaMCAST 735 – Books We Re-read, An Inexperienced Scrum Master, Essays and Conversations

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.

Links to all entries in this year’s re-read can be found at  https://bit.ly/3I2pcCw 

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.

 

SPaMCAST 729 – Product Owners, Not The More The Merrier, Syncing Agile and Waterfall Requirements, Essays and Conversations

This week we go back to basics and answer a listener’s question (name and a bit of the context changed to protect the involved parties). In the essay this week we discuss why it is a rotten idea to have a functional product owner and a technical product owner. When it comes to product owners the old adage, “the more the merrier,” does not hold.

Also, we have an installment of Tony Timbol’s “To Tell A Story” column. In this installment, Tony discusses how to synchronize team-level agile with a waterfall requirements process. This is one of those scenarios that when you run into it you will need to find a way to deal with it until more of the organization embraces agile. 

Tony’s Website: http://bit.ly/3O4aAUv

 

SPaMCAST 705 – Flow, Agile Basics, Scrum Master Not Your Admin, Essays and Conversation

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. 

 

SPaMCAST 671 – Is Your Scrum Master The Problem, I Have A WIP Problem, Conversations with Anthony Mersino and Susan Parente

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. 

 

Re-Read Saturday, Fixing Your Scrum, Week 16, Final Thoughts

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.  

 

Re-Read Saturday, Fixing Your Scrum, Week 15, Chapter 15: The Sprint Retrospective

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. 

 

Re-Read Saturday, Fixing Your Scrum, Week 14, Chapter 14: The Sprint Review

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.

 

Re-Read Saturday, Fixing Your Scrum, Week 13, Chapter 13: Deconstructing The Done Product Increment

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.