Skip to content

Management

Why Your Daily Standup Is Broken (And How to Fix It)

It is 9:30 AM. Eight developers join a video call or gather around a whiteboard. One by one, they take turns reciting the holy trinity of agile ritualism:

"Yesterday I worked on ticket 104. Today I'll continue working on ticket 104 and then I'll start a ticket 109. No blockers."

While one person speaks, six others stare at their shoes, check mails, or mentally rehearse what they are going to say when their turn comes. The person facilitating - usually an Engineering Manager or Scrum Master - nods, jots down a note, and moves to the next name on the roster.

Fifteen minutes later, the call ends. Everyone returns to their desks having learned virtually nothing that helps them ship software faster.

The uncomfortable truth: The Daily Standup was designed as a quick, tactical huddle for a sports team to coordinate the next play. In most software organizations, it has degenerated into status reporting theater - a daily exercise in proving to management that you were busy yesterday.

When standup becomes a roll call, it wastes time, drains energy, and masks the exact bottlenecks it was created to uncover.

Here is why your standup is broken - and how to turn it back into a high-impact engineering tool.

The Root Cause: "Walking the People" vs. "Walking the Board"

The fundamental defect in most broken standups lies in how the conversation is structured.

The Anti-Pattern: Walking the People

Most teams go person-by-person in alphabetical or random order. This forces the conversation to focus on individual activity rather than system flow:

graph TD
    subgraph Status Theater
        M[Manager / Facilitator]
        D1[Dev 1: 'Yesterday I worked on...'] --> M
        D2[Dev 2: 'Yesterday I worked on...'] --> M
        D3[Dev 3: 'Yesterday I worked on...'] --> M
        D4[Dev 4: 'Yesterday I worked on...'] --> M
    end

When you walk the people:

  1. The audience is the manager: Developers report to the authority figure instead of coordinating with each other.
  2. Accountability replaces collaboration: People feel pressured to list trivial tasks just to prove they worked eight hours.
  3. Flow is completely ignored: A critical pull request might be sitting unreviewed for four days in the "Review" column, but because the assignee says "no blockers," nobody talks about it.

The Fix: Walking the Board (Right to Left)

High-performing teams don't care about what individuals did for eight hours yesterday; they care about moving work across the finish line.

Instead of asking people for updates, you open the sprint board and walk the columns from right to left (closest to Done first):

graph LR
    subgraph Tactical Flow
        direction RL
        DONE[4. Done] -.-> QA[3. QA / Verification]
        QA --> REV[2. Code Review]
        REV --> WIP[1. In Progress]
    end

By starting at the right-most column (e.g., In Testing / Verification, then In Code Review, then In Progress), you enforce the most important principle of lean delivery:

"Stop Starting, Start Finishing."

For every ticket closest to Done, the team asks a single question:

"What do we need to do as a team to move this card into 'Done' today?"

If a PR needs a review, someone grabs it right there. If a feature is stuck in QA because an environment is broken, developers volunteer to fix it before picking up a new ticket.

Signal vs. Noise: The Standup Matrix

🔴 Status Reporting Theater 🟢 High-Flow Tactical Huddle
Order: Dev 1 to Dev 2 to Dev 3 (Roster order) Order: Right-to-Left on the Board (Closest to Done first)
Primary Question: "What did you do yesterday?" Primary Question: "What is stopping this ticket from shipping today?"
Target Audience: Manager / Scrum Master Target Audience: Teammates collaborating on delivery
Dynamic: Serial 1-on-1 conversations with passive observers Dynamic: Active swarming around bottlenecks and handoffs
Focus: Individual utilization and busywork Focus: Cycle time, WIP limits, and team throughput
Blocker Detection: Reactive ("No blockers from me") Blocker Detection: Proactive ("This ticket has been in review for 3 days, who can look at it?")

5 Practical Rules to Fix Your Standup Tomorrow

1. Ban the Classic Three Questions

Ditch the textbook Scrum questions (What did I do yesterday? What will I do today? Any blockers?). They almost always trigger defensive status monologues.

