# PM 2: Metodologiyalar — Waterfall, Agile, Scrum, Kanban, Shape Up va miqyoslash

> **Holat:** 2026-yil sentabr. Bu dars asosiy yetkazib berish metodologiyalarini rasmiy manbalar bo'yicha ko'rsatadi: Scrum Guide hamon 2020-yil noyabr versiyasi, SAFe'ning joriy versiyasi 6.0. Oxirida "qaysi loyiha uchun qaysi metodologiya" qaror jadvali bor.

## Mundarija

1. [Metodologiya tanlash va iron triangle](#tanlov)
2. [Waterfall](#waterfall)
3. [Agile Manifesto](#manifesto)
4. [Scrum: 2020 Scrum Guide bo'yicha](#scrum)
5. [Kanban: oqim bilan ishlash](#kanban)
6. [Scrumban](#scrumban)
7. [Shape Up](#shape-up)
8. [Miqyoslash: SAFe va LeSS](#miqyos)
9. [Outsourcing'da gibrid modellar](#gibrid)
10. [Qaror jadvali](#qaror)
11. [Xulosa](#xulosa)
12. [Manbalar](#manbalar)

---

## 1. Metodologiya tanlash va iron triangle {#tanlov}

"Eng yaxshi metodologiya" yo'q. Har biri bitta savolga turlicha javob beradi: **nima qat'iy, nima moslashuvchan?**

Bu savolning asosi — **iron triangle** (project management triangle): scope, vaqt va narx bir-biriga bog'liq, markazda esa sifat. Wikipedia bu g'oyani Martin Barnes'ning 1968–1969-yillardagi cost/time/quality modeliga bog'laydi ([Wikipedia](https://en.wikipedia.org/wiki/Project_management_triangle)). Bittasini o'zgartirsangiz, qolganlaridan biri ham o'zgaradi.

```text
                 Waterfall (predictive)          Agile (adaptive)
Qat'iy:          scope                            vaqt (sprint) va narx (jamoa)
Baholanadi:      vaqt va narx                     scope — sig'ganicha, qiymat bo'yicha
O'zgarish:       rasmiy change request            keyingi sprint backlog'iga
Xavf:            kech feedback                    scope "oqib ketishi"
```

Waterfall uchburchakni boshida "muzlatadi". Agile esa vaqt va narxni sprint ritmi bilan belgilab, scope'ni moslashuvchan qoldiradi. PMI ham bu ikki qutbni **predictive** va **adaptive**, aralashmasini **hybrid** deb ataydi ([PMI](https://www.pmi.org/about/what-is-project-management)).

---

## 2. Waterfall {#waterfall}

Waterfall — bosqichlar ketma-ket o'tadigan model:

```text
Talablar -> Dizayn -> Dasturlash -> Integratsiya va test -> Joriy etish -> Qo'llab-quvvatlash
   (har bosqich oldingisi tugagach boshlanadi, orqaga qaytish qimmat)
```

Tarixdan uchta fakt ([Wikipedia — Waterfall model](https://en.wikipedia.org/wiki/Waterfall_model)):

- Birinchi batafsil tavsif — Winston Royce'ning 1970-yilgi maqolasi. Qizig'i, Royce'ning o'zi test faqat oxirida bo'ladigan sof ketma-ket variantni "risky and invites failure" deb atagan.
- Shunga o'xshash g'oyani Herbert Benington 1956-yilda SAGE loyihasi uchun taqdim etgan.
- AQSh Mudofaa vazirligi uni 1985-yilda DOD-STD-2167 standarti bilan rasmiylashtirgan.

**Qachon hali ham o'rinli** (bu amaliy xulosa, rasmiy qoida emas):

- **Fixed price, fixed scope shartnoma** — buyurtmachi narxni imzolashdan oldin bilishi shart (tender, grant).
- **Qat'iy tartibga solinadigan soha** — audit uchun oldindan tasdiqlangan hujjatlar kerak.
- **Apparat (hardware) bilan bog'liq ish** — ishlab chiqarishga yuborilgan qurilmani keyin o'zgartirish juda qimmat.

Asosiy zaifligi — **kech feedback**: buyurtmachi ishlaydigan dasturni oxirida ko'radi, xato talab esa eng qimmat bosqichda ochiladi.

---

## 3. Agile Manifesto {#manifesto}

Agile — metodologiya emas, qadriyatlar to'plami. **Agile Manifesto**'ni 2001-yilda 17 muallif imzolagan: unda 4 qadriyat va 12 tamoyil bor ([agilemanifesto.org](https://agilemanifesto.org/)). Scrum, Kanban, XP — hammasi shu qadriyatlarga tayanadi.

| Ustuvor (chapdagi)           | Nimadan ustun (o'ngdagi)    |
| ---------------------------- | --------------------------- |
| Individuals and interactions | processes and tools         |
| Working software             | comprehensive documentation |
| Customer collaboration       | contract negotiation        |
| Responding to change         | following a plan            |

Eng ko'p noto'g'ri tushuniladigan joy — manifestdagi keyingi jumla: _"while there is value in the items on the right, we value the items on the left more"_. Ya'ni hujjat, reja va shartnoma **kerak** — faqat ular chap tomondagilardan keyin turadi. "Agile'da hujjat yozilmaydi" degan gap manifestga zid.

12 tamoyildan PM uchun eng amaliylari ([12 Principles](https://agilemanifesto.org/principles.html)):

- **1-tamoyil** — qimmatli dasturni erta va uzluksiz yetkazish;
- **3-tamoyil** — ishlaydigan dasturni tez-tez yetkazish (bir necha haftadan bir necha oygacha, qisqarog'i afzal);
- **8-tamoyil** — barqaror sur'at (doimiy overtime'ga qarshi);
- **10-tamoyil** — soddalik: bajarilmaydigan ish miqdorini maksimal qilish san'ati.

---

## 4. Scrum: 2020 Scrum Guide bo'yicha {#scrum}

**Scrum Guide**'ni Ken Schwaber va Jeff Sutherland yozgan. Joriy versiya — 2020-yil noyabr, 2026-yil sentabr holatida yangisi yo'q ([Scrum Guide](https://scrumguides.org/scrum-guide.html)). Scrum uchta ustunga tayanadi: **transparency, inspection, adaptation**.

**Uchta accountability** (2020 versiyada "rol" emas, "accountability" deyiladi):

| Accountability    | Nimaga javobgar                                                                     |
| ----------------- | ----------------------------------------------------------------------------------- |
| **Product Owner** | Mahsulot qiymatini maksimal qilish, Product Backlog va Product Goal                 |
| **Scrum Master**  | Scrum'ni o'rnatish va Scrum jamoasining samaradorligi                               |
| **Developers**    | Har sprintda foydalanish mumkin bo'lgan Increment yaratish; ishni o'zlari baholaydi |

**Beshta event** (timebox'lar bir oylik sprint uchun; qisqa sprintda odatda qisqaroq):

| Event                    | Timebox          | Maqsad                                                   |
| ------------------------ | ---------------- | -------------------------------------------------------- |
| **Sprint**               | 1 oy yoki kamroq | Qolgan barcha event'lar uchun "konteyner"                |
| **Sprint Planning**      | maks. 8 soat     | Sprint Goal va ish tanlash: nima uchun, nima, qanday     |
| **Daily Scrum**          | 15 daqiqa        | Sprint Goal sari progressni tekshirish, rejani moslash   |
| **Sprint Review**        | maks. 4 soat     | Natijani stakeholder'lar bilan ko'rish, keyingi qadamlar |
| **Sprint Retrospective** | maks. 3 soat     | Sifat va samaradorlikni oshirish rejasi                  |

**Uchta artifact va ularning commitment'i:**

| Artifact        | Commitment             | Ma'nosi                                                         |
| --------------- | ---------------------- | --------------------------------------------------------------- |
| Product Backlog | **Product Goal**       | Mahsulotning uzoq muddatli maqsadi                              |
| Sprint Backlog  | **Sprint Goal**        | Shu sprint nima uchun kerakligi                                 |
| Increment       | **Definition of Done** | "Tayyor" degani nimani anglatishini belgilovchi sifat standarti |

Ikki muhim nuans:

- **Definition of Done** — Scrum Guide'da rasmiy: DoD'ga javob bermagan ish reliz qilinmaydi va Sprint Review'da ham ko'rsatilmaydi. **Definition of Ready** esa Scrum Guide'da umuman yo'q — bu jamoalarning o'z kelishuvi ([PM 5](/ios-lessons/pm-tools-workflow#sozlash)).
- Scrum'da PM qayerda? Rasmiy rol yo'q. Amalda PM ko'pincha jamoadan tashqaridagi ishlarni oladi: byudjet, shartnoma, bir necha jamoa va vendor bilan bog'liqliklar, buyurtmachiga hisobot.

**Tanqid** ([Wikipedia — Scrum](<https://en.wikipedia.org/wiki/Scrum_(software_development)>)): Martin Fowler Agile qadriyatlarini unutgan "marosimiy" jarayonlarni "faux-agile" deb ataydi. Ron Jeffries esa "Dark Scrum" tushunchasini kiritgan: Scrum tamoyillari chinakam o'rganilmasa, u jamoaga bosim vositasiga aylanadi. Belgilar: Daily Scrum — rahbarga hisobot, sprint — "majburiy va'da", retro — shikoyat kechasi.

Mobil jamoada 2 haftalik sprint reliz ritmiga yaxshi mos keladi: sprint oxirida TestFlight build, har ikkinchi sprintda App Store relizi ([release train, DevOps 2](/ios-lessons/devops-release#release-train)).

---

## 5. Kanban: oqim bilan ishlash {#kanban}

Kanban'da sprint yo'q. Ish tayyor bo'lishi bilan navbatdan tortib olinadi (pull), asosiy boshqaruv vositasi esa **WIP limit** — bir vaqtda jarayonda turadigan ishlar soniga chegara.

Kanban University'ning **Kanban Guide**'i 6 ta umumiy amaliyotni belgilaydi ([Kanban Guide](https://kanban.university/kanban-guide/)):

1. **Visualize** — ishni va workflow'ni ko'rinadigan qilish;
2. **Limit WIP** — parallel ishni cheklash;
3. **Manage Flow** — oqimni boshqarish;
4. **Make Policies Explicit** — qoidalarni ochiq yozish ("Code Review'ga o'tish sharti nima?");
5. **Implement Feedback Loops** — muntazam qayta aloqa;
6. **Improve Collaboratively, Evolve Experimentally** — birgalikda, tajriba orqali yaxshilash.

Guide'dagi rasmiy flow metrikalari — **Lead Time** (commitment nuqtasidan tugashgacha), **Delivery Rate** (vaqt birligida tugagan ishlar soni) va **WIP**. Amaliyotda keng ishlatiladigan **Cycle Time** (ish boshlangandan tugaguncha) va **Work Item Age** (jarayondagi ish necha kundan beri ochiq) Kanban University guide'ida alohida metrika sifatida ta'riflanmagan. Ularni hisoblash — [PM 7](/ios-lessons/pm-failures-career#flow).

Mobil jamoa uchun Kanban board namunasi (qavs ichida — WIP limit):

```text
| Backlog | Ready (5) | In Progress (3) | Code Review (2) | QA / TestFlight (3) | Done |
|---------|-----------|-----------------|-----------------|---------------------|------|
| IOS-120 | IOS-115   | IOS-110         | IOS-108         | IOS-104             | ...  |
| IOS-121 | IOS-116   | IOS-111         |                 | IOS-105             |      |
| ...     |           | IOS-112         |                 |                     |      |
                         ^ limit to'lgan: yangi ish boshlamang — Code Review'ga yordam bering
```

Qoida oddiy: ustundagi limit to'lsa, yangi ish boshlanmaydi — jamoa keyingi ustundagi tiqilinchni ochishga yordam beradi. Shu tufayli ishlar "deyarli tayyor" holatda to'planib qolmaydi. Shoshilinch ishlar uchun ko'pincha alohida **class of service** (masalan, "expedite" — navbatsiz o'tadigan production bug) kelishiladi.

| Mezon                   | Scrum                              | Kanban                                                |
| ----------------------- | ---------------------------------- | ----------------------------------------------------- |
| Ritm                    | Qat'iy sprint (1 oy yoki kamroq)   | Uzluksiz oqim                                         |
| Rollar                  | PO, Scrum Master, Developers       | Majburiy rol yo'q                                     |
| Sprint ichida o'zgarish | Sprint Goal saqlanadi              | Istalgan payt, WIP limit doirasida                    |
| Asosiy metrika          | Sprint Goal bajarildimi, Increment | Lead Time, Delivery Rate, WIP                         |
| Eng mos ish             | Mahsulot rivoji, yangi feature'lar | Support, bug oqimi, oldindan rejalab bo'lmaydigan ish |

---

## 6. Scrumban {#scrumban}

**Scrumban** — Scrum'ning qisqa iteratsiyalari va rejalashtirishini Kanban'ning WIP limitlari, vizual board'i va pull tamoyili bilan birlashtiradi ([Wikipedia — Scrumban](https://en.wikipedia.org/wiki/Scrumban)). Rejalashtirish ko'pincha qat'iy sprint boshida emas, **trigger** bo'yicha bo'ladi: masalan, "Ready" ustunida ish ma'lum chegaradan kamayganda.

Qachon mos: jamoa Scrum'dan Kanban'ga bosqichma-bosqich o'tmoqda yoki ishning bir qismi rejali feature'lar, bir qismi kutilmagan so'rovlar bo'lsa. Mobil jamoada bu tez-tez uchraydi: sprintda yangi funksiya, parallel ravishda esa production'dagi crash'lar va App Review javoblari.

---

## 7. Shape Up {#shape-up}

**Shape Up** — Basecamp (37signals) usuli. U baholash muammosini boshqa tomondan hal qiladi: **vaqt qat'iy, scope o'zgaruvchan** ([Shape Up](https://basecamp.com/shapeup)).

| Tushuncha           | Ma'nosi                                                                                               |
| ------------------- | ----------------------------------------------------------------------------------------------------- |
| **6 haftalik sikl** | Mazmunli ish qilishga yetarlicha uzun, deadline'ni boshidan his qilishga yetarlicha qisqa             |
| **Cooldown**        | Sikllar orasidagi ~2 hafta: mayda ishlar, bug'lar, keyingi siklni tanlash                             |
| **Appetite**        | "Qancha vaqt ketadi?" emas, "Bunga qancha vaqt sarflashga tayyormiz?"                                 |
| **Shaping**         | G'oyani mavhum ham, juda batafsil ham bo'lmagan holatga keltirish; "rabbit hole"larni oldindan yopish |
| **Betting table**   | Rahbariyat keyingi siklga qaysi shakllangan g'oyalarga "garov tikishini" hal qiladi — backlog yo'q    |
| **Hill chart**      | Progress: "tepaga" (noaniqliklarni yechish) va "pastga" (bajarish)                                    |
| **Circuit breaker** | 6 haftada tugamagan loyiha avtomatik uzaytirilmaydi                                                   |

Circuit breaker — eng qimmatli g'oya. "Deyarli tugadi, yana biroz vaqt" psixologiyasi loyihani cheksiz cho'zadi. Shape Up'da tugamagan ish to'xtaydi. Kerak bo'lsa, qayta shakllantirilib, keyingi betting table'da yangi garov sifatida ko'riladi.

Qachon mos: kichik, avtonom, dizaynga boy mahsulot jamoasi (dizayner va bir-ikki dasturchi) va o'z mahsuloti. Buyurtmachi har hafta hisobot so'raydigan outsourcing loyihasiga yoki ko'p jamoali enterprise'ga to'g'ridan-to'g'ri mos emas.

---

## 8. Miqyoslash: SAFe va LeSS {#miqyos}

Bitta mahsulot ustida bir nechta jamoa ishlasa, ularni sinxronlash kerak. Ikki mashhur, lekin falsafasi qarama-qarshi javob bor.

**SAFe (Scaled Agile Framework)** — joriy versiya **6.0**, Wikipedia bo'yicha 2023-yil martda chiqqan ([Wikipedia — SAFe](https://en.wikipedia.org/wiki/Scaled_agile_framework)). 2026-yilda "AI-Native SAFe" operating model qatlami sifatida targ'ib qilinmoqda ([framework.scaledagile.com](https://framework.scaledagile.com/)). SAFe 6.0 ning 4 core value'si: **Alignment, Transparency, Respect for People, Relentless Improvement**. 6.0'da "Program Increment" atamasi **Planning Interval**'ga, "SAFe Program Consultant" esa "SAFe Practice Consultant"ga o'zgargan ([What's new in SAFe 6.0](https://framework.scaledagile.com/whats-new-in-safe-6-0/)).

SAFe — eng ko'p tanqid qilinadigan freymvork ham:

- Scrum hammuallifi **Ken Schwaber** — "unSAFe at any speed" (2013);
- **Jeff Gothelf** — "SAFe is not Agile" (2021);
- umumiy tanqid: ierarxik, "yuqoridan pastga" boshqaruv va tashqi ko'rinishdagi agile.

> **Ogohlantirish:** "SAFe miqyoslash freymvorklari orasida ~30% ulush bilan birinchi" degan raqam ko'p uchraydi. Aslida u **2019-yilgi 13-State of Agile** so'rovidan olingan. Joriy 18-nashr ("The Adaptation Era") bo'yicha foizni tasdiqlay olmadik ([stateofagile.com](https://www.stateofagile.com/)). Eski raqamni 2026-yil holati sifatida keltirmang.

**LeSS (Large-Scale Scrum)** — Craig Larman va Bas Vodde yondashuvi, shiori "LeSS is Scrum" ([LeSS](https://less.works/less/framework/introduction)):

- **LeSS** — 2–8 jamoa: bitta Product Owner, bitta Product Backlog, bitta umumiy Sprint;
- **LeSS Huge** — 8 dan ortiq jamoa: Requirement Area'larga bo'linadi, har birida 4–8 jamoa va Area Product Owner;
- yangi boshqaruv qatlami qo'shmaydi, aksincha rol va jarayonlarni kamaytiradi; jamoalar koordinatsiyasi ko'proq kod va continuous integration orqali.

| Mezon        | SAFe 6.0                                              | LeSS                                      |
| ------------ | ----------------------------------------------------- | ----------------------------------------- |
| Falsafa      | Aniq rollar, darajalar, sertifikatlar to'plami        | Scrum'ni minimal o'zgartirib kengaytirish |
| Yangi rollar | Ko'p (masalan, Release Train Engineer)                | Deyarli yo'q                              |
| Joriy etish  | Mavjud ierarxiya va byudjet sikliga osonroq "tushadi" | Chuqur tashkiliy o'zgarish talab qiladi   |
| Xavf         | Byurokratiya, "ko'rinishdagi agile"                   | Tashkilot tayyor bo'lmasa, ishlamaydi     |

---

## 9. Outsourcing'da gibrid modellar {#gibrid}

Outsourcing'da ikki bosim to'qnashadi: buyurtmachi **bashorat qilinadigan** narx va muddat istaydi, jamoa esa **moslashuvchanlik** istaydi. Davlat va yirik korporativ buyurtmachilar rasmiy TZ so'rashi mumkin (GOST an'anasi — [PM 4](/ios-lessons/pm-requirements-tz#gost)). Natijada ko'p jamoalar tashqarida predictive, ichkarida adaptive ishlaydi:

```text
Buyurtmachi bilan (predictive)      Jamoa ichida (adaptive)             Buyurtmachi bilan
+-----------------------------+    +------------------------------+    +--------------------+
| TZ + shartnoma + narx       | -> | Sprint 1 -> Sprint 2 -> ...  | -> | UAT va qabul akti  |
| (scope baseline)            |    | har sprint oxirida demo      |    | (acceptance)       |
+-----------------------------+    +------------------------------+    +--------------------+
             ^                                   |
             +---- o'zgarish = Change Request (baho, narx, muddat) ----+
```

Uchta amaliy shakl:

- **Fixed price + ichki Scrum** — narx TZ bo'yicha, ish sprintlarda, har qanday o'zgarish change request orqali.
- **Time & Materials, yuqori chegara bilan** — soat bo'yicha to'lov, lekin shartnomada "not-to-exceed" (maksimal narx) chegarasi ([Wikipedia — T&M](https://en.wikipedia.org/wiki/Time_and_materials)).
- **Dedicated team** — vendor jamoa ajratadi, backlog'ni buyurtmachi boshqaradi; uzoq muddatli mahsulot uchun.

Shartnoma turlarining afzallik va xavflari — [PM 6](/ios-lessons/pm-risk-communication#shartnoma).

Gibridning eng katta xavfi: ichkarida "agile" deymiz, lekin buyurtmachi har sprint natijasini ko'rmaydi. Unda feedback yana oxiriga qoladi — ya'ni amalda waterfall. Har sprint demosiga buyurtmachi vakilini chaqiring.

---

## 10. Qaror jadvali {#qaror}

Quyidagi jadval — yuqoridagi manbalarga asoslangan mualliflik xulosasi, rasmiy standart emas:

| Loyiha yoki kontekst                                  | Tavsiya                                           | Asosiy sabab                                                  |
| ----------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------- |
| Davlat tenderi, fixed price, talablar to'liq yozilgan | Waterfall yoki PRINCE2 uslubidagi bosqichlar + TZ | Scope, narx va muddat shartnomada muzlatilgan                 |
| Tartibga solinadigan soha (bank, tibbiyot)            | Gibrid: rasmiy hujjat + ichki sprintlar           | Audit izi kerak, ichki tezlik ham kerak                       |
| Startap MVP, talablar noaniq                          | Scrum yoki Kanban                                 | Tez feedback, o'rganish tezligi                               |
| Bitta barqaror mahsulot jamoasi                       | Scrum                                             | Muntazam ritm, sprint review orqali stakeholder aloqasi       |
| Support, bug oqimi, incident'lar                      | Kanban                                            | Ish notekis keladi, sprintga sig'dirib bo'lmaydi              |
| Rejali feature + kutilmagan so'rovlar aralash         | Scrumban                                          | Ritm ham, WIP nazorati ham                                    |
| Kichik, avtonom, dizaynga boy jamoa                   | Shape Up                                          | Baho o'rniga appetite, circuit breaker                        |
| Bitta mahsulotda ko'p jamoa (enterprise)              | SAFe yoki LeSS                                    | Jamoalararo bog'liqlik; tanlov — tashkilot madaniyatiga qarab |
| Outsourcing, turli buyurtmachilar                     | Gibrid + change control                           | Buyurtmachiga bashorat, jamoaga moslashuvchanlik              |

Metodologiyani tanlagach ham uni "din"ga aylantirmang. Har retrospektivada so'rang: bu amaliyot bizga yordam beryaptimi yoki shunchaki marosimmi?

---

## 11. Xulosa {#xulosa}

- Metodologiya — "nima qat'iy, nima moslashuvchan" degan savolga javob. Waterfall scope'ni, Agile vaqt va narxni qat'iy qiladi.
- Agile Manifesto hujjatni inkor etmaydi: o'ngdagilar ham qimmatli, chapdagilar ustuvor.
- Scrum Guide (2020): 3 accountability, 5 event (Daily 15 daqiqa, Planning maks. 8 soat, Review maks. 4 soat, Retro maks. 3 soat), 3 artifact va 3 commitment. DoD rasmiy, DoR — jamoa kelishuvi.
- Kanban University guide'i: 6 amaliyot; rasmiy metrikalar — Lead Time, Delivery Rate, WIP.
- Shape Up: 6 hafta, appetite, circuit breaker. SAFe 6.0 va LeSS — miqyoslashning ikki qarama-qarshi falsafasi; "SAFe ~30%" raqami 2019-yilga tegishli.
- Outsourcing'da gibrid — norma, lekin buyurtmachi har sprint natijasini ko'rmasa, u amalda yana waterfall.

---

## Manbalar {#manbalar}

1. [Wikipedia — Project management triangle](https://en.wikipedia.org/wiki/Project_management_triangle)
2. [PMI — What is Project Management?](https://www.pmi.org/about/what-is-project-management)
3. [Wikipedia — Waterfall model](https://en.wikipedia.org/wiki/Waterfall_model)
4. [Manifesto for Agile Software Development](https://agilemanifesto.org/)
5. [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html)
6. [The Scrum Guide (2020)](https://scrumguides.org/scrum-guide.html)
7. [Wikipedia — Scrum (software development)](<https://en.wikipedia.org/wiki/Scrum_(software_development)>)
8. [Kanban University — The Kanban Guide](https://kanban.university/kanban-guide/)
9. [Wikipedia — Scrumban](https://en.wikipedia.org/wiki/Scrumban)
10. [Basecamp — Shape Up](https://basecamp.com/shapeup)
11. [Scaled Agile — SAFe Framework](https://framework.scaledagile.com/)
12. [Scaled Agile — What's new in SAFe 6.0](https://framework.scaledagile.com/whats-new-in-safe-6-0/)
13. [Scaled Agile — SAFe Core Values](https://framework.scaledagile.com/safe-core-values/)
14. [Wikipedia — Scaled agile framework](https://en.wikipedia.org/wiki/Scaled_agile_framework)
15. [State of Agile Report](https://www.stateofagile.com/)
16. [LeSS — Framework introduction](https://less.works/less/framework/introduction)
17. [Wikipedia — Time and materials](https://en.wikipedia.org/wiki/Time_and_materials)