Posts

Piling in fresh people onto a late project is rarely the quick fix managers hope for. Brooks’ Law is real: adding manpower to a late project makes it later. When new people arrive, productivity usually plunges while the team absorbs them. Veterans spend time teaching instead of building, and team recovery is slow moving - if it does at all. Hiring can help over the long haul, but as a fast remedy it’s a gamble. Often budgets won’t allow more staff, so the practical levers are scope, quality, and how the current team works together. ...

It’s our job to kill dangerous hope early. Hope lets teams give optimistic answers that hide real progress. That’s how projects quietly fail. Instead we should aim to gather hard data every iteration so managers, product owners, and stakeholders can make real decisions instead of wishful guesses. This isn’t about going faster - it’s about learning the truth as soon as possible so we can manage trade‑offs effectively. Delivering hard facts quickly gives us options; clinging to hope removes them. I encourage teams to treat iteration feedback as a tool for making pragmatic, timely choices. ...

Agile development isn’t “Waterfall sliced into smaller pieces” Too often we treat iterations like mini-projects: Analysis at the start Coding in the middle Testing at the end But that’s not Agile — that’s Waterfall on shuffle mode. In true Agile development, requirements, architecture, design, and implementation happen continuously throughout the iteration. We learn → adjust → build → validate → repeat. This flow isn’t a sequence — it’s a rhythm. ...

When starting a project, it’s tempting to grab every shiny tool—MongoDB, Kafka, React, Terraform. But each one adds cost: learning, debugging, lock‑in, maintenance, and version headaches. The cheapest tool? Not using it. (Yet!) Start Simple Begin with the plainest possible solution. Before installing a database, ask: Can text files work? Can a folder of binaries work? Can an in‑memory map power the prototype? Often, you can go surprisingly far without extra tools. And when you finally need one, you’ll choose it based on real needs—not guesses. ...

A team creates a user story for a full calendar feature. The PO, BA, UX, and accessibility SME add pages of detail so developers have everything they need. When developers see the ticket, they know it’s far too big. It needs splitting—but rewriting all that detail feels time‑consuming, inconvenient, and no one volunteers to do it. So the team decides to work on the giant story as-is and “figure out the rest later.” ...