Agile Fundamentals

Here is the uncomfortable truth about Agile in 2026: most organizations practicing "Agile" are doing ceremony-driven development, not value-driven development. They have standups, sprint planning, retrospectives, and a Jira board. They call themselves Agile. But they are just doing waterfall in two-week increments.

The Agile Manifesto was written in 2001 by 17 software practitioners who were frustrated with heavyweight processes. It contains 4 values and 12 principles. The entire thing fits on a single page. And yet an industry of certifications, frameworks, and consultancies has been built on top of it, often obscuring the original intent.

The 4 Values, Practically Interpreted

The 12 Principles: The Ones That Actually Matter

I will not list all 12, because honestly, some overlap. But three principles have had the most impact on how I run delivery:

• "Deliver working software frequently." This is the heartbeat of Agile. Not every two weeks because someone decided sprints should be two weeks. Frequently means as often as your context allows. Some teams deploy 50 times a day. Some deploy once a month due to regulatory constraints. The principle is: shorten the feedback loop as much as possible.
• "The best architectures emerge from self-organizing teams."This is a direct challenge to the command-and-control PM. Your job is not to assign tasks. Your job is to ensure the team has clarity on what needs to be built, why it matters, and what "done" looks like. Let the team figure out how. If you are assigning tasks in Jira, you are the bottleneck.
• "At regular intervals, the team reflects on how to become more effective." This is the retrospective principle, and it is the most powerful one. A team that consistently improves its process will eventually outperform a team with a better starting process. Continuous improvement is not optional in Agile. It is foundational.

Scrum is the most widely adopted Agile framework, and also the most widely misapplied. Let me walk through the roles, events, and artifacts as they are defined, and then tell you what actually works in practice.

The Three Roles

Product Owner: Owns the product backlog and maximizes value. In theory, this is one person who makes all prioritization decisions. In practice at large organizations, I have seen PO committees, rotating POs, and POs who are actually business analysts with a fancy title. The dysfunction is always the same: when nobody has final say on priorities, everything is priority one.

Scrum Master: Facilitates the process and removes impediments. The most misunderstood role in tech. A good Scrum Master is a team coach, not a meeting scheduler. They observe team dynamics, challenge ineffective behaviors, and protect the team from organizational dysfunction. A bad Scrum Master is just a project manager who renamed their title. If your Scrum Master is updating Jira tickets and chasing status updates, they are not doing Scrum Mastery.

Development Team: Cross-functional group of 5-9 people who do the work. The Scrum Guide says no titles within the team. In reality, you have senior engineers, junior engineers, QA, and sometimes UX. The principle is important though: the team owns the work collectively. No single person owns a story. This creates shared accountability and reduces bus factor.

The Five Events

Kanban is the framework people underestimate because it looks simple. A board with columns. Cards moving left to right. No sprints, no roles, no prescribed events. But Kanban's power comes from its focus on flow, and the discipline of WIP limits.

The Four Core Principles

1. Start with what you do now. Kanban does not require a process revolution. Map your current workflow onto a board. No need to adopt new roles or rename anything. This is why Kanban is often easier to introduce than Scrum: there is no organizational change required to start.
2. Agree to pursue incremental, evolutionary change. Improve gradually. Do not redesign the entire workflow in one go. Change one thing, measure the impact, then change the next thing.
3. Respect current roles and responsibilities.No one needs to be renamed "Scrum Master" or "Product Owner." Keep your existing structure. Optimize it.
4. Encourage leadership at all levels. Anyone on the team can identify an improvement and act on it. This is not a top-down framework.

WIP Limits: The One Practice That Changes Everything

Work in Progress limits are the single most impactful practice in Kanban. The rule is simple: each column on your board has a maximum number of items. When a column is at its limit, no new work enters until something moves out.

This sounds restrictive. It is. And that is the point. WIP limits force the team to finish work before starting new work. They expose bottlenecks. If your "Code Review" column is constantly at its limit, you have a review bandwidth problem that needs to be solved. Without WIP limits, that bottleneck hides behind a growing pile of open PRs that nobody talks about.

A good starting point for WIP limits: set the limit for each column to the number of people who work in that stage, minus one. For a team of 4 developers, the "In Development" WIP limit would be 3. This ensures there is always some slack for pairing or swarming on blockers.

When Kanban Beats Scrum

Kanban is the better choice when:

• Work arrives unpredictably (support teams, ops teams, platform teams handling requests from multiple consumers).
• The team does not need the cadence discipline of sprints because they are already disciplined about delivery.
• The work items vary wildly in size and cannot be meaningfully time-boxed into sprints.
• You need continuous delivery, not batch delivery. If you are deploying to production multiple times a day, sprint boundaries become artificial.

The right methodology depends on your context, not on what is popular. I have seen teams fail because they adopted Scrum when Kanban was the obvious fit, and vice versa. Here is a decision framework I use.

Scrumban: The Pragmatic Middle Ground

In practice, the most effective teams I have worked with use Scrumban, a blend that takes Scrum's cadence and Kanban's flow principles. You keep sprint boundaries for planning and stakeholder communication, but you apply WIP limits to manage flow within the sprint. You keep retrospectives for continuous improvement, but you skip formal sprint planning when the backlog is well-refined and the team knows what to pull next.

Scrumban works especially well for teams that have outgrown Scrum's prescriptive nature but still need some structure. Teams that have been together for 6+ months, have a well-groomed backlog, and are comfortable with self-organization. If your team is brand new or recently reorganized, start with Scrum. The structure helps. As the team matures, evolve toward Kanban principles. That evolution IS Scrumban.

When to Use No Framework

This is the take that gets me in trouble at Agile conferences: some teams do not need a framework. A team of three senior engineers building a well-understood feature over six weeks does not need sprint ceremonies. They need a clear goal, a shared board, a daily check-in, and a demo every Friday. Imposing Scrum on a team like this is overhead, not value.

The purpose of a framework is to create shared expectations about how work flows. If your team already has those shared expectations naturally, the framework is scaffolding you can remove. The PM's job is to recognize when the framework is helping and when it is getting in the way, and to have the courage to adapt.