Replace them with two board-centric questions:

  1. "Is any ticket stuck, ageing, or blocked?"
  2. "What can we push across the finish line today?"

2. Enforce the "16th Minute" (Take Deep Dives Offline)

The single biggest reason standups drag on to 30 or 40 minutes is technical rabbit-holing. Two senior engineers start debating database schema migrations, while six other people wait in silence.

Adopt the 16th Minute Rule:

  • Any discussion requiring more than 60 seconds of back-and-forth is immediately tagged: "Let's take that to the 16th minute."
  • Finish the standup within 10–12 minutes.
  • Release everyone whose presence is not required.
  • The 2–3 relevant people stay on the call for the specific technical drill-down.

3. Respect WIP (Work In Progress) Limits

If you have 5 developers on your team and your board shows 11 tickets in "In Progress", your problem isn't coding speed - it's multitasking and uncompleted work.

When you walk the board right-to-left, make WIP visible: - If someone is about to pull a new ticket from To Do, ask if they can instead review an open PR or help test a feature nearing completion. - A ticket sitting in review is zero value delivered. Value is only realized when software hits production.

4. Rotate the Facilitator

If the Engineering Manager or Scrum Master always drives the standup, developers will naturally treat it as a status report to their boss.

Rotate the driver daily or weekly across all team members - including junior engineers. When a developer shares their screen and walks the board, the dynamic shifts from top-down inspection to peer-to-peer collaboration.

5. Go Async for the Monotonous Days

If your team's board is healthy, pull requests are reviewed within hours, and everyone communicates proactively on Slack or Teams, you don't need a live meeting every single day.

Try making standups async on Tuesdays and Thursdays:

  • A simple automated bot or a designated Teams thread where engineers post only blockers or cross-team requests.
  • Save live standups for days where real-time coordination is essential (e.g., sprint kickoff days, release cutoffs, or complex integration phases).

The Takeaway

A daily standup is not a management surveillance tool. Your tracking software, git logs, and DORA metrics already tell you what is happening.

The only justification for interrupting everyone's morning focus is real-time tactical alignment. If your standup doesn't help the team unblock work and finish tasks faster, change the format - or kill the meeting.

Share on Share on Share on

The AI Review Paradox: Generation vs. Comprehension

We were promised a revolution in developer productivity: type a few sentences into a prompt or let an assistant autocomplete your thoughts, and watch hundreds of lines of code appear in seconds.

And it works. Engineers are producing code faster than at any point in software history.

There is just one inconvenient problem: Writing code was never the primary bottleneck in software engineering.

The real bottleneck has always been reading, validating, reasoning about, and maintaining the code. By supercharging code generation without scaling our ability to verify it, we haven't eliminated engineering friction - we’ve merely pushed the bottleneck directly onto the code review process.

Welcome to the AI Review Paradox.

The Generation vs. Comprehension Asymmetry

Writing code is active creation; reviewing code is forensic analysis.

When an engineer writes code by hand, the pacing is naturally throttled. They think through data structures, wrestle with edge cases, rewrite helper functions, and build a mental model of the change. By the time they submit a Pull Request, they usually understand why every line is there.

graph TD
    subgraph Traditional Flow
        A[Problem] --> B[Mental Model]
        B --> C[Careful Implementation]
        C --> D[PR<br/>Author understands 100%]
    end

With AI assistants, that cognitive pipeline breaks down:

graph TD
    subgraph AI-Accelerated Flow
        E[Problem] --> F[Prompt]
        F --> G[Instant Code]
        G --> H[PR<br/>Author understands ~60%<br/>Reviewer must decipher 100%]
    end

It takes 30 seconds to generate an entire service layer with error handling, logging, and database queries. But it still takes 30 to 45 minutes for a teammate to verify whether that logic handles race conditions, adheres to domain boundaries, and respects existing architectural patterns.

When output speed increases by 5x but review capacity stays flat, the math simply stops working.

The "Looks Good To Me" Trap

