Agile Framework for Technical PMs: Guide to the main types

A team working together on planning an Agile project

Agile frameworks for technical project managers fall into two distinct categories: product execution-oriented models, such as Scrum and Kanban, and comprehensive project management frameworks, such as AgilePM, which manage the governance, budget, and lifecycle of the entire project. This distinction is not academic. A technical PM who uses only Scrum to manage a complex IT project finds himself without tools for governance, reporting to sponsors, and formal closure management.

The main Agile frameworks relevant for those managing IT and R&D projects in Italy include:

AgilePM(based on DSDM): complete project management framework, with phases, formal roles and techniques such as MoSCoW and Timeboxing
Scrum: iterative framework for product delivery, organized in sprints with defined roles
Kanban: continuous flow visual method, without sprints, with limitation of work in progress
SAFe(Scaled Agile Framework): Architecture for coordinating multiple Agile teams at the enterprise level
Lean Software Development: approach derived from Lean thinking, focused on eliminating waste

Cross-cutting techniques such as MoSCoW for prioritization and timeboxing apply across multiple frameworks and are particularly useful in R&D projects where requirements are constantly changing.

Index

How AgilePM works and why it covers the entire project
Scrum and Kanban compared: which one do you choose for your team?
Differences between AgilePM, Scrum and Kanban: a systematic comparison
Practical advice for adopting Agile frameworks in Italy
What is SAFe and when is it really needed?
Lean Software Development: eliminate waste in the project
Viniciolupo ControlRoom: Agile management with real-time visibility
Key points

How AgilePM works and why it covers the entire project

AgilePM was born from DSDM (Dynamic Systems Development Method), one of the longest-standing Agile frameworks, developed in the 1990s in the British context. Unlike Scrum, AgilePM covers governance and management of the entire project lifecycle, not just the development phase. This makes it suitable for contexts where the PM must respond to a steering committee, manage contracts with external suppliers or report to a PMO.

The AgilePM life cycle is divided into six sequential phases:

Pre-project: definition of the idea and verification of strategic alignment
Feasibility: rapid assessment of technical and economic feasibility
Foundations: definition of high-level requirements, architecture and project plan
Evolutionary Development: Iterative and incremental development, often with internal Scrum sprints
Deployment: solution release and user training
Post-project: verification of expected benefits and formal closure

Formal AgilePM roles include Business Sponsor (budget manager), Project Manager, Technical Coordinator, and Business Visionary. This governance structure is what is missing from pure Scrum, which only defines Product Owner, Scrum Master and Development Team.

MoSCoW(Must have, Should have, Could have, Won’t have) is the central prioritization technique in AgilePM. It allows you to negotiate the scope of the project without blocking the work: if a “Should have” feature slows down the delivery, it moves to “Won’t have” for this release without reopening the entire plan. TheTimeboxing, adopted in both AgilePM and Scrum, transforms vague deadlines into defined work cycles, improving forecasting in uncertain R&D projects.

A tip: In IT projects with external vendors, use AgilePM for contractual governance and Scrum as the internal delivery engine for the technical team. The two structures integrate without conflicts: AgilePM manages the "what" and "when" at the project level, Scrum manages the "how" at the sprint level.

Scrum and Kanban compared: which one do you choose for your team?

Scrum and Kanban are both Agile frameworks for execution, but they work very differently. Scrum isa sprint-based iterative frameworkwith defined roles and fixed ceremonies; Kanban is a continuous-flow visual method, without timed iterations. The choice depends on the type of work the team handles.

Scrum: structure and principles

Scrum organizes work into sprints of fixed duration, which generally cover a period of several weeks. The three fundamental roles are the Product Owner, who manages the backlog and defines priorities; the Scrum Master, who removes impediments and facilitates ceremonies; and the Development Team, which executes the work. The core values of Scrum, transparency, inspection and adaptation, guide each ceremony: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.

A woman takes notes on the tablet during a sprint work session.

Scrum works well when the team is working on a product with evolutionary requirements and can engage in focused sprints. In a software development project with timed releases, Scrum provides pace and visibility. The risk is treating it as a complete project management system: Scrum covers product delivery, not project governance.

Kanban: visual flow and WIP limitation

Kanban uses visual management with a board divided into columns (typically: To Do, In Progress, Completed) and imposes a limit on the number of activities being processed simultaneously (WIP limit). There are no sprints, there are no mandatory roles, there are no fixed ceremonies. Work flows continuously from the left column to the right column.

