Project Management for Traditional, Scrum or Kanban work
PMI says, Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. For best outcomes, we need to vary our Project Management techniques by work type. Traditional work Vs Scrum or Kanban, all require different approaches
When people hear the word “Project Management”, they often think only about creating plans, tracking schedules, managing risks, coordinating teams, and ensuring that projects get delivered successfully. But should every type of work be managed in the same way? I believe that the answer is a clear “No”. Delivering a project with stable, well-understood requirements is fundamentally different from developing an innovative product where the solution emerges through experimentation. Both are different again from operational work where requests arrive continuously. This is why effective project management starts with understanding the nature of the work. Traditional project management, Scrum, and Kanban do not simply provide three different ways of organizing tasks. They address different types of work and therefore Project Management for Traditional, Scrum or Kanban work requires different approaches to planning, risk management as well as progress tracking. The role of the Project Manager changes for each approach.
Understand the Nature of the Work
Traditional project management works well for defined work, where requirements are relatively stable, and outcomes are known upfront. Usually, established practices already exist. Examples could include a server upgrade, hardware rollout, or SAP security patching. Because uncertainty is relatively low, detailed planning is both possible and useful. Scrum is designed to help with Complex or empirical work. When requirements are unstable or not clear, teams cannot know everything at the beginning. In such situations, requirements evolve through feedback. Trial and error helps to iterate to the right solution. Developing an AI-based demand forecasting solution or a new digital product are examples. Instead of attempting to eliminate uncertainty through more detailed planning, Scrum manages uncertainty through short iterations, feedback, inspection, and adaptation. Kanban is particularly useful for flow-based or operational work. Production support, incident management, service requests, and supplier tickets are some examples. In such work, we usually do not have a defined beginning and end. Work arrives continuously, and priorities do change frequently. Fast response to the changing priorities and incoming work is important. Deciding a Sprint Goal becomes quite difficult. The challenge is therefore to keep work flowing smoothly while avoiding bottlenecks and excessive Work-in-Progress (WIP). A simple way to remember the distinction is:
If the work can be is stable and can be predicted, plan it; if you need to learn while doing it, use empiricism; if work continuously arrives, optimize the flow.
Planning as per work type: Traditional, Scrum or Kanban work
Planning is necessary in all three approaches, but the purpose and horizon of planning change. In a traditional project, the primary planning question is: What work must we complete, and how do we deliver it on time and within budget? The Project Manager typically creates a detailed project plan covering scope, milestones, dependencies, resources, schedule, and budget. Tools such as the Work Breakdown Structure (WBS), Gantt charts, and milestone plans support this predictive approach. When we plan for predictive work, focus is on efficiency and optimization Scrum asks a different question: What is the most valuable thing we should build next, and what can we learn? Planning is adaptive and focuses on feedback. In such an environment, planning happens at multiple levels through the product roadmap, Product Backlog, release planning, backlog refinement, and Sprint Planning. Scope can and often does evolve as customer feedback and learning provide new insight. The objective is not simply to deliver everything originally requested, but to maximize customer and business value. When we are working with flow-based or operational work, the planning question is: What work should we pull next to ensure smooth flow and meet service expectations (SLA/KPIs)? In the flow based work, we continuously prioritize work based on demand, urgency, available capacity, and service expectations. Kanban boards, WIP limits, service request queues, and classes of service help while planning Kanban kind of work.
Thus, Traditional planning optimizes for predictability, Scrum focuses on planning for experimentation with focus on continuous outcomes and Kanban plans for optimizing the flow and removing bottle necks.
Risk Management: The Risk Itself Changes when work type changes
Risk management also differs as per the nature of the work. Traditional projects primarily face risk of execution not going as per plan. The concern is whether the team manages to deliver the agreed scope according to the plan. Schedule delays, missed dependencies, budget overruns, and scope creep are common risks. Project Managers rely on risk registers, dependency analysis, mitigation plans, contingency reserves, and formal change control. In Scrum, the dominant risk is uncertainty and rapidly evolving requirements. Are we building the right features? Will our customers user our prouduct? What if an assumed technical solution does not work? Scrum reduces these risks through short iterations, prototypes, rapid feedback, backlog reprioritization, and continuous learning. Kanban faces operational risk . Growing queues, SLA breaches, excessive WIP, capacity constraints, and bottlenecks can quickly affect service. Teams use patterns like WIP limits, SLA monitoring, flow metrics, and bottleneck management. These patterns help the teams to establish the flow.
To summarize, Traditional approaches try to predict the risk and then analyze and control it. Scrum emphasizes on learning based on feedback and then adapting and pivoting as needed. While Kanban focuses on detecting problems quickly, restoring flow, and continuously improving.
Tracking Progress differs for each work type: Are We on Plan, Creating Value, or Flowing?
Perhaps the clearest difference is visible in how progress is measured. In a Traditional project, the key question is: Are we on plan? Measures such as milestone completion, percentage complete, schedule variance, cost variance, Earned Value, SPI, and CPI help compare actual performance against the baseline. In Scrum, the more important question is: Are we creating value effectively? Sprint Goal achievement, working product increments, customer feedback, quality, value delivered, burndown, and velocity can provide useful information. Importantly, completing more work does not automatically mean creating more value. For Kanban, the question is: Is work flowing? Lead time, cycle time, throughput, WIP, work-item age, cumulative flow, and SLA compliance help teams understand whether work is moving efficiently through the system.
Success itself looks different for each work type: Traditional projects emphasize delivering scope, Scrum emphasizes delivering value, and Kanban emphasizes delivering flow.
With Changing work types, The Project Manager’s Role Must Change Too
One major misconception about Agile is that Agile does not need Project managers – well if the work needs managing, we need someone to manage the work. Read this article to understand why we still need a manager in Agile Projects. If planning, risk, and tracking change, the Project Manager cannot operate in exactly the same way either. In Traditional projects, the PM naturally spends significant effort planning, coordinating dependencies, monitoring schedules and budgets, managing risks, communicating status, and controlling deviations from the agreed plan. In an Agile environment, these responsibilities do not disappear—they are redistributed. The Product Owner, Scrum Master, team, technical leaders, and Project Manager may share responsibilities that traditionally sat with one PM. This requires an important mindset shift. Instead of focusing primarily on following the plan, focus on achieving the desired outcome. Instead of controlling change, respond effectively to change. We need to move from managing individual tasks to enable high-performing teams. Rather than measuring activity, we should measure customer value and outcomes. And instead of directing execution, facilitate collaboration and learning.
Snehamayee’s recommendation — Choose the Approach Based on the Work
Project Management for Traditional, Scrum or Kanban work is very different. Which is why, Traditional, Scrum, and Kanban should not be viewed as competing methods where one must always be better than the others. The better question is: What is the nature of the work we are trying to manage?
When work is predictable and well defined, detailed planning and control can provide tremendous value. On the other hand, when the work contains significant uncertainty and learning, Scrum’s empirical approach enables teams to inspect, adapt, and discover better solutions. Lastly in situations where work arrives continuously, Kanban helps teams optimize flow and responsiveness. Great project management is therefore not about rigidly following one methodology. It is about recognizing the type of work in front of us and adapting how we plan, manage risk, measure progress, and lead teams accordingly.
When we work at enterprise level Agile, it becomes important to recognize that often we will need to employ all 3 approaches within same large multi team Agile Project or Program based on what each specific team does – I explore this idea with more depth in World Of Agile Agile PM Skill Badge