When reviewers are flooded with massive diffs that look syntactically pristine, human psychology takes over.

AI-generated code has a distinct characteristic: it looks exceptionally polished on the surface. It features clean variable names, well-placed comments, sensible formatting, and believable test suites.

This creates a dangerous cognitive bias. Reviewers instinctively associate clean syntax with correct logic. Confronted with a 600-line diff on a busy afternoon, the cognitive load is overwhelming. Instead of meticulously tracing execution paths, reviewers skim the diff, see that the CI pipeline is green, and leave the dreaded:

“Looks good, merge it! 🚀”

This is how subtle bugs, security vulnerabilities, and architectural drift slip into production undetected.

The Illusion of Quality in AI-Generated Code

The risk isn't that AI writes completely broken code that crashes immediately - unit tests and CI usually catch blatant syntax errors. The real risk lies in what AI code gets subtly wrong:

  1. Plausible but Flawed Invariants: The code looks logically sound until you realize it makes subtle, incorrect assumptions about your business domain that no generic LLM could possibly know.
  2. Happy-Path Test Syndrome: AI is remarkably good at generating unit tests that test that the generated code works, rather than testing the edge cases where the code might fail. It writes tests that mirror the implementation, creating a false sense of test coverage.
  3. Architectural Inconsistency: Left unchecked, different engineers prompt AI to solve similar problems in completely different styles - introducing three different HTTP clients, two state management paradigms, and bespoke utility functions that duplicate existing codebase tools.
  4. The "Disowned Code" Dilemma: When an outage hits at 2 AM, the author who generated 400 lines of code with a single prompt often struggles to explain the exact mechanics of the fix, because they never truly built the mental model in the first place.

Pragmatic Rules for Engineering Teams

We cannot - and should not - put the genie back in the bottle. AI coding assistants are powerful tools when used with discipline. But engineering teams need new rules of engagement to survive the volume:

1. The author owns 100% of the code

The foundational rule: "The AI wrote it" is never an acceptable explanation. If an engineer cannot explain line-by-line how an algorithm works, why a specific concurrency primitive was chosen, or what happens during a network timeout, the PR is not ready for review.

2. Radical PR size limits

When writing code is effortless, PR sizes balloon. Teams must enforce strict diff caps (e.g., maximum 200–300 lines of change per PR, excluding generated lockfiles/schemas). If a feature requires 1000 lines, break it down into atomic, reviewable increments.

3. Review the tests before the code

When reviewing an AI-assisted PR, flip your usual review process:

  • Start with the test cases.
  • Look specifically for missing negative tests, boundary conditions, and null/empty state handling.
  • If the tests only verify the happy path, reject the PR before spending time reviewing the implementation.

4. Shift-Left: align on design, not just diffs

If an engineer spends 10 minutes discussing the interface design and architectural approach with a peer before prompting an LLM to generate the implementation, the resulting code will be much cleaner, more cohesive, and faster to review.

The bottom line: velocity isn't typing speed

The ultimate goal of software engineering has never been to maximize the rate of keystrokes. It has always been to deliver reliable, maintainable business value with minimum complexity.

AI is a powerful force multiplier. But if your team uses it merely to generate larger volumes of code without raising the bar on comprehension and review rigor, you aren't increasing velocity - you're just accelerating your path to technical debt.

Share on Share on Share on

Risk Management in Software Development

Recently, I wrote about how to measure developer progress without the drama. Today, let's tackle the other side of the same coin: risk management.

At first glance, measuring progress and managing risk might look like two separate items on an engineering manager’s checklist. But in reality, they are deeply connected.

Measuring progress is your radar; risk management is your steering wheel. – Without the radar, you won’t see the iceberg coming. Without the steering wheel, you can see it clear as day and still crash right into it.

The primary goal of both tracking progress and managing risk isn't to micromanage developers or blindly check off Jira tickets. It’s about spotting course deviations as early as possible so you can deliver real, working value.

