The never-ending methodology debates are exhausting. “Agile or Waterfall? “Are we doing Scrum correctly?” “Should we use Kanban instead of Scrum?” “What about an agile scaling framework?” “When will this “agile” fad blow over?” I see these questions constantly followed by answers from “Agile experts” who will happily quote the…

In a conversation about what activities senior developers should be doing, there was a general alignment on activities such as mentoring and growing more seniors, working on design, working directly with stakeholders, etc. …

Recently, I’ve had conversations about team structure, specifically whether development teams should be organized around features or product capabilities. During those conversations, it became clear that Large Scale Scrum (LeSS) agile coaches are adamant that teams should be organized around features. …

Several years ago, I posted “You Don’t Need Story Points.” I said, “Just make things small.” One thing I neglected to do was explain how. Here’s how we did it. tl;dr: Use BDD and stop wasting time fantasizing about fake numbers. Background We were trying to implement a continuous delivery workflow…

The waiting is the hardest part Every day you get one more card You take it on faith, you take it to the heart The waiting is the hardest part “The Waiting”, Tom Petty and the Heartbreakers, 1981 Tom Petty understands one of the biggest problems in software delivery. …

I wrote a paper a couple of years ago called “How to Misuse and Abuse DORA Metrics” based on real-world experiences using metrics to help teams identify constraints and the appalling and destructive ways others used them in the industry. Recently, McKinsey released their “Developer Productivity” framework that reads like…

In the 1993 movie “Malice,” Alec Baldwin's character, Dr. Hill, is being sued for malpractice. When asked, “Do you have a god complex?” Dr. Hill responds with something that sounds eerily familiar to the attitudes of some peers I’ve come across in my career: “I have an M.D. from Harvard…

Large teams cannot deliver anything quickly. There is too much internal communication drag. The entire point of working this way is rapid feedback. Too many focus on the mechanics Scrum teaches instead of the goals. The problem you're seeing with small teams is the same problem you see when people decide to build microservices without any understanding of DDD. Lacking any focus coupling issues, they create a distributed monolith. Same with team structure. Because they don't focus on decoupling the teams, they have one, giant, badly communicating team and then try to manage those dependencies with something like SAFe. Small teams can accelerate feedback loops if the architecture is also improved to decouple the teams. Starting with small teams to build something new is easier than refactoring the org and a legacy application, but I've helped with the latter, and it's dramatically better than the alternatives.

I recently gave a talk called “Agile Rehab” at QConNYC 2023 about the techniques we used to transition from delivering once per quarter to delivering multiple times per day. We did this by ditching SAFe and taking Continuous Delivery and software engineering seriously. We asked ourselves, “Why can’t we deliver…