Agile-ის მასშტაბირება ნიშნავს მრავალი გუნდის კოორდინირებას, რომლებიც ერთ პროდუქტზე მუშაობენ მძიმე, ზემოდან ქვემოთ მიმართული კონტროლის გადატანის გარეშე. ძირითადი გამოწვევა არის ავტონომიის და სწრაფი გამოხმელების შენარჩუნება, თუ სიმძლავრეების გუნდების გასწორებისას შესახებ საერთო მიზნებით და დამოკიდებულობების მართვა. რამდენიმე ჩარჩო სხვადსხვა გზით ეს პრობლემის გადაჭრას ცდილობს.
| ჩარჩო | იდეა | კომპრომისი |
|---|
| SAFe | ფენიანი სტრუქტურა, Agile Release Trains, PI planning | ძლიერი გასწორება; შეიძლება გრძნობილი იყოს მძიმე/დამკვეთელი |
| LeSS | Scrum მასშტაბირებული მინიმალური დამატებითი პროცესით | მსუბუქი; მოითხოვს რეალური ორგანიზაციული ცვლილებას |
| Spotify model | Squads, tribes, chapters, guilds | კულტურული ნიმუში, არა copy-paste ჩარჩო |
COMMON GOALS WHEN SCALING
- align teams on a shared product vision/roadmap
- make cross-team dependencies visible and managed
- keep each team as autonomous as possible
- preserve fast feedback despite added coordination
ერთი პლატფორმის რვა გუნდი მიღებული მაქვს დაკვартალური დიდი ოთახის დაგეგმვის ღონისძიება მიზნების გასწორებისთვის და დამოკიდებულობის ზედაპირზე დასაყენებლად, ხოლო თითოეული გუნდი ფლობს საკუთარი Sprint ტემპი და backlog-ს.
ცუდი მასშტაბირება ხელახლა აქმნის ბიუროკრატიას, რომელიც Agile ელი გამოიკვეთა, რაც სიჩქარეს კვდება, რომელიც ცვლილებას გამართლებული აღმოჩნდა.
სწორი ჩარჩო დამოკიდებული არის კონტექსტზე; უნარი კოორდინაციის overhead-ის დამთხვევა გუნდებს შორის რეალური დამოკიდებულობის დონიდან.