We've already discussed how to measure progress. So, how do you handle risk? The key is treating it as a living, breathing daily ritual for the team - not a static document created at project kickoff and promptly forgotten on Confluence.

1. Spotting and Categorizing Risks

In software engineering, risks generally fall into three main buckets:

  • Technical: Sprawling tech debt, unstable 3rd-party APIs, unverified performance bottlenecks, or tricky data migrations.
  • People & Team: High Bus Factor (critical domain knowledge trapped with single individuals), team turnover, burnout, or key skill gaps.
  • Process & Business: Scope creep, vague requirements, client or Product Owner approval delays, and shifting compliance or legal mandates.

2. Preventive Moves: Mitigating Risk Proactively

Run Spikes & Proofs of Concept (POCs)

When tackling tasks wrapped in uncertainty or unknown tech, don't rely on wild estimates. Schedule a quick 1- to 2-day Spike to build a Proof of Concept (POC). This short research task uncovers hidden gotchas, clarifies requirements, and prevents deep underestimations before they wreck your sprint.

Address the "Bus Factor" and Decision Bottlenecks

The single point of failure - often colloquially (and dramatically) called the Bus Factor (how many team members need to get hit by a bus before the project grinds to a halt?) - is frequently ignored until it's too late. A common variation is the decision bottleneck, where everyone waits on one key dev to approve every pull request or technical detail.

  • How to spot it: Build a quick Skills Matrix. It instantly highlights missing capabilities and knowledge silos across the team.
  • How to fix it: Be intentional about knowledge sharing. For software teams, nothing beats pair programming and cross-training on unfamiliar modules.

Keep a Living Risk Register

Maintain a lightweight Risk Register (e.g., in Confluence or a dedicated Jira board). Don't leave it in a virtual drawer - review and update it regularly during your sprint retrospectives or reviews. This simple habit eliminates nasty surprises right before launch.

Buffer & Scope Stripping

Define your MVP upfront and clearly separate core requirements from "nice-to-haves." When planning sprints, never load your team up to 100% capacity. Leave an explicit 20% safety margin (plan at 70–80% velocity). As Murphy’s Law reminds us: If something can go wrong, it will.

Quick Mitigation Summary

Mechanism How it Works in the Team What it Mitigates
Spike / POC (Proof of Concept) Short (1–2 day) research task before estimating complex modules. Technical uncertainty & major estimation blunders.
Cross-training & Pair Programming Intentional knowledge sharing across modules with non-authors. High Bus Factor & single-person bottlenecks.
Living Risk Register Lightweight table reviewed routinely during retros or reviews. Nasty surprises right before release.
Buffer & Scope Stripping Planning at 70–80% capacity while explicitly tagging MVP vs. Nice-to-Haves. Missed critical deadlines & burnout.

3. How Progress Tracking & Risk Management Work Together

Early Warning Systems (Leading Indicators)

Progress metrics are your best early indicators of rising risk.

  • Progress Signal: You notice a sudden spike in Cycle Time (tasks jumping from 3 days to 8) alongside surging Work in Progress (WIP).
  • Risk Action: This signals an underlying technical issue (e.g., hidden tech debt, complex API dependencies) or a team roadblock (e.g., code review bottlenecks). You can intervene before it derails the milestone.

Feedback Loops & Scope Control

Both tools exist to help you make scope decisions based on hard data rather than gut feelings.

  • Progress Signal: A Burnup Chart shows that at current velocity, the team won't ship all planned features by launch day.
  • Risk Action: Trigger your mitigation protocol: execute Scope Stripping. Pare down features to the essential MVP and push non-critical items to the backlog.

Empiricism vs. "Hope Strategy"

One of software development's biggest traps is the illusion of progress (a.k.a. the notorious "99% done" syndrome).

  • The Shared Principle: Neither progress nor risk reduction should rely on optimistic status updates in Jira ("I'm almost done!"). Both rely strictly on tested, working code deployed to integration or staging environments.

Technical Debt & Code Quality

