11 най-чести причини да използвате Scaled Agile Framework (SAFe) и как да се справите с това с неразмерен Scrum

И защо това е по-ефективно от използването на SAFe

За да се определи неефективността при работа с множество екипи, често някой предлага да въведе рамка за мащабиране. С повече екипи възникват всички видове проблеми. Въвеждането на рамка за мащабиране звучи като идеалното решение. Така ли е?

Най-известният пример за такива рамки е Scaled Agile Framework (SAFe). На ниво Повишаване на програмата SAFe представя Scrum като един от начините за създаване на нарастване на продукта. С това адаптирана версия на Scrum често е част от SAFe.

Когато хората въведат SAFe, те въвеждат допълнителни събития, артефакти, роли и правила. Това допълнително увеличава сложността на средата им, което може да доведе до техните собствени предизвикателства и проблеми. Често рисковете, които хората въвеждат със SAFe, са по-големи от проблемите, които искат да решат със SAFe.

Въпреки това, най-честите причини за използване на SAFe могат да бъдат отстранени, като се използва само Scrum, толкова лек, колкото е. Сега ще ви покажа, че нямате нужда от SAFe за справяне с най-често срещаните проблеми с мащабирането.

От cocoparisienne в Pixabay

1. Управление на взаимоотношенията между екипите за предоставяне на увеличение

Когато няколко екипа работят върху един и същ продукт, тези екипи често са зависими един от друг. Отбор А може да изисква действия от Отбор Б и обратно. С SAFe можете да идентифицирате тези видове зависимости по време на планирането на увеличаване на програмата, обикновено разглеждайки няколко спринта.

Scrum има чудесен начин да премахнете този проблем:

„Екипите за развитие са многофункционални, с всички умения като екип, необходим за създаване на увеличение на продукта;“ - Scrum Guide 2017

Всеки екип за развитие трябва да може да достави работещо парче от продукта. Ако съществуват зависимости между екипите, които ги ограничават да правят това, тогава разгледайте начините за преструктуриране на екипите, така че зависимостите вече да не са там. С това първата причина за използване на SAFe ще изчезне.

2. От визия до ниво на продукта / хармонизиране на ниво предприятие с ниво на екип

Често продуктовата визия се създава далеч от екипите на Scrum, където се изграждат ценните продукти. Със SAFe има допълнителни слоеве (за портфолио и / или големи решения), предназначени да помогнат да се намали визията до изоставането на екипа.

Ето как можете да решите това с Scrum:

„Product Backlog е подреден списък на всичко, за което се знае, че е необходимо в продукта. Това е единственият източник на изисквания за всички промени, които трябва да бъдат направени в продукта. “ - Scrum Guide 2017

Да, продуктовото изоставане е мястото, където представяте как искате да преминете от визия към стойност. Често виждате, че се записват само елементите, както се възприемат, необходими за следващите няколко спринта. Ръководството за Scrum обаче е много ясно, че всичко, за което се знае, че е необходимо, трябва да има. Не е необходимо да се разгражда напълно, можете да имате неясни предмети, които представляват големи късове работа.

3. Изравнете лицата, които вземат решения за продукта и собственика на продукта

Често решенията за посоката на продукта са извън обсега на притежателя на продукта. SAFe се грижи за това с роли като собственик на бизнес и собственик на Epic.

Ето как можете да го решите само със Scrum:

„Собственикът на продукта е отговорен за максимално увеличаване на стойността на продукта в резултат на работата на екипа за развитие.“ - Scrum Guide 2017

Ако разрешите на собственика на продукта да бъде отговорен за увеличаване на стойността на продукта, нямате нужда от допълнителни роли, както са дефинирани в SAFe.

Възможно е сега да сте в различна ситуация, в която продуктовата отговорност и отговорността за продуктовото изоставане са разделени. Въпреки това, за да бъдете по-ефективни в продуктова среда с множество екипи, помислете дали да промените това, като разширите ролята на собственика на продукта.

4. Дайте най-високо ниво на организацията механизъм за контрол

Хората от най-горния слой на организацията често не знаят как точно работят екипите за създаване на ценни продукти. Те не се чувстват като замесени или контролирани. SAFe има редица слоеве и събития за това. В грешни ръце, обаче, това може да бъде злоупотребено с цел принудително управление отгоре надолу.

Scrum предоставя перфектното - чисто и просто - място за оценка на текущото състояние и обсъждане на това, което следва след това:

