Agile

I’ve been participating in fully-remote software standups every day for over a decade, and over the past two years, leading them, too. Here’s how I run the best standup meetings that I can. Guiding Principle: Physically Stand Standups got their name because people physically stood up during them; use that as a guiding principle. I don’t stand up, nor do people on my team, and not everyone can. But, the idea is to keep the meeting tight. Standups shouldn’t be long. They should not be something you can step away from for ten minutes to flip the laundry. ...

There’s an enviable quality of great engineers I’ve known: they seem to get things right the first time. When you ask them to do something, and they say “It’s done”, it is, almost always. How? Here, I think there actually is “one weird trick.” It’s a bit tedious, but it compounds and is dead simple. It’s checking your work before delivering. Agile Foundations I did not invent this idea. It’s core to many folktales and fables, and also to Agile software development. ...

This year I’ve run over 25 Scrum refinement meetings; here’s what I’ve learned. This post will cover: What is refinement, and why does it matter? Two counterarguments, refuted! My step-by-step approach Notes on pointing bugs Let’s dive in. What is Refinement? (Backlog) Refinement is a process of improving tickets so they are understood by the whole team and ready for work. Refinement turns chaff like this: “Design for error on download screen” ...

Acceptance criteria, or AC, describe what a feature or bugfix does. Writing them is an art, and some AC work much better than others. So, how do we make them work? By including a little more detail. Let’s explore the goals of AC, a standard example, an example that works better, a few counterarguments, and how to write great AC with ease. Goals of AC: “Right Thing”, “Thing Right”, Documentation What are the goals of AC? They should: ...

Confluence was messy. Our documentation felt outdated, hard to navigate, and unreliable. Rather than scrap everything and start over, I decided to try something different: a Kaizen. Here’s what we did, what we learned, and how it went. What is a Kaizen? Kaizen is a Japanese business philosophy that can be translated to mean “Change for the better.” It can be an event, too. Before this experiment, I’d observed a Kaizen workshop once in a factory, but I’d never led one myself, or heard of one done on a software team. ...

Jira does have a “Start Standup” button, but it’s hidden and not well documented. To enter start a standup in Jira, open an active Kanban-style board. If there’s a “Start Standup” button in the upper right (this appears to be experimental), click it. Your board converts to a simplified standup presentation! On the left, each team member is listed in random order, which you can shuffle. I like to mix up the order of reports every day, so this feature helps me do that. Teammates can also be skipped. ...

I recently calculated that I merge 0.8 pull requests every day into my team repo. Let’s round up and say I merge about one PR every day, delivering one or more features to production. I like this velocity, and in this post, I’ll explain how you can achieve it yourself. My ideal day as an IC goes like this: Morning: start a ticket Early morning/early afternoon: open a PR Early afternoon: respond to comments and merge PR Afternoon: deliver work to a QA environment Late afternoon: deploy to production This doesn’t happen by accident. It’s the result of processes— mine and my team’s. These are the ingredients of those processes. ...

When I don’t feel like I’m making sufficient progress at work, I have a favorite technique: asking “What would finishing this today look like?” It’s a version of one of Tim Ferriss’ favorite questions: “‘What would this look like if it were easy?’ If I feel stressed, stretched thin, or overwhelmed, it’s usually because I’m overcomplicating something or failing to take the simple/easy path because I feel I should be trying ‘harder’…” ...

When preparing feature development work, I write Gherkin-style tickets, which follow the “Given/When/Then” format. Many people call these stories, and I do, too. This technique is incredibly effective! But why? In this post, I’ll try to answer that question. I learned this technique watching the greats at Hashrocket. They’ve been doing it this way since 2008 because it works. I have two complementary arguments for this technique: images and raw text hide complexity, while stories reveal complexity. ...

Action items are small, defined, actionable TODOs to follow up on after the meeting. An example: “close all pull requests opened more than 90 days ago.” Agile retrospectives should produce many of these. Why Are They Important? Action items steer a retro away from conversation and toward action. I once worked with an engineer who ran retros among all the contractors on the project. He’d push for action items after every discussion, saying: “I want to respect everyone’s time by making sure this leads to action.” ...