I’ve been reading many posts on Reddit about “daily scrum” meetings, and I’ve got to say, there are some really strange practices out there. I don’t understand how people are ending up with the processes they do. I wanted to write down a few basics to get them out of my head and be able to share them with others, so I’m drafting this post. This post will be about the team daily touchbase meeting format that I’ve been using for the last three years, known in for-fee framework circles as “the daily scrum” and also as “daily standup”.

What Is Agility?

People seem to talk a bunch about “big-A Agile”. I don’t know that I like labels too much. I am working more from base principles here than from a Scrum foundations textbook or the Agile Manifesto. But it does seem reasonable to review some Agile basics.

Being agile, for my purposes, starts in the definition of the word:

Able to move quickly and easily

When developing a product, the point of “being agile” is to be able to move quickly and easily. This definition says “move”, but I think there’s more of a feeling here of “adaptivity” than motion. In my mind, agility is the ability to adapt quickly and easily, no matter the challenges that might occur during development. To move quickly and easily, we must also be able to adapt to challenges quickly and easily thaat seem to always interrupt and make things harder.

The Most Important Ceremony

To be agile, I think boils down into three words, “Inspect and Adapt”. While having an outcome in mind is necessary to follow an agile process, there are many non-agile processes that you could follow (see most of what people are doing on Reddit) that still have some outcome in mind, but are still not agile; Therefore, while I’m considering that the outcome is baked into the process, that an outcome exists is not itself unique to any agile process.

Building on inspection and adaptation as the basis of an agile process, if you’re going to only hold one ceremony/meeting to start, the most important one to begin with should be a “retrospective”. Why is the retrospective the most important meeting? Because it takes the two most important parts of being agile, inspection and adaptation, and focuses exclusively on them. Also, the retrospective purpose is to inspect what you’ve been doing, and adapt that process so that the outcome is improved.

There are two implications to a retrospective upholding these two sacrosanct agile principles. First, the retrospective must inspect the process that arrived at the outcome that occurred. While this may include some inspection of the outcome itself, the lens must be aimed so that the focus is primarily on the process, because you cannot inspect just the outcome and expect to change it without also looking at what led to its occurrance. Second, the retrospective must include an explicit mechanism for adaptation. Too often, a meeting will conclude with action items being recorded that could improve outcomes, but those action items are not enacted. The action items must be captured in such a way that they will be acted upon, not simply noted for future observation when failures continue.

What does this have to do with a daily touchbase?

If you start from nothing, and you want agility, you will hold an initial retrospective to understand how your current process does not serve your outcomes as best it can, and will imagine how you can adapt/invent your process to improve those outcomes. The very first thing you should notice about your process, lacking all other ceremonies, is that to have agility - the ability to adapt to changes in the demand of/for your product - you may need to communicate the challenges on the ground more quickly. Whether changes in demand come from a product team (or people functioning as a proxy for the customer) or challenges in production come from the development team, you will want your process to respond as quickly as possible to those needs without over-burdening the product team with process.

To do correct course without going too far astray, you will likely need to inspect and adapt the process of your product development more frequently. Yes, this means more frequent retrospectives. The challenge is holding retrospectives in duration and frequency that is proportional to the amount of change required to keep product development on course. Imagine a boat where daily course correction is done via a rudder, to keep the boat headed in generally the right direction. You would likely not set your rudder once every two weeks and expect to arrive at your destination. The right amount of course correction over each day of product development is likely to embody itself as a daily touchbase.

Daily touchbase is a retrospective focused on the last 24 hours to keep product development on course.

A full retrospective would change the rudder to a motor, or suggest sails, or changing the shape of the hull, or other larger changes that are likely to have a bigger impact on the overall voyage. A daily touchbase - or “standup” - is meant to take what processes exist and keep them on course.

Touchbase, Not Standup

“Standup” is the name that many people use to talk about the daily touchbase meeting, implying that the meeting must be held while standing. This is to encourage the meeting to be short. This is dumb for two reasons. First, it’s ablist. For anyone who can’t stand, you’ve just implied a terrible barrier to participating in your agile ceremonies. Second, you’re imposing an arbitrary inconvenience to force meetings to be short. This is as dumb as setting the room you’re in on fire so that you keep the meeting as short as possible. The meeting should be as long as it needs to be, and no longer, and the agenda for the meeting should be controlled for duration.