„По време на Sprint Review, Scrum Team и заинтересованите страни си сътрудничат за това, което е направено в Sprint. Въз основа на това и всички промени в продуктовия залог по време на спринта, участниците си сътрудничат по следващите неща, които биха могли да се направят за оптимизиране на стойността. “ - Scrum Guide 2017

Да, Sprint Review е вашето събитие, ако искате да обсъдите текущия продукт и неща, които могат да повлияят на решенията какво да правите по-нататък. Тя е директна и е ефективна, защото всички участващи могат да бъдат част от дискусията.

Няма значение каква е вашата роля. Ако искате да повлияете на посоката на продукта, посетете Sprint Review!

5. Синхронизиране на стъпки за доставка / интегриране

В продуктова среда с множество екипи, Agile Release Vlains на SAFe са там, за да синхронизират доставката към версии за множество екипи.

С Scrum екипите имат множество начини да синхронизират работата си. Основното в това е:

„Множество екипи от Scrum често работят заедно върху един и същ продукт. Един опис на продукта се използва за описание на предстоящата работа върху продукта. “ - Scrum Guide 2017

Това предполага следното:

1 Блог на продукта → 1 Собственик на продукт → 1 Увеличение на продукта → 1 Sprint Review.

С това синхронизирането вече е автоматично на място, тъй като има 1 Увеличение на продукта, което трябва да бъде проверено по време на 1 Sprint Review. Емпиричният подход за контрол на процеса на Scrum не трябва да бъде обезсилен поради подобни проблеми със синхронизирането на изданията. Ще прекъсне цикъла за обратна връзка.

Вместо това екипите трябва активно да търсят начини за улесняване на интеграцията по истински Agile начин:

„Те си сътрудничат и си взаимодействат чрез усъвършенствани архитектури за разработка и целеви среди за освобождаване.“ - Scrum Guide 2017

6. Подобряване на производителността

SAFe често се въвежда с цел повишаване на производителността на екипите. Причината за по-ниската производителност може да бъде комбинация от някой от гореспоменатите проблеми:

  • Управление на зависимостите между екипите за предоставяне на повишение;
  • От визия до продуктово / хармонизиращо ниво на предприятието с нивото на екипа;
  • Дайте най-високо ниво на организацията механизъм за контрол;
  • Синхронизиране на добавки / интегриране на стъпки.

Подобряването на тези области би довело до подобряване на производителността. Подобренията в производителността до голяма степен се сравняват с традиционните подходи за изпълнение на проекти (в района на водопада).

Вече обсъдих как ефективно могат да бъдат направени тези подобрения в Scrum. В резултат Scrum вече ви помага да постигнете значително подобрение на производството. За това не е необходимо да използвате SAFe.

7. Увеличете доставката на стойност

SAFe се представя като алтернатива на традиционното управление на продуктите. С използването на Lean и Agile принципи и рамки като Scrum, SAFe се фокусира върху изграждането на правилното нещо. SAFe има редовни моменти на размисъл, за да може да гарантира това.

Повечето от тези моменти на размисъл обаче са вече вкоренени в Scrum. По дяволите, SAFe използва моментите на размисъл, както са дефинирани в Scrum (като Sprint Review и Sprint Retrospective), като се нуждаят само от допълнителни моменти на размисъл поради допълнителната сложност.

Това, което изпъква при Scrum, е, че тези моменти на размисъл - при ключовите заинтересовани страни - са длъжни да се случват по-често, защото се случват всеки спринт, вместо всяка двойка спринти (с SAFe). Това дава възможност за по-голяма пъргавина, повече възможности за адаптиране към новата информация, което води до по-големи шансове да увеличите доставката на стойността си.

8. Повишаване на качеството

SAFe има „Вградено качество“. Това е един от начините да се гарантира, че доставените продукти отговарят на фирмените стандарти за качество. Част от вграденото качество е дефиницията на „Готово“ на екип.

Scrum обаче се стреми да направи същото с това определение на „Готово“. Той вече трябва да включва стандартите за качество на компанията. Определението на „Готово“ обикновено се определя на ниво организация за развитие. Не на ниво отбор.

SAFe изтъква, че вграденото качество е повече от определението на Scrum за „Готово“. Не съм съгласен с това. Определението на „Готово“ е това, което създава организацията за развитие. Може да включва същите неща като вграденото качество на SAFe.

9. Организационна схема - какво да правя с всички хора, работещи върху продукта?

