1 Overview
A development team does not decide everything. It does not set the company strategy, choose the market, or control the budget. But within the space it is given, a team makes a surprising number of decisions that shape whether work ships and whether the people doing it stay sane. This article looks at the decisions a team actually owns, and how those decisions differ depending on whether the team is using Agile ideas, Scrum, or Kanban. The point is not to crown a winner. The point is to show where the real authority sits, because teams that cannot decide their own working methods tend to slow down, burn out, or both.
The three approaches share a belief that the people closest to the work should decide how the work gets done. They differ in how much structure they add around that belief. Scrum adds roles, events, and artifacts that create a steady rhythm. Kanban adds a visual flow and limits on how much work can be in progress at once. Agile is the broader set of values and principles that both can serve. A team can borrow from all three, but it cannot avoid the hard question of what it is allowed to decide on its own.
2 The problem this method was built to solve
The problem was not that software teams lacked intelligence or effort. The problem was that decisions about how to work were often made far away from the work itself. Managers who did not write code chose the process. Executives who did not test the product set the deadlines. Teams were handed a plan and told to execute it, even when the plan ignored what the team learned after the first week. The result was predictable: late delivery, hidden quality problems, and a quiet sense that the people doing the work had no say in how it was done.
Agile, Scrum, and Kanban each attacked a different part of that problem. Agile named the values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Scrum turned those values into a repeatable structure with clear roles and a short cycle. Kanban focused on the flow of work, making bottlenecks visible and limiting how much work a team takes on at once. None of them solved the problem completely, because no method can force an organization to give up control. But each gave teams a language for claiming decisions that should have been theirs all along.
3 How one cycle runs, from ready to done
In a Scrum-style cycle, the team starts with an ordered list of work. The product-focused role has already put the most valuable items near the top. The team pulls a small set of those items into a short cycle, often one to four weeks. During the cycle, the team meets briefly each day to inspect progress and adjust the plan. The work moves across a visible board: not started, in progress, in review, done. At the end of the cycle, the team shows a working increment to stakeholders and then holds a retrospective to improve how it works. The cycle then repeats.
A Kanban-style flow looks different. There is no fixed cycle length. Work moves continuously across a board, and the team limits how many items can sit in each column at once. When a column is full, no new work enters it. That limit forces the team to finish what it started before pulling more. The team still meets to coordinate, but the rhythm comes from the flow of work rather than from a calendar. In both cases, the team decides what done means. A working increment that meets the team's definition of done is the only thing that counts. Everything else is still in progress, no matter how good it looks in a demo.
4 Roles and how they divide the work
The most important role in any of these methods is the team itself. The team decides how much work it can take on, how it will approach the work, and what quality standard it will hold. That sounds obvious, but it is often the first thing lost when an organization adopts the language of Agile without changing who holds authority. A team that cannot choose its own tools, its own working hours, or its own definition of done is not really a team. It is a workgroup with a new vocabulary.
Around the team sit two other roles. One is product-focused. This person orders the work by value, talks to stakeholders, and decides what the team should build next. The other is coaching-focused. This person helps the team apply the method, removes obstacles, and protects the team from distractions. In Scrum, these roles are usually called the Product Owner and the Scrum Master. In Kanban, they may not exist as formal titles, but the functions still need to be filled. The trade-off is real. A strong product role can keep the team focused, but it can also become a bottleneck if that person is overloaded or absent. A strong coaching role can improve how the team works, but it can also drift into management if the team does not own its own process.
5 Artifacts worth keeping
The artifacts that matter are the ones that help the team make decisions, not the ones that impress an auditor. The first is an ordered list of work. It does not need to be long or detailed. It needs to show what is most valuable next, so the team can pull from the top and leave the rest. The second is a visible board. Whether it is physical or digital, the board shows what is in progress, what is blocked, and what is done. A board that nobody updates is worse than no board at all, because it creates a false picture of progress.
The third artifact is a definition of done. This is the team's agreement about what quality means. It might include code review, automated tests, documentation, or a demo. The exact contents matter less than the fact that the team wrote it and holds itself to it. The fourth artifact is a working increment. This is the only proof that the team actually delivered something. Plans, estimates, and status reports are useful for coordination, but they are not the product. A team that keeps its board honest and its definition of done strict will usually outperform a team that produces beautiful reports about work that is not finished. The artifacts should serve the team, not the other way around.
6 Where this method breaks down
The method breaks down when the team is given responsibility without authority. A team that is told to self-organize but cannot change its own process, choose its own tools, or push back on unrealistic deadlines will quickly learn that the language of Agile is just a new way of being told what to do. The daily meeting becomes a status report. The retrospective becomes a complaint session. The board becomes a decoration. None of that is the fault of the method. It is the fault of an organization that wanted the benefits of team ownership without giving up control.
The method also breaks down when the cycle is treated as a deadline rather than a learning loop. A short cycle is meant to create fast feedback, not to force the team to cram more work into less time. When stakeholders treat the end of the cycle as a hard ship date, the team will cut quality to hit it. That is a rational response to a broken incentive. Kanban has its own failure mode: without limits on work in progress, the board becomes a museum of half-finished tasks. The team starts many things and finishes few. The fix is not a new method. The fix is a team that is allowed to say no, to finish what it started, and to change its own process when the current one stops working.
7 Frequently asked questions
Does a team need a product owner to use Scrum? Scrum defines the role, but the function matters more than the title. Someone must order the work by value and make trade-off decisions. If no one does that, the team will either guess or wait. Both are expensive. The role can be shared, but the decision rights cannot be vague. A team that cannot tell who decides what will spend more time negotiating than building.
Can a team use Kanban without a fixed cycle? Yes. Kanban is built for continuous flow. The team still needs a rhythm for coordination and improvement, but it does not need to start and stop on a calendar. The trade-off is that without a cycle boundary, it is easier to let work pile up. Limits on work in progress are what keep the flow honest.
What if the team disagrees with the product role? That is normal. The product role decides what to build next, but the team decides how much it can take on and how to build it. If the disagreement is about value, the product role should explain the reasoning. If it is about capacity, the team should show the data. A healthy team argues about these things openly rather than pretending they do not exist.
Is Agile a method? Agile is a set of values and principles, not a step-by-step method. Scrum and Kanban are methods that can serve those values. A team can be Agile without using either, but it will still need some way to decide, deliver, and improve. The method is less important than whether the team actually owns its own work.