Tag: agile
Posts
Agile Is Not Dead — the Cargo Cult Version Deserved to Fail
The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong.
What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Posts
Definition of Ready Is the Guardrail That Sprint Planning Needs
Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.
Posts
Fixed-Price Contracts and Agile Development Are Structurally Incompatible
The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer
When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Posts
Splitting User Stories Is a Skill Most Teams Develop Too Late
The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.
Posts
Technical Debt Belongs in the Backlog, Not in Side Conversations
Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.
Posts
The #NoEstimates Argument Deserves to Be Taken Seriously
The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.
Posts
The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.
Posts
The Product Owner Role Is Harder Than Most Organizations Treat It
The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly.
The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.
Tag: agile-ceremonies
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Posts
The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.
Tag: agile-contracts
Posts
Fixed-Price Contracts and Agile Development Are Structurally Incompatible
The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.
Tag: agile-manifesto
Posts
Agile Is Not Dead — the Cargo Cult Version Deserved to Fail
The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong.
What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.
Tag: ai-assisted-development
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Posts
The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.
Tag: architecture
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Tag: backlog-refinement
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Definition of Ready Is the Guardrail That Sprint Planning Needs
Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.
Tag: client-relationships
Posts
Fixed-Price Contracts and Agile Development Are Structurally Incompatible
The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.
Tag: coaching
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Tag: code-quality
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Tag: code-review
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Tag: continuous-delivery
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Tag: daily-standup
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Tag: definition-of-done
Posts
The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.
Tag: definition-of-ready
Posts
Definition of Ready Is the Guardrail That Sprint Planning Needs
Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.
Tag: deployment
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Tag: devops
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Tag: distributed-teams
Posts
Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer
When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.
Tag: engineering
Posts
Technical Debt Belongs in the Backlog, Not in Side Conversations
Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.
Tag: engineering-craft
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Tag: engineering-culture
Posts
Agile Is Not Dead — the Cargo Cult Version Deserved to Fail
The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong.
What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Tag: engineering-discipline
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Tag: engineering-leadership
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Tag: estimation
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
The #NoEstimates Argument Deserves to Be Taken Seriously
The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Tag: judgment
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Tag: kanban
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Tag: noestimates
Posts
The #NoEstimates Argument Deserves to Be Taken Seriously
The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.
Tag: organization
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: pair-programming
Posts
AI Pair Programming Has Not Eliminated Code Review — It Has Made It Harder
The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed.
When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.
Tag: planning
Posts
The #NoEstimates Argument Deserves to Be Taken Seriously
The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.
Tag: planning-poker
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Tag: process
Posts
The Definition of Done Needs to Account for How the Code Was Built
The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later.
AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.
Tag: product-backlog
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Technical Debt Belongs in the Backlog, Not in Side Conversations
Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Tag: product-management
Posts
The Product Owner Role Is Harder Than Most Organizations Treat It
The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly.
The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.
Tag: product-owner
Posts
The Product Owner Role Is Harder Than Most Organizations Treat It
The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly.
The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.
Tag: project-management
Posts
Fixed-Price Contracts and Agile Development Are Structurally Incompatible
The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.
Tag: prompt-engineering
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Tag: remote-teams
Posts
Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer
When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.
Tag: requirements
Posts
Requirements Writing Is Now a Core Engineering Skill
For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together.
AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Tag: retrospectives
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Tag: roles
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Tag: safe
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: scaling-agile
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: scrum
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Posts
The Product Owner Role Is Harder Than Most Organizations Treat It
The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly.
The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Posts
The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Tag: scrum-master
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Tag: software-craft
Posts
The Decisions That Remain Irreducibly Human
The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why.
Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.
Tag: software-delivery
Posts
Continuous Delivery Is Not a DevOps Practice — It Is an Agile Foundation
Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.
Tag: software-design
Posts
Architectural Coherence Is the Discipline That AI Cannot Substitute
Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.
Tag: software-development
Posts
Agile Is Not Dead — the Cargo Cult Version Deserved to Fail
The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong.
What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.
Tag: sprint-goal
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Tag: sprint-planning
Posts
Backlog Refinement Is the Most Underrated Practice in Scrum
Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function.
A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.
Posts
Definition of Ready Is the Guardrail That Sprint Planning Needs
Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer.
A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.
Posts
Splitting User Stories Is a Skill Most Teams Develop Too Late
The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.
Posts
The Sprint Goal Is the Most Skipped Part of Scrum
The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.
Tag: sprint-review
Posts
The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.
Tag: stakeholder-engagement
Posts
The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.
Tag: story-splitting
Posts
Splitting User Stories Is a Skill Most Teams Develop Too Late
The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.
Tag: tdd
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Tag: team-communication
Posts
The Daily Standup Has Three Failure Modes and Teams Hit All of Them
The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately.
The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.
Tag: team-dynamics
Posts
Planning Poker Works, But Not for the Reason Most Teams Think
Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.
Posts
Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer
When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.
Posts
Retrospectives That Change Nothing Are Worse Than No Retrospective
The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.
Posts
The Scrum Master's Real Job Is Organizational, Not Ceremonial
The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.
Tag: team-performance
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Tag: team-structure
Posts
How AI Has Shifted the Leverage Points in Engineering Teams
Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.
Posts
Most Teams Adopting Scaling Frameworks Do Not Need Them
The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.
Tag: team-velocity
Posts
What Sprint Planning Looks Like When Throughput Has Doubled
Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for.
When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.
Tag: technical-debt
Posts
Technical Debt Belongs in the Backlog, Not in Side Conversations
Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.
Posts
Technical Debt in the AI Era Is Accumulating at a Different Rate
Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse.
AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.
Tag: testing
Posts
Testing AI-Generated Code Requires a Different Default Posture
Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally.
AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.
Tag: tools
Posts
Prompt Engineering Is a Software Discipline, Not a Workaround
The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost.
Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.
Tag: user-stories
Posts
Splitting User Stories Is a Skill Most Teams Develop Too Late
The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.
Posts
User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.
Tag: velocity
Posts
Velocity Is a Planning Tool, Not a Performance Metric
Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.
Tag: workflow
Posts
Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.