I’m not suggesting that all of your touchbases be an hour long, simply that they are exactly as long as they need to be to purposefully keep development flowing. If you need to schedule time for your touchbase - which is a practical consideration we all have - consider scheduling it for a short time, say 15 minutes, at a time of day where you can take longer than the schedule allows if necessary. Just before lunch is great so that you aren’t interrupting the team’s work to hold a meeting, and yet it has the buffer of lunch to overrun into (with the added benefit of nobody really wanting it to run long if it doesn’t have to).

Why Daily?

Do you need to have a touchbase every day? My answer to this question is pretty simple: How long would you be willing to tolerate work being done that, without a course correction, is throw-away? If you would rather not have more than a day go by without being able to change course to properly achieve your goal, then daily is the cadence you’re looking for.

I would even suggest that if you’re doing Monday-Wednesday-Friday touchbases without having first tried and measured daily touchbases, you might want to evaluate the turn-around-time to adjust course on specific work. Are you not measuring how much time you’re wasting when people are doing the wrong work or doing work the wrong way? Interesting… Read on…

How Your Touchbase Is Wrong

You may already be holding daily touchbases. Do you ask each of the members on your team for the status of what they’re working on? You probably already know this is wrong – The touchbase meeting is not a status meeting; it’s a retrospective of the last 24 hours to keep development on course. Do not use your touchbase for status updates!

Do you do an “around the table” or “across the board” touchbase? Does “what I did, what’s next, what I’m blocked by” sound familiar? These are pretty common mechanisms for touchbases. If they’re working for you, I suppose that’s nice. If you want to step up your game, let’s focus on the important parts of what a touchbase needs to accomplish and see what you might like to change.

Here are some basic questions:

  • How do you keep your team engaged for the duration of this meeting?
  • How do you know what challenges exist to your team getting their work done?
  • How do you ensure that there aren’t hidden blocks to planned work that affect your schedule?
  • How do you you record/examine the amount of time you’re spending on changing direction?

You might have noticed, if you’re doing those other meetings, that your team only really pays attention when it’s each person’s turn to talk or their name is called out. Does that actually mean your meeting is a status meeting? If seven of the eight members of your team ramble for 15 minutes about what they did yesterday, what they’re doing today, and that they have no blockers, then your last teammate has a real problem, did you waste 15 minutes of the team’s time talking about meaningless status updates when you could have been working together to solve that person’s actual problems? Yes. Yes, you did it wrong.

What the Traction Touchbase Is

The Traction Touchbase is a meeting format for the daily touchbase. You can adjust as necessary (as a result of a retrospective!), but it has the primary function to enable your team to keep their daily work on track and raise alerts early for things that would disrupt their flow.

There are six parts to the Traction Touchbase:

  1. Segue
  2. To-Do List Review
  3. Scorecard
  4. Build out the Issues List
  5. IDS
  6. Close

Each part is designed to keep your team engaged and keep work flowing. And yes, it can easily be done in 15 minutes or less.

Parts of the Traction Touchbase

A> To give an example of how a typical Traction Touchbase might go, a transcript of an imagined touchbase appears in these asides next to each section.

A> Alice is the facilitator for this transcript, and all other participants are developers on the team.

Here are each of the six parts of the Traction Touchbase broken down in detail.

There are two artifacts referred to here that are used during the Traction Touchbase: The To-Do List and the Issues List.

The To-Do List is a running list of to-do items that carries from day to day. The entire team is responsible for maintaining this to-do list. Each item on the list is assigned to one or more people on the team.

The Issues List is a list that is generated fresh (has nothing on it to start) during each touchbase meeting. The facilitator of the meeting adds things to the Issues List as the meeting progresses. By the end of the meeting, each of the items on the Issues List has been addressed. An Issues List does not persist between meetings.

Segue

A> Alice: Did everyone have a nice weekend?

A> Bob: I finally got out on the boat!

A> Dave: That’s awesome, send photos to the team Slack.

A> Alice: Very cool, Bob. I can already see Chris daydreaming about her trip next week.

A> Chris: Sorry, what did you say? I was daydreaming.

A> Alice: Funny. Ok, let’s get to work!

The Segue is meant to be a warm-up for the meeting. This typically consists of one of banter just to get the team engaged.

Established teams typically don’t need coaching on the segue, they naturally fall into banter as the meeting begins. For new teams, or teams with new or visiting members, it is useful to perform introductions before getting underway. Sometimes an icebreaker is useful for brand new teams, though not recommended every day. Mondays are great days for ice breakers even for established teams, if there’s time.