Unaddressed tech debt is a classic risk that directly drags down velocity and stability over time.

  • Progress Signal: Key DORA metrics like Change Failure Rate (percentage of deployments causing outages) and Mean Time to Restore (MTTR) begin to climb.
  • Risk Action: Rising failure rates mean system stability is critically endangered. The team must pause new feature delivery to focus on refactoring, automated testing, and reliability spikes.

Task Bottlenecks & Knowledge Silos

  • Progress Signal: Tasks assigned to a specific individual or module sit in In Review or In Progress significantly longer than others.
  • Risk Action: The metrics surface a high Bus Factor risk. The team immediately mitigates this by pairing developers or reallocating review responsibilities.

Share on Share on Share on

How to Measure Devs Without the Drama

A friend recently asked me:

"How do I measure my team's performance without breaking either the product or the team?"

At first, I thought the answer was obvious.

Then I remembered how many engineering teams I've seen optimizing for the wrong things. Managers tracked story points, commit counts, or bugs closed. Dashboards looked great. The product didn't. Worse, the metrics created incentives that turned developers and QA into adversaries instead of teammates.

The golden rule of engineering management is simple: people optimize for how they're measured (Goodhart's Law). Pick the wrong metrics, and your team will optimize them perfectly — even if the product suffers. The challenge isn't collecting more data. It's separating the few metrics that signal real engineering health from the many that create noise.

The Ultimate Cheat Sheet: Signal vs. Noise

🟢 The Pure Signal 🔴 The Distracting Noise
Cycle Time: How fast an idea becomes live code. Velocity & Story Points: Purely internal tool for tasks estimation.
Deployment Frequency: Shipping small and shipping often. Lines of Code: Encourages bloated, messy software.
Change Failure Rate: How often things blow up. Bug Count per Capita: Turns Dev vs. QA into a civil war.
Mean Time to Restore (MTTR): How fast you fix the blow-ups. Commit Volume: Rewards messy, fragmented work.

What to Actually Watch

Modern engineering leaders rely on DORA metrics. They don't look at how hard individuals are typing, instead, they measure the fluid mechanics of the delivery pipeline and system stability.

Cycle Time

The clock starts when a dev types their first line of code and stops when it hits production. Shorter cycle times mean your tasks are small, your code review process is crisp, and your pipeline is free of bureaucratic roadblocks.

Change Failure Rate & MTTR

This is the ultimate playground where Dev and QA meet. What percentage of releases trigger immediate rollbacks or emergency patches? When a fire does break out, how quickly can the team put it out? High stability means your QA safeguards are robust and your monitoring is sharp.

Escaped Defects

The bugs that slipped through the cracks and were caught by your actual users. If this number spikes, it is a clear sign that your testing strategy needs an upgrade (e.g., missing automated regression tests), not that your QA team isn't trying.

Mute the Noise: The Vanity Metrics to Delete

Some metrics feel comfortable because they are easy to plot on a chart, but they actively incentivize terrible behavior.

Take Velocity (Story Points). Story points are designed for internal sprint planning and delivery estimation, not as management currency. If you demand a higher velocity, your team will simply start estimating a 2-point task as a 5-point task. Voilà! Productivity magically "doubles" on paper, while output stays exactly the same.

Similarly, tracking the number of bugs fixed or found per person is a recipe for disaster. If you reward QA for finding bugs, they will log every single missing pixel or typo as an individual critical ticket. If you judge Devs on bugs closed, they will spend their afternoons arguing with QA that a broken button is "actually a feature, not a bug."

Pro-Tip on Team Synergy:

Keep an eye on the "Bounce Rate"—how often a task fails QA and gets kicked back to development. A high bounce rate points to poor communication during refinement, meaning Devs and QAs are not aligning on requirements before the code is even written.

The Takeaway

Stop micro-managing tickets and start managing the flow. Your goal as a manager isn't to make sure everyone looks busy - it's to ensure that high-quality, stable software moves smoothly from a developer’s brain out to the real world. When Dev and QA share ownership of the entire pipeline instead of playing the blame game, performance takes care of itself.

Share on Share on Share on