--- title: "13 — Process and Project Management — ITIL, Agile Flavors, and PMI" uid: process-and-project-management tags: ["rup", "less", "kanban", "prince2", "roadmap:software-architect", "safe", "pmi", "xp", "scrum", "itil", "agile"] excerpt: "ITIL, RUP, LeSS, SAFe, XP, Kanban, Scrum — all answers to two questions (how to plan work, how to run it) on a spectrum from heavyweight/predictive to lightweight/adaptive." date: 2026-08-13T03:27:40+0000 source: https://www.aveshina.my.id/en/blog/process-and-project-management --- A pile of certifications was how I filed the management cluster — ITIL, RUP, LeSS, SAFe, XP, Kanban, Scrum, PMI, Prince2. The model that organized them: **these are all answers to the same two questions — how to plan work, and how to run it — and they sit on a spectrum from heavyweight/predictive to lightweight/adaptive** [1]. Once I saw the spectrum, the choice stopped being "which is right" and became "how much predictability does this work actually need, and how many teams are involved." Management covers the certifications, methodologies, and organizational practices an architect encounters within structured project and process frameworks [1]. Knowledge here helps an architect operate effectively within an organization's existing processes. ## The predictive end: PMI, PRINCE2, ITIL, RUP At the heavyweight end sit the frameworks built for **predictability** — large scope, many stakeholders, change is expensive. **PMI** (Project Management Institute) issues the internationally recognized PMP credential, validating skills to manage projects by the best practices and standards in the PMBOK guide [2]. **PRINCE2** is a structured project-management method emphasizing dividing projects into manageable, controllable stages, widely adopted in the UK, Western Europe, and Australia [3]. Both are process-heavy and plan-driven — the assumption is that you can define the work, estimate it, and execute against the plan, controlling changes formally when they arise. **ITIL** is a framework for **IT service management**, aligning IT services with business needs through defined processes like incident, change, and problem management [4]. It's adopted by enterprises needing consistent, auditable processes for running IT operations. An architect benefits from understanding ITIL when their systems must integrate with an organization's existing service-management practices — the change-management process your deployment goes through is often ITIL-shaped. **RUP** (Rational Unified Process) is a software-development framework (created by Rational, now IBM) following an **iterative and incremental** approach based on best practices for delivering quality software on time and budget [5]. RUP is iterative, which places it partway toward adaptive, but it carries the heavyweight documentation and process overhead of its era. ## The adaptive end: Scrum, Kanban, XP At the lightweight end sit the **agile** methods, built for adaptability — scope evolves, learning happens during the work, change is expected. **Scrum** organizes work into fixed-length iterations called **sprints**, with defined roles (product owner, scrum master) and ceremonies (sprint planning, daily standups, retrospectives) keeping the team aligned and improving over time [6]. It's one of the most widely adopted agile methodologies. **Kanban** visualizes work on a board with columns for each stage, focusing on managing flow and **limiting work in progress** [7]. Unlike Scrum's fixed iterations, Kanban focuses on continuous delivery, making it flexible for teams with varying or unpredictable workloads. Architects use Kanban boards to track technical tasks and see bottlenecks. **Extreme Programming (XP)** is an agile methodology emphasizing **technical practices** — pair programming, test-driven development, continuous integration — to improve software quality [8]. It focuses heavily on engineering discipline alongside the collaboration elements of other agile frameworks. Architects who value technical excellence often draw on XP practices (especially TDD and CI) even when a team formally follows a different methodology. The thread connecting the agile end: short feedback loops, working software over comprehensive documentation, and the assumption that the plan will change. ## Scaling agile: SAFe and LeSS The middle of the spectrum is where agile meets many-teams. Both **SAFe** and **LeSS** scale Scrum across organizations, but they take opposite stances on how much structure to add. **LeSS (Large-Scale Scrum)** adheres to Scrum's principles, emphasizing simplicity and continuous improvement — a single backlog and common product owner across teams, with coordination through collaboration rather than added roles [9]. Its goal is to minimize bureaucracy and maximize value delivery. **SAFe (Scaled Agile Framework)** is more structured, providing a formal approach to coordinating multiple teams, programs, and portfolios, incorporating elements of Lean, DevOps, and agile, with additional roles, ceremonies, and artifacts to align teams with business strategy [10]. SAFe enables large-scale planning and continuous delivery at corporate scale. The trade-off: LeSS scales by removing, SAFe scales by adding. LeSS trusts teams to coordinate; SAFe coordinates them explicitly. Large enterprises often gravitate to SAFe because its structure maps onto existing org charts; smaller, more cohesive organizations may prefer LeSS for its lighter touch. ```figure predictive / heavyweight adaptive / lightweight PMI PRINCE2 ITIL RUP plan-driven · formal change control SAFe adds structure LeSS removes it scaling agile across teams Scrum Kanban XP short feedback loops embrace change ``` ## How I use this I match the methodology to two variables: how predictable the work is, and how many teams are involved. Predictable, single-team work can run lightweight Scrum or Kanban. Unpredictable, exploratory work wants XP's technical discipline (TDD, CI) under whatever process wraps it. Many teams in a large enterprise often need SAFe or LeSS to coordinate — and I lean LeSS when the org can handle the trust, SAFe when the existing structure needs explicit mapping. ITIL-shaped change management I treat as a constraint to design around, not fight — the deployment pipeline has to satisfy it, or no change ships. The mistake is adopting a methodology for its popularity rather than for the predictability and scale of the actual work. ## References [1] "Management," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/management](https://roadmap.sh/software-architect/management) [2] "Project Management Institute," PMI. [Online]. Available: [https://www.pmi.org/](https://www.pmi.org/) [3] "PRINCE2 Certification," AXELOS. [Online]. Available: [https://www.axelos.com/certifications/propath/prince2-project-management](https://www.axelos.com/certifications/propath/prince2-project-management) [4] "ITIL Documentation," AXELOS. [Online]. Available: [https://www.axelos.com/certifications/itil-service-management/itil-4-foundation](https://www.axelos.com/certifications/itil-service-management/itil-4-foundation) [5] "Rational Unified Process," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/rup](https://roadmap.sh/software-architect/rup) [6] Atlassian, "What is Scrum and How to Get Started," [Online]. Available: [https://www.atlassian.com/agile/scrum](https://www.atlassian.com/agile/scrum) [7] Businessmap, "What Is Kanban?," [Online]. Available: [https://businessmap.io/kanban-resources/getting-started/what-is-kanban](https://businessmap.io/kanban-resources/getting-started/what-is-kanban) [8] Agile Alliance, "What is Extreme Programming (XP)?," [Online]. Available: [https://www.agilealliance.org/glossary/xp/](https://www.agilealliance.org/glossary/xp/) [9] "LeSS Framework," less.works. [Online]. Available: [https://less.works/less/framework](https://less.works/less/framework) [10] "SAFe 6.0," Scaled Agile, Inc. [Online]. Available: [https://scaledagileframework.com/SAFE](https://scaledagileframework.com/SAFE) ```quiz Q: PMI (PMP) and PRINCE2 sit at which end of the methodology spectrum? - Predictive / heavyweight, plan-driven - Adaptive / lightweight, embrace change correct: 0 explain: PMI and PRINCE2 are plan-driven, process-heavy methodologies built for predictability and formal change control — the predictive/heavyweight end of the spectrum. Q: What distinguishes Kanban from Scrum? - Kanban uses fixed-length sprints; Scrum uses continuous flow - Kanban focuses on continuous delivery and limiting work in progress rather than fixed-length iterations correct: 1 explain: Scrum organizes work into fixed-length sprints; Kanban visualizes flow and limits work in progress for continuous delivery, making it flexible for unpredictable workloads. Q: XP's defining trait compared to other agile methods is… - its emphasis on technical practices like TDD, pair programming, and CI - its heavy documentation and formal change control correct: 0 explain: XP brings engineering discipline — TDD, pair programming, continuous integration — alongside the collaboration elements of agile. Architects often borrow XP practices regardless of the team's formal methodology. Q: SAFe and LeSS both scale Scrum. What's the core difference? - SAFe adds structure and roles; LeSS scales by removing bureaucracy and keeping one backlog - SAFe is for small teams; LeSS is for single developers correct: 0 explain: SAFe scales by adding explicit coordination (roles, ceremonies, artifacts); LeSS scales by removing structure — one backlog, one product owner, coordination through collaboration. Q: Why should an architect understand ITIL even though it's not a development methodology? - Because the change-management process deployments must pass through is often ITIL-shaped - Because ITIL is required to write code in any language correct: 0 explain: ITIL governs IT service management (incident, change, problem management). The change-control process your deployment goes through in an enterprise is often ITIL-based, so designing around it is how work actually ships. ```