Reading time: 90 seconds

In QualiMente’s Secure Cloud team retrospective on Friday, we identified a couple of improvement actions:

Improvement Actions from Friday’s Retrospective

For context, we are several weeks into building a new service called k9 that helps people and access analysis tools understand “who has access to what” in AWS.

As product owner and team lead, I prioritized building something useful in order to learn about the domain and get feedback from customers over internal aesthetics I expected to change. As with many new projects, we know a lot more about the problem domain and even the underlying AWS security services than we did a month ago. Also, ‘code review’ was the skill we focused-on learning last week as part of our continuous improvement efforts.

Now we’re converging the product’s internal structure closer to the newly-learned reality before expanding the feature set. We started some of that refactoring in the middle of last week. Some of these refactoring efforts were glommed onto a significant feature addition and everyone ended up agreeing that change was too large.

In our retrospective, we decided to make a couple behavioral changes related to refactoring and code reviews:

  • Perform small refactorings within feature stories, but create a dedicated story for a large refactoring. (1)
  • Reviewers should be stricter about improving code when they see it as opposed to letting issues grow.

We’re also going to create a checklist to support k9 change authors and reviewers.

This story was entered right after our retrospective and filled-out a bit this morning when I groomed the backlog:

Story to create a code review checklist
Story to create a code review checklist

This checklist will build on QM’s standard code review checklist by prompting for the behavioral changes we want to make in our code review process and failure-handling guidelines that are important for security work. Naturally, this checklist will evolve over time.

Zzzt! Our feedback loop is closing.

I hope yours does, too.


(1) Yep, there are a number of tradeoffs when modeling refactoring as a discrete story or task, particularly: visibility, measuring throughput, and predicting releases