Is breaching WIP always bad?
In a Slack conversation recently, someone asked “Isn’t it a big assumption that breaching WIP is always bad?” It’s a great question, and the answer is more interesting than it first looks.
Your teams aren’t broken
Companies sometimes bring me in with the mandate: “fix my teams”. Other times it’s not said quite that directly, but the message is clear. Leadership has decided that something is wrong with the people doing the work, and I’ve been hired to correct it.
Turn off your self-view
When COVID hit and we all switched to video calls overnight, everyone started reporting how tired they were at the end of a day of meetings. Part of that was obviously that we were in a pandemic and stress levels were high, and yet there was something in the video meetings themselves that made it so much worse.
The case for real collaboration
I recall introducing pair programming to a team years ago. During the first round of pairing it just so happened the the most senior person on the team (20 years working on the same code base) got paired with the most junior (recent graduate from school on her first job). Mostly likely everyone assumed that the senior would be hand-holding the junior through the exercises, and yet when we got to the debrief, there was a surprise.
Critical thinking and the headlines we share
Yesterday, I kept seeing this story repeated about Stripe and the new AI model from Anthropic. The claim is the AI was able to do in one day what it would have taken months for the existing teams to do.
The people I’ve been warned about
When I first arrive in a new engagement, it’s not uncommon to be warned about specific people. “Bob will push back on everything you say” or “Janet just won’t play along”. The warnings are usually well-intentioned, with helpful colleagues trying to prepare me for what’s ahead.
The month they worked on nothing
I once had a client that decided to cancel a project before they had anything prepared for the team to work on next. This was actually a great opportunity; the team could have spent that time improving their own skills, paying back some technical debt, or catching up on the thousands of things that normally don’t get attention.
Why Agile’s early feedback signal keeps getting ignored
Agile made a specific promise: you’ll know about problems early enough to do something about them. Not after the deadline passes, but early enough to make a difference. That promise starts with working, tested software on frequent intervals so you can see what’s actually done, not just what’s reported. It’s also why the agile community embraced probabilistic forecasting; rolling Monte Carlo simulations that tell you weeks or months in advance whether you’re on track.
AI shifted your bottleneck. Do you know where it went?
Recently I ran a session at Okanagan Agile, our local agile meetup, on what happens to a development team when AI makes coding dramatically faster. Before we got into the theory, I wrote each step of a typical delivery workflow on paper cards and laid them end to end on the table. It sounds simple, and it is. But being able to point at a card and say “this is where things are piling up” changes the conversation from abstract to concrete in a way that a slide never does.
The vacation test
I once worked for a manager who never made a decision. He was thoughtful, well-intentioned, and completely committed to having all the right information before doing anything. I’d suggest a change and he’d say “let me think about that”, and then nothing would happen.