Learn modern project management strategies, release planning, QA integration, and team scaling. Insights for engineering leaders and project managers.
Your codebase has 47 active feature flags. Five are documented. Three are tied to features shipped nine months ago and no one thought to remove them. Two conflict with each other: enabling both at the same time produces undefined behavior. You have just discovered why feature flags are not free.
The team spent three weeks modeling the bounded contexts, aggregates, and domain events of their content management application. The application does CRUD on five tables. That is the sign that DDD is being used as an end in itself, not as a tool.
"We need a technical debt sprint." This phrase is spoken in hundreds of teams every quarter. What happens next: two weeks of refactoring without clear direction, whose value is impossible to communicate to management, and which doesn't fundamentally change the most painful problems.
How many days does a new developer spend trying to get the project running locally before they can actually contribute? In most teams, the answer is somewhere between two and ten days. The onboarding documentation exists - it's just wrong.
How many times have you had a 1-on-1 where your manager opened Jira to review your current tickets? That meeting could have been an email, or a glance at the Kanban board. A 1-on-1 that looks like a status report is a wasted 1-on-1.
Your team has a Notion page with next quarter's plan. It was written last week. Three people added comments. Two reacted with an emoji. The plan hasn't changed. No decision has been made. That's async without guardrails: lots of activity, little resolution.
When is an epic done? The question should have a simple answer. In practice, in most teams, it triggers a long conversation. The epic grows, splits, reopens, migrates from sprint to sprint. That is not a Scrum implementation problem. It is a definition problem.
"Our velocity is 42 points per sprint." This sentence is spoken with pride in hundreds of planning meetings every week. What does it actually say? That the team is closing tickets at a consistent pace. What it does not say: whether those tickets create value, whether the estimates are realistic, whether the team is thriving.
How many times have you seen a release turn into a catch-all of half-finished features, last-minute fixes, and tickets migrated from three previous sprints? The release has lost its meaning because it is only used as a delivery container, not as a management tool.
"As a user, I want to be able to log in so that I can access my account." This ticket has been written millions of times. It describes nothing useful about what the developer needs to do. That is the central problem with the user story as a unit of work.