To ensure that there’s time for all topics under discussion, assuming normal touchbase durations of roughly 15 minutes, try to limit the segue to just a couple of minutes.

Segue is pronounced “SEG-way”

To-Do List Review

A> Alice: Ok, there are three to-do’s. Bob, you were going to turn on access for the team on the new server, did you get that done?

A> Bob: Yes, should be all set now, let me know if you can’t get in.

A> Alice: Great. Chris, you were going to card up some of that config work; get that done?

A> Chris: No, not yet.

A> Alice: No worries, I’ll leave it on the list. And finally, Dave, do you have an update on the potential options for deployment?

A> Dave: Sure! The first option is…

A> Alice: Hold up, I’ll add that to the issues list and we’ll talk about it in a second.

The To-Do List Review is a review of items previously recorded in the to-do list. It should be a simple run-down of the list with one of three responses for each item: “Done”, “Not Yet Done”, or an issue added to discuss the item in the Issues List. Items that are not done remain on the list for the next review. Items having a report from their assignee should add an issue to the Issues List for the IDS phase and be marked as done during the To-Do List Review. Items that are done and accounted for during the meeting are removed from the list immediately or after the touchbase is over. It is important that if you are assigned an item on this list and you are able to mark it as done for the touchbase, that you mark it as completed but do not remove the item from the list so that it can be reviewed during this portion of the touchbase.

Every item in the list should be reviewed in every meeting, except for items that have specific re-review dates assigned to them. If an item is checked as complete, the intent is to confirm that there is no follow-on action necessary (add an issue to the issues list, if so). Completed issues should be removed from the to-do list during each meeting, with any needed follow-on items being added as a result of the IDS phase that includes that follow-on issue.

Items should not remain on the list for more than two weeks without motion. If an item is on the list for two weeks, it should be re-raised as an issue in the IDS phase.

Other incidents with to-do items (people going on vacation, and not being able to complete assigned to-dos, for example) may also trigger an issue to be added in the IDS phase.

Scorecard

A> Alice: Looking at our metrics, I see that card 473 has been in progress for four days with no update. Let’s add that one to the issues list, just to make sure it’s not stuck.

A> Alice: Our backlog is looking a little light, let’s add an issue to talk about whether we need to write up some more cards to work.

The Scorecard component is meant to establish key performance indicators of the team as it progresses through work. These indicators should give the team an idea of how the work is progressing in real-time, with a simple set of numbers that are easily understood. These measurements can trigger warnings to look more in-depth at their causes.

In concept, the data used in this section should provide an indicator of issues that should be added to the Issues List for discussion. Appropriate measurements for each team will vary, but a common valid metric to use for teams with a kanban board is a measure of “aging work in progress”. Aging work in progress is a measure of how many days a card has been in development. The ideal intent is for the duration of each card to be equal to the number of days estimated for that card. In true Kanban, the duration a card should be in development should be no more than the current SLE duration as defined by the team.

If a card indicates that it has been sitting in a column long enough to impact (or to have the potential to impact) the team’s SLE, then the card should be added to the Issues List.

Other measurements that may trigger the addition of items to the Issues List include the current backlog length, the number of developers involved in interrupt work, metrics from error reporting systems, burndown chart deviation, number of overnight pager alerts, or anything that produces a metric that would indicate a point of discussion that could help persist the team’s flow.

Build out the Issues List

A> Alice: Ok, what issues do you all have to raise?

A> Bob: I got paged for high load on server 4 last night, and I found a problem I want to get input on.

A> Alice: Ok, I’ve added “server 4” to the issues list. What else?

A> Chris: I’m working on 507, and it’s not going as smoothly as I’d hoped.

A> Alice: Ok, I’ve added 507 to the list. What else? … Nothing else? Cool.

Up until this point in the touchbase, items should have been accruing on the Issues List. As mentioned, the Issues List is the list of topics that are meant to be discussed during the next phase, the IDS phase.

These are some, but not all, of the things that could be added to the issues list before or during this phase of the meeting:

  • Topics arising from the to-do list
  • Cards that are notable from the scorecard
    • Cards that are blocked
    • Cards that are in danger of exceeding our Kanban SLE
    • Cards that are thought to potentially become blocked, improperly scoped, or may challenge our Kanban SLE
    • Cards that are inappropriate for the current team goals
  • Rocks from a “rock review”
    • Potential upcoming challenges with work from large projects
    • Requests for help with upcoming work
    • Pairing requests
    • PR Code Review or testing requests
  • Topics from meetings since the last touchbase that are to be shared with the team

