Kevin E. Schlabach

Category: Teams

  • On Track, No Impediments

    My greatest pet peeve is watching a standup where the facilitator calls on each person round robin, each one says “on track, no impediments,” and the meeting wraps in 4 minutes. Just like yesterday.

    That’s not a healthy standup. It’s a status report with eye contact. Or, with cameras off, it’s just voices passing notes that could’ve been a message in a team channel.

    The standup is the moment where the collaboration happening in pairing sessions and side conversations becomes visible to the whole team. It’s where you check in on shared architectural paths, not your own lane. When it doesn’t, diverging approaches and technical debt are seeds taking root.

    I always have an ear out for when someone mentions friction or concern about their work and their teammates immediately move on to what they’re picking up next. That’s backwards. Stabilizing work already in flight is almost always more valuable than starting something new. If you can contribute to unblocking a peer, that’s the better focus.

    From a Scrum Master or Product Owner perspective, this is also where you get your clearest signal on how the sprint is actually going. Not the board; the conversation. Trade-offs being made inside the technical work need to align with where the business needs the product to land. Risks to delivery surface here before they show up as misses.

    A standup that ends in 4 minutes with zero friction isn’t efficient. It means the team is working in silos with no shared sense of where the work is heading.

  • Fly in My Soup

    A card hits done. Someone immediately finds a bug. Now there’s an argument about what to do next.

    Two options come up every time:

    1. Reopen the story and fix it there.
    2. Open a new card for the fix.

    The answer depends on the bug. If the product owner can live with it and it’s low impact, option 2 is reasonable. Log it, prioritize it, move on.

    But if the bug blocks value from reaching users, or if it was introduced while working on that exact story, the story was never done. Reopening it isn’t a punishment. It’s accurate.

    Teams resist this. Nobody wants to walk back something they already got credit for. That’s understandable, but your definition of done exists for a reason. Quality is part of it. This one slipped through.

    The soup analogy holds here. You order a bowl, find a fly in it, and send it back. The kitchen fixes it. They don’t charge you for another. The first bowl wasn’t valuable.

    Done means something. A card that shipped with a defect injected during its own development didn’t earn it. The board says otherwise, but the work tells the truth.

    Reopen it. Fix it. Move on.

  • Prioritize in a Line, Not Clusters

    A team gets handed 12 “top priorities” and then leadership gets frustrated when nothing ships on time.

    Real prioritization is a 1-to-N ordered list. One thing at the top, one thing second. Nothing shares a slot. The moment you have 3 items tied at #1 and a cluster at #4, what you actually have is a wishlist with numbers on it.

    The question that forces the issue: “We just declared this urgent. What gets pushed to make room for it?” There’s always an answer. The answer just requires someone to say something uncomfortable out loud. It should always be asked. (Sometimes it even causes the urgent thing to no longer be urgent!)

    Same logic applies when planning a sprint. When the team can’t fit everything in, ask which item drops first. Whatever that item is, you just found your lowest priority. 

    Also, many teams treat prioritization like a quarterly ritual. A big room with sticky notes everywhere, and a locked plan that isn’t supposed to change until the next quarter. But you’re shipping regularly and getting feedback. The order should adjust when the information moves. After a sprint or two of delivered work, stop and scan the list. Does this order still make sense? What have you learned? A 15-minute conversation is usually enough. The list is alive. Treat it that way.

  • Pressure Is Not a Strategy

    I’ve been in more than a few rooms where leadership is frustrated with pace. The team isn’t moving fast enough, deadlines are slipping, and someone decides the fix is to “create urgency.”

    Sometimes the word “pressure” comes up directly.

    If you believe manufacturing pressure will make the team work faster, then you don’t trust the team. That’s what the move actually says, even when no one intends it that way. It signals: “On a normal day, I assume you’re coasting. I need to introduce some fear or guilt to get real output out of you.”

    The team sees through this. Every time.

    Especially when they shift into high gear, rise to the occasion and hit the deadline, to then watch the business slow-roll the training and rollout of their work. Then a new pressure date lands on the next effort before anyone has caught their breath.

    And it produces the opposite of what was intended. They pad estimates. They stop raising problems early because problems invite more pressure. They route around whoever is asking for daily status updates. The feedback loop that was supposed to speed things up quietly chokes itself. Even worse, they work the long hours, burn out, and then claw the time back later without mentioning it.

    If the team isn’t moving as desired, dig into why. The answer is usually somewhere in clarity, capacity, process, or trust. Pressure just makes everyone quieter about whichever one it actually is.

  • Remote Teams Still Need Hallways

    Since COVID, remote work spread well beyond the offshore team or the one person who relocated. For most teams now, people are remote at least a few days a week. The physical center of the team just… stretched out.

    This reduced the small, unplanned moments that used to happen around the edges of work. Hallway conversations. Lunch chats. The five minutes after a meeting when someone says something useful because the official agenda is finally over. The tiny human details that remind you the person in the Jira ticket is an actual person, not just a Slack icon with a status dot.

    When there’s a production fire, people need to move quickly. They need to trust each other. They need to disagree without flinching. They need to assume good intent while everything is burning down and someone is asking for an ETA every few minutes.

    That kind of trust comes from shared experience. Standups and sprint cards don’t get you there. So how do you replace the hallway?

    On my last team, we had peers distributed across the eastern US and Brazil. We put an intentional social hour on the calendar each month. Sometimes it was over lunch, sometimes at the end of the day. Sometimes we had a loose activity, other times it was completely free-form. When someone new joined the team, we scheduled one relatively quickly. 

    The rule was simple: no work talk. It was time to hear about pets, kids, hobbies, travel, or whatever weird thing was happening just outside someone’s window. Just show up and be human for a bit. Sometimes that meant laughing about something small. Sometimes it meant hearing about something heavier. Both mattered.

    It gave people a low-pressure way to connect and made future small moments easier. If a meeting ended early, people were more likely to hang around and talk for a few minutes. Someone would ask about a trip, a kid, a dog, or a soccer match.

    You can’t fully recreate the hallway, but you can notice that it’s gone and do something about it.

  • Change Needs a Reason

    Change doesn’t fail because the idea was bad. It fails because the people being asked to make the change never understood why it was happening.

    I’ve seen this play out more times than I can count. A leader or team identifies something that needs to change, puts together a plan, and announces it. Adoption is slow and resistance quietly shows up in the form of workarounds, lip service, and people reverting to old habits the moment no one’s watching.

    The most common thing missing is the why. Not the organizational why, the personal why. Why is this better than what we’re doing now? Why does this make things better for me personally, or my team?

    “Why?” is an important tool in my toolkit. I’ve used it to build things up, and I’ve used it to tear things down that had outlived their purpose. It works in both directions. When people understand the reason behind a change, they stop being passengers and start taking ownership.

    If you can’t explain the why, you’re not leading change, you’re just mandating it. And mandated change without understanding produces resistance or compliance, not ownership.

    There’s one more thing that gets overlooked: all changes should be treated as experiments.

    That means going in with a hypothesis, an agreed-upon way to measure success or failure, and a stated willingness to revert if it isn’t working. “We’re trying this. Here’s how we’ll know if it’s working. If it isn’t, we’ll adjust or undo.” That framing does something important. It reduces the stakes. People are more willing to participate in an experiment than to commit to a permanent shift in how they work. And if it works, no one will want to go back.

    Change needs a reason. Make sure everyone in the room knows what it is.

  • Change Requires Slack

    If you or your team are already working at stretched capacity, there’s no room left. People are keeping up with their work, likely pushing an extra hour or two, then going home to recover.

    Now ask that same person to take a class, learn something new, and start using a tool that will slow them down before it helps. That’s a tough ask. (But the organization, the world, is asking for continuous improvement, and AI is accelerating that pressure.)

    Promises of future gains don’t mean much when someone already feels behind. Especially if that payoff is further out than they can realistically focus on.

    Change requires slack.

    In the U.S., we’re hyper-focused on optimizing every moment of the workday for value. What we forget is that value also comes from learning, adapting, and preparing for what’s next.

    Being ready means working more efficiently. Being overwhelmed means working slower.

    Slack in the work week isn’t waste. It’s what allows people to grow, try new approaches, and actually adopt change.

    If you’re leading a change effort and adoption is low, it’s worth stepping back and asking why.

    It’s not the idea.

    It’s how much oxygen remains for the fire you are trying to ignite.

  • Conformity Constrains

    I’ve seen this pattern a lot.

    An organization has many teams, and leadership wants visibility.

    So they standardize everything.

    • Same exact Scrum process
    • Standardized story point scale (“1 point = 1 dev day”)
    • Standups must be before 10am
    • Exactly 3 sprints of backlog ready at all times
    • All team sprints start and end at the same time

    On paper, it makes sense.

    It’s easier to track.
    Easier to compare.
    Easier for someone outside the team to drop in and “understand”

    But it comes at a cost.

    What happens when:

    • a team is more predictable using their own estimation scale
    • a team’s energy is higher with end of day standups
    • a team could move to Kanban and reduce process overhead
    • retros surface improvements… that don’t fit the rules

    Now the system blocks the team from getting better.

    This is the difference between guardrails and rigid process.

    Guardrails exist for a reason:

    • they create safety
    • they guide behavior
    • they can be adapted through reflection

    Rigid process is different.

    It optimizes for consistency and observability…
    at the expense of team performance.

    Not every team is the same.

    A team doing infrastructure work shouldn’t operate the same way as a team shipping software features.

    And a team that’s matured shouldn’t be held to the same structure as a team that’s just forming.

    Conformity makes things easier to measure.

    But it also keeps teams from evolving.

    And over time, that constraint becomes the bottleneck.

  • Why Self-Organization Is Faster

    Expanding on my last post about how self-organization is often blocked by leadership, not teams…

    A simple way I’ve explained self-organization to teams:

    I’ll grab two people in front of a group and run a quick exercise.

    Person 1 can give directions:

    • “take 3 steps forward”
    • “turn left”
    • “take 2 steps”

    Person 2 can only do exactly what they’re told.

    The goal is simple:
    Get from point A → out the door → to another room → and back.

    We time it.

    It’s slow. A lot of stop/start. Constant direction.

    Then we reset.

    Same goal.

    But this time, Person 2 just… does it.

    No step-by-step instruction. Just the outcome.

    And it’s always faster.

    Not because the person suddenly became more capable.

    But because:

    • they can adjust in real time
    • they don’t have to wait for direction
    • and they can solve small problems without escalation

    It’s a simple exercise, but it makes the point pretty quickly:

    If the goal is clear, most people don’t need to be told how to move every step of the way.

    And when they are, it slows everything down.

    This is what self-organization actually looks like in practice.

    Not chaos.

    Just people who understand the goal and have enough space to move toward it.

  • Self-Organization Is Usually Blocked by Leadership, Not Teams

    Self-organization usually isn’t blocked by the team.

    It’s typically blocked by leadership.

    Most teams, if you let them, will:

    figure out how to divide the work
    help each other out
    and naturally rebalance over time

    That’s where the real speed comes from.

    Where it breaks down is when managers step in and start assigning work to the “best” person.

    Usually driven by urgency.

    “I need this done quickly, give it to X.”

    It works in the moment.

    But over time, it creates a pattern:

    the same people get pulled into everything
    others don’t get stretched
    and the team never actually levels up

    Now you don’t have a self-organizing team.

    You have a few strong individuals carrying the system.

    This is one of my most common go-to observations:

    It’s rarely the team resisting self-organization.

    It’s the surrounding leadership not letting go long enough for it to actually take hold.