My boss Cedric once gave me an idea that reshaped how I thought about code reviews and about dev tasks:

The code review is an accountability conversation

An accountability conversation is one where you address broken commitments or unmet/violated expectations. The books to read on this are Crucial Conversations and Crucial Accountability.

Looking at the code review in this light, the reviewer is checking whether “expectations” were met:

  • Does your feature work as desired?
  • Did you finish in the allotted time?
  • Does your solution architecture fit the problem and the environment?
  • Did you follow the team’s accepted coding practices (tests, patterns, etc.)?

So far so good. But as I unpacked the idea further, it hit me: why are we having the accountability conversation after the work is already done?

Look at how a single developer typically works on a task:

Waterfall (Original image from Wikipedia, edited using Pixlr)

“Hey, that’s Waterfall!” You’re right. It is.

Let’s rethink how a developer could be more agile here. Remember, agile is about short feedback loops. The easiest way to avoid unmet expectations is quick, short conversations early and often.

In conversation terms, it’d sound like this:

  • With the product owner:
    • “Here’s what I think you need the feature to do. Are we on the same page?”
    • “Here’s how the UX is looking so far. What do you think?”
  • With the PM:
    • “What are our time and budget constraints for this feature?”
    • “Here’s how long I think this will take to implement. Does that work?”
  • With the Tech Lead and other teammates:
    • “Here’s how I am thinking of building this feature, and here’s why. Do you see any potential issues?”
    • “This piece is taking me longer than expected. Can anyone help?”
  • With the QA:
    • “What users, workflows, edge cases, etc. should I keep in mind?”
    • “What UI and API testing do you recommend?”
    • “Are there any cross-functional concerns and contract testing involved?”
    • “Are there any 3rd party vendors involved?”
    • “Which browsers and OS’s do we need to support?”
    • “Are there any non-functional concerns like accessibility, security, performance/load testing that I should keep in mind?”
  • Along the way, you discuss tradeoffs explicitly:
    • “This solution is hacky, but given the time constraints it’s our best option. Does everyone agree?”
    • “We’re taking on some technical debt here, when can we revisit and refactor this?”

By the time you get to 100% done, you’re not only super-confident of having built the right thing, so is the product owner, tech lead, QA and PM. The code review and QA process goes super-smooth. The team saves time.

The entire process might look like this:

  1. Before coding: Set an upfront contract
    • Understand the requirements and review the UX with the product owner
    • Confirm estimates and time/budget constraints with the PM
    • Discuss your planned technical design with the architect or tech lead
    • Discuss your test plan with the QA
  2. 10-20% checkpoint:
    • Develop a small vertical slice of end-to-end functionality
    • Discover the major technical hurdles, and revisit with the tech lead if needed
    • Revisit initial estimates and notify the PM if you anticipate major deviations
    • Do a mini-demo with the product owner to verify UX assumptions, if heavy UX work is involved
  3. 50% checkpoint:
    • Another checkpoint with PM / tech lead / product owner - depending on where you see the maximum uncertainty.
    • Notify them of progress and roadblocks. Ask for help. Pivot if need be.
  4. 90-100%:
    • Desk check with the QA
    • Code review end-to-end with the tech lead or a peer
    • Full demo to product owner
    • Minor adjustments as needed

This may sound tedious, but it’s actually faster. By having 2-to-5 minute conversations and mini-demos early in the process, course correction is faster and bugs are reduced. Rework due to misunderstood requirements goes to zero.

In summary: being Agile applies just as much to small tasks as to big features. The key is quick feedback. The more conversations early and often, the closer our product will be to what the customer needs.

p.s. If you’ve implemented this idea too - can we talk? Please reach out, I would love to pick your brain.