This list is just a hint at the nature of the issues that should be added to the Issues List, and is not comprehensive. The purpose of this step in the touchbase process is to collect all of the topics that need to be discussed and resolved.

It seems obvious and sadly necessary to mention here that the touchbase facilitator need not be a scrum master or manager, but can be anyone on the team. Rotating the facilitator across every member of the team such that a person facilitates for a whole week is actually really useful. It spreads responsibility, educates each member of the team on the process, and encourages them to take accountability for their own work. It might be useful to have a key member of the team run the meetings on Mondays and introduce an issue that describes the week’s deliverable goals for the team. This also allows the week’s facilitator to be named without them being surprised on Monday. The added benefit is that you don’t have one person who facilitates all of the meetings who can never take vacation without the team being unable to proceed with work.

Reviewing Rocks for the Issues List

A> Alice: We’ve got that deadline for ACME coming up next month, is there anything that anyone knows of that would prevent us meeting it?

A> Bob: I think 423 is on the critical path for that one, but it’s written oddly.

A> Alice: Huh, I don’t know about that one. Let me add it to the list.

A rock review is a way to ensure that the most important work that moves the team towards its goals are surfaced for addition to the Issues List. A “rock” is a big item for which the team is responsible to complete in the short term. These are often recorded as epics on a Kanban board, and it should be possible to run down the list of epics (or customers) that have been assigned some work for the team.

Another critical question at this point is whether any major projects require additional planning (or will soon) in order to continue development. If so, this should be raised as an issue for the issue list, and a discussion should be had about when to have and who to invite to a meeting to plan additional work.

A Note About Building the Issues List

While building out the Issues List, participants should refrain from describing their issue in detail. This should wait until the IDS phase. This is important and is probably the hardest part of the process make natural. Even if the issue seems like a small announcement related to the project, the priority and depth of the issue may be different than the contributor perceives, and discussion on this one topic should not upset the process. A key phrase (such as “elmo”) should be used to suggest that the issue alone will be recorded, and discussion can happen later. All participants should feel empowered to shout out “elmo” (Enough, Let’s Move On) if the issue prematurely enters discussion.

This is an important rule of this touchbase format to abide by, but even teams that are skilled at this format break the rule on occasion. As long as there aren’t other important topics to cover, this is fine. Teams should nonetheless make sure to hold themselves accountable to this rule, as it is the thing that has the greatest effect on keeping touchbases to an appropriate duration.

IDS

A> Alice: Ok, given that we’re betting our reputation on the ACME launch, let’s talk about 423 first. Bob, wanna give us a summary?

A> Bob: Sure. ACME’s rep asked us to put a few modals into the app, and I’m not so sure that we should be doing that. The rest of the UX has no modals.

A> Chris: We were pretty clear with them when we started that we wanted these notices to be async to make the user’s experience smooth. All of the design docs show toasts and update the data in realtime.

A> Dave: Yeah, I think I know what is going on here. ACME talked to our new product associate, and the two of us wrote up an initial card for the work. I think I expected to update things in refinement, but it’s been a while and we hadn’t gotten to that yet.

A> Chris: Just confirming, we still want everything to be async, yes?

A> Dave: Yeah, definitely, I was just trying to show Tom how we write up cards real quick.

A> Alice: Ok, cool. So, Dave, do you want to update that card definition so that it matches the UX, or should we just wait for refinement to fix it up?

A> Dave: Nah, let’s not wait. It’s caused enough confusion, and I don’t want one of the interns to pick it up and do it wrong. I’ll fix the card.

A> Alice: Sounds good. I’ve added a to-do for you here. Ok, next up is server four…

The IDS phase is the phase where issues are discussed. The issues are presented in order of importance. Importance is often subjective, and the facilitator of the meeting should try to be as objective as possible when setting the order of issues for review. In cases when it’s not clear, start with the urgent issues, then move on through the issues in order they were added. The reason for this is to ensure that the important issues are discussed and solved within the meeting time limits. If the other issues are not covered, this is ok; Follow-ups via email, chat, or an additional meeting can be organized. It’s simply important to ensure that the important items get actual meeting time.

