This week we feature our interview with Eric Daimler, Ph.D. Eric and I discussed how AI can unlock the potential of humanity.  


The accountability conversation is the fifth and last conversation addressed by Squirrel and Fredrick in Agile Conversations. Next week we will cover the conclusions and some final thoughts. Then we will have a quick interlude re-reading Jim Benson’s Why Limit WiP while we run a poll to select the next books. 

In Chapter 7 the authors define accountability as “being obligated to render an account of what you have done and why.” They suggest that the definition is a departure from normal usage. I don’t think of this as a radical departure from the classic Merriam-Webster Dictionary definition which focuses on providing and/or giving an explanation. All the current common definitions I found boil down to expressing what was done and why.


Week 7of our re-read of  Agile Conversations by Douglas Squirrel and Jeffrey Fredrick begins Chapter 5 addressing the ‘Why Conversation’. Like the ‘Fear Conversation’, we will approach this in two parts; focusing this week on two areas, position and interests, and inquiry and advocacy. We will tackle joint design next week. 


Chapter 2 of Agile Conversations by Douglas Squirrel and Jeffrey Fredrick is titled, Escaping The Software Factory. The idea that software development and maintenance fit a factory model in which people are fungible and that processes are deterministic is a thing in 2021 (as it was when this book was written). I have always been hard-pressed to buy the factory/manufacturing model. I have worked on an assembly line. One of the jobs I had was building tires for Firestone Tire and Rubber Company at their plant in Memphis. That job was one of the reasons I made sure I went to university. Whether the assembly line model was truly appropriate even for tire manufacturing would be interesting to debate (the plant is gone, no amount of scientific management could save it). At the very least, software development and maintenance are better served by team-based collaborative approaches. Words like team-based and collaboration require communication (something that did not happen on the assembly line, except when we had union meetings) so that rigid processes and micromanagement can be minimized.


This week we continue the priority theme with an essay titled, “What is a Priority?” I wish it was a simple question. Since the whole idea of priority is premised on a group of people having a shared perspective and definition this is a question that needs to be asked and answered. 

We also have a visit from Susan Parente with her I’m Not A Scrumdamentalist column.  In this installment, we tackle bad leadership (I wish tackle was not used metaphorically).


The Software Process and Measurement Cast features an essay on prioritization. We prioritize in order to establish what to work on and when to do it. There is often a difference between assigned priority and the real priority based on when teams start and complete a piece of work. This essay is part of the overall conversation on controlling work entry and answering the question: Are we working on the most important thing?

We also have a visit to the QA Corner with Jeremy Berriault. Mr. Berriault and I discussed how testing is integrated into the Agile Performance Holarchy.


This week we dive into what is often viewed as arcane science by the development community, pricing. Pricing can make or break any product. Everyone in the value chain has to have a good understanding of how pricing decisions are made and how they can impact what should be built and when. One critical part of the conversation focuses on whether there is an ideal pattern for product and development to work together? If not, what are the consequences? Our conversation just skims the surface of Ajit Ghuman’s new book Priced to Scale which hit the book stands in April. 


Work Entry: An Introduction, focuses on what work entry is and why it is the single most important part of determining whether a team is dependable, predictable, and even remotely agile. 

We will also have a visit from Jon M Quigley and his Alpha and Omega of Product Development. Jon and I discuss, wrestle, and chew on how the idea of a product backlog can exist in a project environment. 

Re-Read Saturday News 

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 briefly consider three points that came to mind during the re-read. If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems 

Next week we will start our re-read of Monotasking by Staffan Noteberg by laying out an approach. I am contemplating combining the re-read with experience reports as I try to put the ideas in the book to use. More on that next week.

This Week’s Installment 

Week 16 – Final Thoughtshttps://bit.ly/3p3tbU0v 

Previous Installments

Week 1: Re-read Logistics and Front Matterhttps://bit.ly/3mgz9P6 

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Badhttps://bit.ly/37w4Dv9 

Week 3: Breaking Bad Scrum with a Value-Driven Approachhttp://bit.ly/3stGc9Q 

Week 4: The Product Ownerhttps://bit.ly/3qpKvSn 

Week 5: The Product Backloghttp://bit.ly/3cAEk9c 

Week 6: The Development Teamhttp://bit.ly/2OLVAAs 

Week 7: Embracing The Scrum Master Role –  https://bit.ly/3m0HB5D 

Week 8: Managementhttps://bit.ly/31Kv39l 

Week 9:  Thinking In Sprintshttps://bit.ly/321wXTg 

Week 10: Sprint Planninghttps://bit.ly/3stWOhx 

Week 11: Sprint Backloghttps://bit.ly/3njezit 

Week 12 – Reclaiming The Daily Scrumhttps://bit.ly/3eNzMgz 

Week 13: Deconstructing the Done Product Increment – https://bit.ly/3bedTGc 

Week 14: The Sprint Reviewhttps://bit.ly/3huZvgP 

Week 15: The Retrospective https://bit.ly/3bOK2Vg 


Speaking of Monotasking by Staffan Noteberg, in the next podcast, we will feature the interview I did with Staffan covering the book that we are about to re-read.  We discussed how to apply the ideas in the book to improve focus, productivity, and quality of life.

Play Now!

The idea of Communities of Practice is thrown around a lot in organizations, often without thinking about the goals of a CoP.  Why? Organizations are increasingly becoming more diverse and distributed, while at the same time pursuing mechanisms to increase collaboration between groups and consistency of knowledge and practice hence the rapid growth of Communities of Practice.  Let’s explore the goals of a CoP.

This week also marks the premiere of Tony Timbol’s new column, “To Tell A Story.” In this week’s installment, we begin to explore the nuances of User Stories.  Tony is a practitioner, consultant, entrepreneur, and science fiction author — Tony does it all.

Email: tony.timbol@agileready.net

Web: BeAgileReady.com 

Interested in Mikolaj Pawlikoski’s book, Chaos Engineering, Site reliability through controlled disruption I have discount codes for the listeners of the Software Process and Measurement Cast, ping me @tcagley@tomcagley.com and I will share them with you!

Play Now!

This week’s Software Process and Measurement Cast features our interview with Ted Harrington, author of HACKABLE: How to Do Application Security Right. Application security requires planning, coding, and testing. It is not something that you can easily remedy after the fact – it needs to be part of the conversation before you write one line of code. Ted provides insights for developers, C-level executives, and product owners. If you have not bought a copy buy two copies (https://amzn.to/386w7Hr), one for you and one for your boss, and listen to the interview together.


Next Page »