Hands organizing tasks on a Kanban board

Kanban is ideal for tech support, IT operations, or software maintenance teams, where requests come in unpredictably and you can't plan a sprint. A DevOps team managing incidents and change requests uses Kanban much more effectively than Scrum.

Comparison table: Scrum vs Kanban

Feature	Scrum	Kanban
Cadence	Fixed sprints of pre-established duration	Continuous flow
Defined roles	Yes (Product Owner, Scrum Master, Team)	No (optional roles)
Ceremonies	Planning, Daily, Review, Retro	None mandatory
Priority management	Backlog sorted by sprint	Continuous queue with WIP limit
Documentation	Backlog, Definition of Done	Kanban board, flow metrics
Suitable for	Iterative product development	Operations, support, maintenance
Progress measurement	Velocity for sprints	Lead time and throughput

Differences between AgilePM, Scrum and Kanban: a systematic comparison

The most common confusion among technical PMs is treating Scrum as synonymous with Agile. Agile is a philosophy, Scrum is one of the frameworks that implements it. AgilePM is another framework, with a much broader scope. Understanding where one ends and the other begins changes the way you structure a complex IT project.

Comparison table: AgilePM, Scrum and Kanban

Size	AgilePM	Scrum	Kanban
Roles	Business Sponsor, PM, Technical Coordinator, Business Visionary	Product Owner, Scrum Master, Dev Team	No mandatory roles
Documentation	Formal: Business Case, PID, risk registers	Backlog, Definition of Done	Visual board, flow metrics
Phases	6 structured phases (Pre-project → Post-project)	Iterative sprints without formal phases	Continuous flow without phases
Times	Timeboxing at the project and iteration level	Fixed sprints (some weeks)	No fixed cadence
Priority	MoSCoW with scope negotiation	Backlog ordered by Product Owner	WIP limit and priority per queue
Communication	Facilitated workshops, formal reports to sponsors	Daily Scrum, Sprint Review	Flow meetings (optional)
Perimeter	Entire project life cycle	Product delivery	Workflow management

The most relevant practical difference concerns governance. AgilePM produces formal artifacts (business cases, risk registers, release plans) that a steering committee or corporate PMO expects. Scrum doesn't produce them by default. In IT projects with significant budgets or contractual constraints, this Scrum gap becomes a real problem.

The integration between the two frameworks resolves the tension: Scrum within AgilePM allows the development team to work with the flexibility of sprints, while PM maintains the governance required by the organization. It is not a compromise, it is the most effective configuration for medium and large IT projects.

The advantages and limitations for IT and R&D projects:

AgilePM: suitable for projects with formal sponsors, external suppliers and reporting requirements; less agile in quickly responding to sudden technical changes
Scrum: Excellent for development teams focused on one product; insufficient as a sole management tool in multi-team or multi-vendor projects
Kanban: perfect for continuous operational work; difficult to use to schedule releases with fixed deadlines

Practical advice for adopting Agile frameworks in Italy

The biggest risk for a technical PM is to adopt a framework ideologically: choose Scrum because “everyone uses Scrum” or reject any predictive framework because “we are Agile”. The choice must start from the context of the project, the level of technical uncertainty and the organizational constraints.

Some concrete indications for the Italian context:

Assess the level of uncertainty: R&D projects with very open requirements benefit from Scrum or AgilePM with MoSCoW; projects with fixed specifications and lump sum contracts are best managed with a hybrid approach
Don't ignore governance: large Italian companies predominantly use hybrid Waterfall-Agile approaches, combining rigorous strategic planning and operational agility in the development phases
Use MoSCoW to negotiate scope: in R&D projects where requirements change every month, MoSCoW allows you to manage priorities dynamically without rewriting the plan every time
Apply Timeboxing even outside of sprints: defining fixed time windows for analysis, prototyping and validation activities reduces the time drift typical of research projects
Coordinate multiple teams with shared artifacts: When you manage multiple technical teams, a shared backlog and weekly synchronization ceremonies prevent misalignment
Choose tools based on the framework: Jira and Azure DevOps support Scrum and Kanban well; for AgilePM you need tools that also manage project documentation and formal registers

A tip: Before choosing the framework, map stakeholder expectations. If your sponsor expects a Gantt and risk register, using only Scrum creates unnecessary friction. A layer of AgilePM on top of Scrum sprints meets both needs without slowing down the team.