IDS stands for Identify, Discuss, Solve. Each issue in the list should be subject to each step of the process. There are times when it’s obvious that a protracted process is not required, but this has to be felt out by the participants as they become familiar with the process. Because the daily touchbase is such a short meeting, effort should be taken to keep the IDS phase moving quickly, or otherwise, to schedule a separate meeting to more thoroughly discuss the topic.

For each issue in the Issues List, do the following:

Identify

The issue discussion should start with a basic statement of the understanding of the issue. Sometimes this is enough. Often, there are issues that underly the issues that are obvious. It’s important to use this phase of the IDS process to identify the root cause so that it can be solved.

Discuss

After the true issue is identified, the participants of the meeting should discuss the issue. Options should be presented as potential solutions, and questions should be asked and answered to help illuminate challenges to the solution. Participants should all have their say on the topic, but not belabor their points.

Solve

It’s sometimes not obvious that participants should arrive at a solution for raised issues. This phase ensures that every raised issue has a solution. The decider/facilitator present in the meeting (sometimes these are not the same person) hears the discussion and ultimately chooses a solution to the issue. Upon arriving at this decision, discussion is closed, and the group agrees to abide by the decision made.

Solutions consist of one of the three potential types of action items:

  1. Assign an action task to a specific person. This task should be added with the person’s name to the to-do list. Only one person should be assigned to any to-do item, which makes that person accountable for the task, even if a pair or group is responsible for accomplishing it. It is possible to generate more than one to-do from a single issue, but the person accountable for the to-do should be explicitly recorded for each, even if that person is the same for every to-do item.
  2. Assign an investigation task to a specific person. The investigation task is recorded just like the action task, but the expectation is that the person to whom the item is assigned will supply the group with a report for discussion in some future meeting. The report is presented as an issue in the IDS phase in a meeting after the investigation is complete, or there are questions raised by the investigator that the group must convene on.
  3. Make the group aware of a condition. Sometimes the result of an issue is simply to announce a condition or information to the group as a whole. The information could simply be conveyed verbally in the meeting (“We aren’t doing X anymore, please be aware.” or “The dishwasher is out of service today, so use paper plates.”), but an explicit decision should be made as to whether to record the information more formally in the team documentation or to send it out via email. This would result in an action task being assigned to a person.

Close

A> Alice: Ok, that’s the whole issues list. Nicely done. Any last-minute announcements?

A> Chris: Yeah! Don’t forget, I’m going to be out next week, so get any last minute stuff to me ASAP.

A> Alice: That trip is going to be so fun. And we want more photos of the kids on the boat, Bob!

A> Bob: Ask and ye shall receive!

A> Alice: Excellent. Ok, thanks everyone! Enjoy lunch!

There may be some information that would be useful for the team to convey after the meeting has closed, and there is usually informal banter at this time. For informal announcements, such as someont letting the team know that they’re taking time off and will be unavailable, this might be good to save for the meeting close. It may be useful for new groups to make a point of noting where to-dos and notes might be published for the meeting, although for established groups this may be well known enough that it can be skipped.

At the close of the meeting, participants know that the meeting has ended and that the issues have been completely discussed.

It is useful to have participants rate the meeting from 1 to 10, or even a simple thumbs-up/down, on how well the meeting went so that they can work to improve the meeting content and keep the vibe upbeat and productive. When rating the meeting, participants should consider whether this meeting contained and remained focused on useful content, and whether they were able to (or understood their teammates to be) engage in the meeting in a useful way. Rating the meeting in this way implies to the team that their engagement is of concern, and that they should connect with the meeting or its not being done well. Not every meeting is going to be a winner, but it’s incumbent upon the participants to make the meeting worthwhile. Be wary – Lively discussion on a topic is good, even if people were in vehement disagreement!

The Traction Advantage

The Traction Touchbase has some characteristics that are meant to solve for problems with the other types of touchbase meetings:

The work described by a majority of participants does not need to be discussed. It is a waste of time for 9 people out of a 10-person team to answer the standard scrum standup questions when everything’s going smoothly, only to have the tenth person drop a bomb on the meeting. With Traction, only the important issues are raised, and by design the most important issues are discussed first.

