Today, we feature an essay titled, So I Asked What Is Agile. A simple question that yields interesting answers. One interesting outcome was that answers fit into three categories. We explore the process and people-oriented groups this week. I will come back to the rant category later this month.  


If you ask the question what is agile in polite company you get a wide range of answers. I know because I have asked that question in polite and less cultured environments. Polite answers focus on ceremonies, people, mindsets, guardrails, or paths. The less than polite are usually a version that people are using the term agile as a form of gaslighting.  Pushing aside the last group, at least for now, we are left with two categories of answers. The first focusing on process and the second on people. Both are right because both reflect different real-world contexts and different personal and organizational needs. Perception of “what” is agile, how you define agile, is heavily influenced by what you want from agile; the why of agile. This is true for practitioners as well as organizations which is why specific agile practitioners are more comfortable in some organizations and vice versa. As a consultant, I have seen a wide spectrum of definitions — all tied to the reason the organization is interested in agile. 


Until this week, Disciplined Agile was a topic we had not investigated on the Software Process and Measurement Cast. DA is an approach to scaling agile development.  Today, Jonathan Lee and I discuss Disciplined Agile and reinventing yourself to stay relevant in a dynamic world. 


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 ). 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 

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. 


In Chapter 1, The Age of Software, Kersten established that we were at or just past a turning point; those that do not embrace change will face grave difficulties surviving to the next cycle. As a consultant, I work with companies wrestling with trying to transform. Not all succeed for a variety of reasons. In this chapter, the author highlights and compares the lessons derived from his visit to the BMW plant, his study of the development of the Boeing Dreamliner, and the transformation failures at Nokia and a large bank. The first two examples reflect the pinnacle of a product view from the Age of Mass Production which preceded the Age of Software.


Luis Gonçalves and I talked about his new book introducing the ADAPT Methodology. We discussed why using a framework can help leaders stay relevant. Our conversation dovetails nicely into the Re-read Saturday focus on Project to Product. There is a lot of synergy between the ideas of Kersten and Gonçalves. 


As a coach, I use and observe transactive memory all the time. Used wisely, transactive memory means a team can be more than the sum of its individual members. Mess it up and you might as well put your hand in a running garbage disposal. For example, my wife remembers things like special events and then clues me in…if she is around. This year I missed an important birthday.  Coaches and Scrum Masters often act as the official process memory for teams until they move on . . . you can guess what happens next. This week we explore when transactive memory works and when it does not.

Also, Jeremy Berriault and I discuss helping improve Daily Scrums in his QA Corner column.


We are back from backpacking on Isle Royale. Simply awesome.  Today, we feature a discussion with Tom Henricksen.  You know Tom from the Agile Online Summit and the Dev Ops Online Summit however Tom is more than just the Summits. Today we discuss learning and then get into whether hybrid working scenarios are all they are cracked up to be. I am not sure we agreed.


New content is nearly here!  The Software Process and Measurement Cast and Blog’s summer hiatus is drawing to a close.  There is still time to help pick the next Re-read Saturday Book.  I have decided to select the two books with the highest vote count (I like all of them) and use that as my backlog. Vote now and if you have already voted once, feel free to vote again to emphasize your opinion.

Upcoming Events

Have you registered for what in my opinion is the premier Agile Online Conference? It is time to monotask and take care of that oversight

Register Now and join us from October 25th to 27th, 2021, featuring live and recorded segments.

Join Tom and crew for the fifth annual event, The Agile Online Summit was virtual before virtual became a thing — they really know how to do this right. Tom indicates that since this is a milestone anniversary, he has some exciting twists and turns.  The Summit has free options and paid add-ons so you can tailor your experience to your schedule and need. Register using the link below to let them know the Software Process and Measurement Cast sent you 

Register at

Where to first?

Most of you know I am re-reading  Monotasking by Staffan Nöteberg as part of our Re-Read Saturday Feature. I thought I had completed my current theme on prioritization when I read the section in the book on kinds of priority. The whole idea of priority is premised on a group of people having a shared perspective and definition. That perspective may vary, which can be troublesome, but there is at least a rough consensus about what the word means. Steffan dissuaded me of the idea that there was a common framework for thinking about priority. There are many ways to think about priority. In Monotasksing, Nöteberg describes D. W. Houge’s 1970 paper in which he described four kinds of perceived priority.  

  1. Relative Priority – A team will work all priorities at the same time but with more emphasis on the most important. In practice, this is often the case when teams start everything as work is presented leading to WIP issues. Everything is a priority, therefore nothing is a priority.
  2. Spillover Priority – Put all effort to the top priority until it is done and then when done, shift your effort to the next priority.   This is the type of priority Staffan uses as part of the Short List concept in Monotaksing. 
  3. In-case-of-conflict Priority – Teams do everything with equal emphasis unless conflict between projects occurs then they adjust based on the conflict. I see this often when teams apply the squeaky wheel approach to prioritization. 
  4. Completion Priority – Prioritize and do work that can be completed. This approach was recently described by a colleague as a fill-in method or the low-hanging fruit approach. People and teams that use this approach always have a list of shorter items that can be knocked off quickly that they use to fill gaps between larger items. Priority on that list is not explicitly linked to value but rather to duration. This is a weighted shortest job first approach without the value weighting. 

Hogue’s perspective shows that is a wide range of ways to use and define priority. On reflection, the idea that different people have different frameworks to define priority and then use their definition to allocate people and resources should not have come as a shock as we have explored other methods on this blog before.  For example, another approach to defining and assessing priority is the classic Eisenhower matrix. This approach uses importance and urgency as a tool to define priority. For example, items that are important and urgent should be done BEFORE items that are urgent but not important. 

Paul Spicker’s paper, What is a priority? (Spicker) outlines a third approach.  The paper suggests that there are five kinds of priorities.  They are:

  1. Priority as importance. One item is more important than something else. Implementation of the word important is a matter of context and biases. 
  2. Relative Priority. Importance is a function of set weights that can be allocated between options to generate a decision on the priority of an item.
  3. Precedence. Priority is defined based on whether one option has to be dealt with before another option. 
  4. Priority as special status. Priority is influenced by specific attributes that must always be taken into account. Set-asides are a form of special status. An organization I worked with required a percentage of all work to be for tech debt reduction; it had special status. In many organizations, specific products have special status and are considered first for people and resources. 
  5. Lexical ordering. The order of items imputes priority. In the same organization, UI/UX was listed first on the priority list because they affected users. Lexical ordering is often influenced by other factors such as special statuses. 

Spicker approached defining priority in a medical setting, however, the logical construct is useful for defining how we can create a framework for knowing what to do next. At its heart, priority is merely a construct. Left to our own devices each of us uses our own bias to determine what is important. Whether you leverage the ideas of Houge, Eisenhower, or Spicker is far less important than adopting a framework and then ensuring everyone understands it.

Next, we will combine the ideas of all three approaches.


Spicker, Paul. “What is a priority?” Journal of Health Services Research & Policy, vol. 14, no. 2, 2009, pp. 112-116. (Downloaded 8/10/2021)