Agile leadership matters as much as the framework you choose. A PM who imposes Scrum without giving the team autonomy gets the worst of both worlds: the ceremonies without the culture. The goal is to create the conditions for the team to adapt, not to control every technical micro-decision. To learn more about how artificial intelligence is changing this balance, it is worth reading the analysis aboveAI and project control.

What is SAFe and when is it really needed?

SAFe (Scaled Agile Framework) is an architecture for coordinating multiple Agile teams working on the same product or program. It was created to answer a specific question: how do you maintain coherence and alignment when not one but ten or twenty teams work in parallel on different components of the same system?

SAFe introduces overlapping planning layers. At the team level, standard Scrum sprints are used. At the program level, multiple teams synchronize in a cycle called PI (Program Increment), typically 8–12 weeks, with a collective planning event called PI Planning. At the portfolio level, SAFe manages investment allocation and strategic alignment between different value streams.

For an Italian technical PM managing a single team or medium-sized project, SAFe is overkill. Introduces ceremonies, roles, and artifacts designed for organizations with hundreds of developers. The cost of adoption, in terms of training, coordination and organizational overhead, exceeds the benefits below a certain size threshold. SAFe becomes relevant when coordinating at least 5–6 Agile teams on a shared program, typically in large telecommunications, banking or manufacturing companies with structured IT divisions.

The central role in SAFe is the Release Train Engineer (RTE), who coordinates the work flow between teams like a Scrum Master at the program level. The SAFe structure is certified and documented by the Scaled Agile, Inc. organization, with internationally recognized training paths.

Lean Software Development: eliminate waste in the project

Lean Software Development is not a framework with ceremonies and defined roles. It is a set of principles derived from the Toyota production system, adapted to software development by Mary and Tom Poppendieck in their 2003 book. The central idea is simple: everything that does not add direct value to the customer is a waste and must be eliminated.

The seven principles of Lean Software Development are: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity into the product and see the system as a whole. In practice, this translates into concrete choices: reduce work in progress, avoid unrequired features, automate tests, shorten feedback cycles.

For a technical PM, Lean Software Development is more of a mental filter than a method to be adopted as a replacement for Scrum or AgilePM. It is used to evaluate whether a ceremony, document or process really adds value or is just organizational overhead. Kanban, for example, incorporates many Lean principles: the WIP limit reduces waste from multitasking, flow visualization makes bottlenecks visible, lead time measurement guides continuous improvement.

In R&D projects, Lean thinking helps avoid the trap of excessive documentation. Producing detailed specifications for features that might change within two sprints is a classic waste. Thevisual management of workand short feedback loops are the most useful Lean tools in this context.

Viniciolupo ControlRoom: Agile management with real-time visibility

Those who work on complex IT and R&D projects know the problem well: Agile frameworks give structure to the process, but real visibility into progress, risks and bottlenecks remains fragmented between sprint boards, spreadsheets and manual reports.

Viniciolupo

Viniciolupo ControlRoom is the AI workspace designed for technical PMs who manage complex projects in Agile environments. It does not replace Scrum or AgilePM: it joins the framework you already use and brings artificial intelligence where it is missing, i.e. in the continuous monitoring of the project status, in the early identification of risks and in the automatic synthesis of information for stakeholders. The net result is less time spent building reports and more time spent making technical decisions that matter.

For PMs managing multiple R&D teams or projects with evolving requirements, ControlRoom offers a unified view that no Kanban board or sprint backlog alone can provide. You can start with a direct test onControlRoom AIand see firsthand how it integrates with your current workflow.

Key points

The most effective Agile frameworks for technical PM combine iterative execution and structured governance, with the choice depending on the project context and stakeholder expectations.

Point	Details
AgilePM vs Scrum	AgilePM manages the entire lifecycle with formal governance; Scrum only covers product delivery.
Recommended integration	Using Scrum as the development engine within AgilePM resolves the tension between flexibility and control.
MoSCoW and Timeboxing	These two transversal techniques are indispensable for managing scope and time in R&D projects with changing requirements.
Hybrid approach in Italy	Large Italian companies predominantly adopt hybrid Waterfall-Agile models to combine strategic planning and operational agility.
Viniciolupo ControlRoom	AI tool for technical PMs that supports any Agile framework with continuous monitoring and automatic synthesis for stakeholders.

Want to go deeper on the method?

Read the AI Process Intelligence framework