Daily touchbases should not be status meetings. There is a mechanism for understanding status that is better than a meeting – the kanban board. Team members should be aware of how to use the board effectively to indicate progress against their work. Work should be broken down to a point that small cards can move through the board and indicate sprint progress. There is therefore no reason to waste daily touchbase time on status. Traction dedicates zero time to status updates.

People tune out when it’s not their turn. If the point of the meeting is to convey important information to and receive feedback and valuable discussion from your team, it is paramount that the team is paying attention. In other formats, the team tends to pay attention to what is going on only insofar as they know when it is their turn to speak. When a person is done speaking, they tune out completely or work on other things until the meeting concludes. The facilitator frequently needs to intervene to get parties that should be interested to listen to someone else talk about topics that affect them. Traction focuses on discussing important issues such that all participants can and should be engaged throughout the meeting.

Freeform discussion doesn’t illuminate important issues. In some derivations of the “Around the Table” format, participants do not stick to the three-question (or more expansive) format, and instead talk about work in general. This may bring to light important information, but it may not. Using Traction, the important issues are always brought to the table for potential discussion, as well as topics of import that may be on the participants minds, using a formalized process for ensuring completeness that is still very casual to implement.

Touchbases typically don’t focus on team key performance indicators. There are key indicators of a team’s performance. Many teams measure velocity, but then have no active way of measuring work to ensure that velocity stays on track. Using Traction, performance metrics are a visible part of the work, and team members can see how committing to those metrics improves their flow.

Traction Disadvantages

Of course, it would be foolish to suggest that this process was ideal with no flaws. There are some characteristics of this touchbase format that make Traction challenging:

Traction assumes that its participants exhibit professional rigor. This is not meant to imply that anyone using the other methods is unprofessional; Rather, there is a bit more professional rigor required to make Traction work, since, for example, it does not supply a daily status update. Participants need to know how to effectively use the tools responsible for reporting general status to the group such that it appears in the Scorecard phase and filters into the issues process. Participants need to know when to raise issues on their projects, like when they anticipate blockages or are having difficulty with their work, so that they can be discussed as needed. If members of the team are not professional about their work, problems can languish. Traction meetings require team trust, and the facilitator must encourage this in tangible ways. On the positive side, Traction can be encouraging for teams to develop this discipline, since it trains them to be more aware of when issues need to be surfaced and encourages that collaboration.

Traction requires status metrics to be observed separately. This isn’t as much of a problem for the participants or the meeting, but for a manager using Traction, the work to understand what everyone is working on and how things are progressing on a day to day basis must be obtained by other means. The benefit is that the team is not wasting time double-reporting status on a board and in a touchbase meeting, and if done properly, forcing the status report to be physically tracked and recorded provides useful metrics to the team on sprint velocity and estimation.

Traction is hard to understand just by reading about it. I have heard this complaint before from people who read the documentation and haven’t tried it. But ask them to give it a try for a month, and put some real effort into facilititating the meeting well yourself during that time. I have yet to meet a developer that did not love the Traction format after they became familiar with it running smoothly. I often liken Traction to the game of baseball…

You may be familiar with the rules of baseball, in general. Imagine trying to teach baseball to a child who has never seen or played the game. I know from personal experience that this is a challenging process, because there are so many rules that we’ve internalized that it feels simple, even though the game is quite complex. Please keep this in mind as you consider this touchbase format, since the process described here is quite simple, even if describing it seems tedious to the point of wondering if you should bother learning it.

In Closing…

The Traction Touchbase is one significant part of a clean and functioning agile team’s toolkit. I’m curious what you’re doing and where you’ve found success that might deviate from the traditional options but with greater success. (Certainly, I have no interest in “the three questions around the table reported via slackbot each day works well enough for me”, since I have not yet met a team that can even answer basic questions about their daily work, flow, and progress in this kind of system.)

I’m a strong believer that touchbases are daily events, involving the entire team (as often as is possible), and done “live”, whether on a group call, video chat, or together in person. My bold claim here is that folks who do not feel like 15 minutes of their workday to align with their team on their work is worth their time are likely in a dysfunctional team – There is a lack of team trust, the work isn’t being broken down properly, they lack acocuntability, or even possibly there are poor performers hiding behind an unsupportive process.

Give Traction a try and see if it improves your touchbases! Next, I plan to write up some notes about how you should stop using Scrum, and really dive fully into true Kanban principles to ensure the flow of work on your team. If you’re not familiar, I think people will be surprised at some of the problems Kanban, when done as more than just “the board we write work on”, can solve.