SAFe има удобен отговор на въпроса, където всички хора от организацията се поберат, когато работят „Agile“. С многото роли винаги има място за всички (управление на бизнеса, управление на продукти, системни архитекти, системни инженери, инженер за освобождаване на влакове и още повече за по-големите решения).

Наличието на всички тези роли в SAFe позволяват позиция, която „да се вписва толкова лесно в съществуващата организация.“ Това би могло да премахне необходимостта от реални - болезнени, но необходими - промени в организацията. С това може да се превърне в организация, която изглежда „Agile“, но всъщност не е „Agile“, пропускайки всички предимства на работата по пъргав начин.

С Scrum няма толкова лесен отговор. Scrum знае само три роли (Собственик на продукт, Scrum Master, член на екипа за разработка) и заинтересованите страни. Важно е да се разбере, че това са роли в Scrum. Това не е / не трябва да е същото като функция на компанията.

Scrum е рамка. Дава ви платно и как вие създавате своята картина зависи от вас. Но ето няколко примера за решаване на въпроса кой отива накъде:

  • Продуктов мениджър може да бъде Собственикът на продукти на Scrum или ключов участник;
  • Системният инженер може да бъде част от екипа за развитие или ключов участник;
  • Системният архитект може да бъде част от екипа за развитие или ключов участник;
  • Собственикът на продукта, както е дефиниран от SAFe (работи в екип от екипи), може да бъде част от екипа за разработка като продуктов експерт или да бъде собственик на продукта.

Scrum ви дава свободата да го прилагате, както смятате за най-изгодно. За това не са ви необходими допълнителни роли или събития. Всеки може да има място в подхода си, за да използва рамката Scrum.

10. Управление на програма с множество продукти

Друга причина за въвеждането на SAFe е да управлявате програма с множество продукти с много зависимости.

Може да спорите, че вече обсъждах зависимостите (тема 1 и 5 идват на ум). Въпреки това искам да представя този пример за няколко продукта конкретно.

Първото нещо е: не е ли това смесване на управление на проекти и управление на продукти?

SAFe и Scrum са решения за доставяне на ценни продукти. И двете НЕ са рамки за управление на проекти.

Ако имате различни продукти с много зависимости, трябва да преразгледате това, което определяте като свой продукт. Преоценка на дефиницията на даден продукт и в резултат на това може да бъде преоценка на вашето продуктово портфолио. Това най-вероятно ще увеличи прозрачността (като кой е отговорен като собственик на продукта) и ще премахне очевидната необходимост от използване на SAFe.

11. За да подравните няколко собственици на продукти по посоката на продукта

SAFe често се разглежда и като решение за изравняване на множество собственици на продукти, отговорни за даден продукт. Работата може след това да се намали от програмата или портфолиото до изоставането на екипа, разделено на собственика на продукта.

Проблемът с това е, че един продукт трябва да има само един собственик на продукт (1 продукт заден ход → 1 собственик на продукт). Следователно да имаш няколко собственици на продукти за даден продукт е анти-модел. Ако премахнете този проблем, вие също така отнемате необходимостта от този тип подравняване и причина да използвате SAFe.

Долната линия

Scaled Agile Framework (SAFe) предлага решения за много често срещани проблеми, ако искате да преминете към начин на работа с по-голяма гъвкавост. Не се нуждаете обаче от всички звънци на SAFe, ако искате да решите проблемите си. Можете да разрешите същите проблеми с Scrum, рамка, която е наистина лека. Използвайки Scrum самостоятелно, избягвате излишна сложност и режийни разходи.

Моят съвет винаги ще бъде да определите какви са истинските ви нужди и да започнете с малки.

По-лесно е да добавите сложност, отколкото да я премахнете. Затова винаги бъдете внимателни, когато добавяте много сложност едновременно. Опитайте се да го добавите постепенно и разберете дали наистина имате нужда от него и дали наистина решава проблема ви. Веднъж там е трудно да се премахне.

Scrum е един от начините да започнете с малки. Ако сте овладели достатъчно Scrum и все още чувствате, че нещо липсва, винаги можете да потърсите начини за мащабиране. Тук SAFe е една от опциите, но има и LeSS, Nexus, Scrum @ Scale и други.

Ще бъдете приятно изненадани от силата на Scrum. Просто мащабирайте само с Scrum.

Скалираният Scrum все още е Scrum. Прост и мощен.
Искате ли да пишете за Serious Scrum или сериозно да обсъждате Scrum?