Как да подходим към прехода от Scrum към SAFe

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

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

Често се оказвате със Silo екипи, което на практика означава самостоятелни scrum екипи, които работят за постигане на местната си цел, но едва ли имат представа за крайната обща цел на цялата програма. Това е мястото, където Scaled Agile Framework (SAFe) влиза в действие.

Какво е SAFe?

източник: scaledagileframework.com

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

SAFe е изграден около няколко основни ценности.

Подравняване

• Всички scrum екипи трябва да разберат визията и стратегията и каква е крайната цел, към която вървят.
• Свържете стратегията между екипите и ги насочете към съвместно изпълнение.
• Комуникирайте с екипите с унифициран общ език, който лесно могат да разберат.
• Постоянно проверявайте дали екипите разбират целите и визията.
• Екипите трябва да бъдат ориентирани към клиентите и да разбират кои са клиентите и от какво имат нужда. Актуализирайте стратегията, за да отразите това.

Прозрачност

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

Уважение към хората

• Подчертайте какво означава да си човек. Не третирайте хората като ресурси.
• Цени разнообразието от хора и техните мнения. Поддържайте честна обратна връзка.
• Развивайте и обучавайте хората чрез коучинг и наставничество.
• Прегърнете, че вашият клиент е този, който консумира работата ви.
• Изградете дълготрайни партньорства в екипите и извън тях.

Безмилостно подобрение

• Изградете среда, в която решаването на проблемите мотивира екипите.
• Помислете как сте се справили миналата седмица и определете какво може да се направи по-добре следващия път.
• Приемете фактите като най-важния аргумент за подобряване на нещата.
• Осигурете време и пространство за иновации. Дайте възможност на екипите да експериментират и да изпробват различни маршрути, дори и да не са най-безопасните.

SAFe предоставя ниво на сътрудничество и комуникация към мащабирани Agile системи. Това не замества индивидуалните Scrum Team Sprint дейности, които правите днес.

Ключова част от всеки SAFe е Agile Release Train (ART). Това е дълготраен, стабилен екип от Scrum екипи (обикновено до 12 отделни екипа), който редовно предоставя нови допълнителни функции след всяко издание на спринт. Те разработват, доставят и поддържат едно или повече решения в работен поток.

източник: scaledagileframework.com

Роли на SAFe

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

#1. Гъвкав екип

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

Всеки Agile екип има набор от умения, за да изпълни своя договорен и ангажиран обхват. Екипът прилага този обхват, като увеличава всеки спринт по предвидим начин. Предсказуемостта е от решаващо значение, защото само тогава екипът може да се ангажира с постигането на конкретни цели в конкретно време. Комуникацията и доставката са ключовите ценности, които екипът непрекъснато подобрява.

Гъвкавият екип е основна част от сесиите за планиране на Program Increment (PI) за създаване на истории и планирането им в Sprints. И накрая, те се ангажират със собствените си PI цели.

Scrum Master тренира Agile Team и улеснява срещите на екипа. Те премахват пречките и защитават екипа от външно влияние. Те участват в Scrum срещи като част от ART.

Собственикът на продукта (PO) е друг специален член на екипа. PO е гласът на клиента и има пряко влияние върху историите и тяхното приоритизиране. PO комуникира с други PO, за да дефинира и приоритизира историите в неизпълнените задачи на екипите.

#2. Управление на продуктите

Продуктовият мениджмънт стои над scrum екипите и се грижи за подравняването между екипите. Те трябва да покрият следните отговорности:

• Постигнете бизнес целите, като гарантирате, че екипите за разработка създават осъществими и устойчиви продукти и решения.
• Разберете нуждите на клиентите и гарантирайте, че продуктите са завършени според определена гледна точка на клиента.
• Уверете се, че има достатъчно готови функции в натрупаните по всяко време.
• Подкрепете потока от работа през програмните табла и в програмния изоставане.
• Определете обхвата на следващото програмно увеличение, като предоставите приоритет на функциите, които екипите са създали. Продуктовият мениджмънт е в крайна сметка отговорен за дефинирането на следващия PI.

#3. Системен архитект / Инженеринг

Инженерният екип анализира и разработва съгласуваното съдържание на неизпълнените истории. Те са експертната част от екипа и покриват следните отговорности:

• Създайте и поддържайте Architectural Runway, така че новите функции да могат да използват технологичните средства.
• Участвайте активно в планирането на увеличаване на програмата. Присъствайте по време на демонстрациите на системата в края на всяка стъпка на програмата.
• Работете с гъвкави екипи за внедряване на нови активиращи архитектури. Само това ще позволи на екипите да изградят нови функции.
• Помогнете на гъвкавите екипи да дефинират дизайнерски решения и решения на високо ниво. Предложете алтернативни решения и най-добрия подход за доказване на концептуалните дейности в гъвкавите екипи.
• Те създават архитектурна писта. Това е дефиниция на технологични средства, готови да бъдат използвани от функции, които са дефинирани от съответните екипи.

#4. Собственици на предприятия / заинтересовани страни

Това са екипи, външни за екипите на Scrum, но те все още играят важна роля в рамката на SAFe на всеки етап от изпълнението.

Преди PI планиране:

• Осигурете принос към дейностите по прецизиране на натрупаните задачи.
• Участвайте в планирането преди PI, ако е необходимо.
• Гарантиране, че бизнес целите се разбират и приемат от ключовите заинтересовани страни във влака, включително инженера на влака за пускане (RTE), продуктовия мениджмънт и системните архитекти.

По време на PI планиране:

• Осигурете бизнес контекста и визията за предстоящия PI.
• Участвайте в прегледа на проектоплана и присвоете бизнес стойност на целите на PI на екипа.
• Участвайте в прегледа от ръководството и помогнете за разрешаването на проблеми, които ще доведат до приемането на окончателния план.

След PI планиране:

• Участвайте активно в поддържането на съответствие между бизнеса и развитието, тъй като приоритетите и обхватът неизбежно се променят.
• Помогнете за утвърждаване на определението за минимални жизнеспособни продукти (MVP) за Program Epics и насочете решението за завъртане или продължаване въз основа на доставката на MVP.
• Посетете демонстрацията на системата, за да видите напредъка и да предоставите обратна връзка.
• Посетете събития за планиране на спринт на Agile екип и ретроспектива на спринт, ако е необходимо.
• Участвайте в управлението на версиите, като се фокусирате върху обхвата, качеството, опциите за внедряване, версията и пазарните съображения.

#5. Освобождаване на влаков инженер (RTE)

RTE организира дейността на хората и екипите в рамките на ART. Това е ролята на Scrum Master за цялата програма. Основните отговорности са следните:

• Управлявайте и оптимизирайте потока на стойност през ART.
• Създаване и съобщаване на годишните календари за спринтове и увеличаване на програмата (PI).
• Бъдете модератор на срещи за планиране на PI.
• Организирайте екипи и им помогнете да създадат резюме на идентифицираните от тях PI цели. Прехвърлете целите на екипите в общите цели на PI плана.
• Съберете екипите, за да общувате и разрешавате рисковете и зависимостите помежду си.
• Свържете продуктовия мениджмънт, собствениците на продукти и други външни заинтересовани страни, за да обедините страните в тяхната обща стратегия.
• Организирайте семинарите за проверка и адаптиране с цел непрекъснато подобряване на вече съществуващи процеси и дейности.
• Оценете текущото ниво на зрялост на приемането на гъвкавата методология в екипите и дефинирайте елементите за последващи действия, за да подобрите екипите в бъдеще.

#6. Лидерство

Ръководството определя стратегията за програмата и дава на екипите всички необходими инструменти и подкрепа, за да им позволи работата. В крайна сметка те определят системата, в която всички останали работят. Ето защо е изключително важно да имате управленски екип, който дава на екипа правилната цел и определение на ценностите. Техните основни отговорности са следните:

• Водете с пример.
• Възприемете мислене за растеж.
• Подчертайте ценностите и принципите на SAFe.
• Развивайте хората.
• Водете промяната.
• Насърчаване на психологическа безопасност.

Планиране на увеличаване на програмата (PI).

PI Planning е събитие от два до три дни с цел разбиране и ангажиране с работата за следващото увеличение на програмата. Това може да е периодът на следващото тримесечие, например.

Управлението на продукта притежава приоритизирането на характеристиките, идентифицирани по време на планирането на PI. Гъвкавите екипи притежават планиране на капацитет, създаване на история, оценка и ангажираност към целите на PI.

PI планирането е от съществено значение за SAFe. Ако не правите PI планиране, това на практика означава, че не правите SAFe.

PI процес

източник: scaledagileframework.com

PI планирането започва с някои входни данни в таблицата. Всеки работен поток ще събере техните нужди и идеи за това какво биха искали да изградят по-нататък за своите продукти. След това го въвеждат в PI като вход:

• Топ 10 функции за внедряване по-нататък,
• ART Backlog от готови за формулиране епоси или функции,
• Визията на собственика на продукта.

Дискусията започва между различните работни потоци. Всеки от тях представя своите визии и характеристики. Те подчертават какво е важно да приложат след това и от какво се нуждаят, за да успеят, докато правят това. Това може да означава няколко различни неща:

• Активирането се доставя от други работни потоци, за да им позволи да продължат с функциите.
• Зависимост от други работни потоци и необходимостта подреждането да бъде приоритет.
• Текущи проблеми, които присъстват в системата и които първо трябва да бъдат коригирани, за да продължите.
• Кадрови предизвикателства пред отбора. Възможно е няколко ключови роли в екипа все още да липсват за внедряването на съдържание, което функциите изискват.
• Бюджетните ограничения не позволяват на вашия работен поток да изпълни визията в дадения график.
• Всички други рискове, проблеми, предположения или зависимости, които екипът може да разпознае и е необходима по-широка дискусия в останалите екипи на SAFe, за да се приведе в съответствие с общата цел.

PI Упътване

Самото планиране на PI често се разделя на няколко дни, обикновено два до три дни, където дневният ред може да бъде както следва:

Ден 1

• Обсъдете изложението на бизнеса и ключовите предстоящи цели, които формират цялостната програмна визия и стратегия. Ръководството притежава тази част и ясно комуникира с екипа.
• Поставете всички функции от работните потоци на масата и ги подредете по приоритет в съответствие с общата визия.
• Влезте във визията на Архитектурата и определете основните цели на изискванията за разработка. Подчертайте техническите предизвикателства и се договорете за разрешаване на препятствията между екипите.

Ден 2

• Обяснете подробно процеса на планиране на екипите. Очертайте очакваните резултати, след като PI бъде затворен.
• Направете Team Breakouts за първи път по време на планирането. Целта на екипа е да създаде проекти на планове и да идентифицира пречките и рисковете.
• След като пробивът приключи, екипите трябва да представят и прегледат проектите на плановете, които са създали, пред другите отбори.
• Следващата стъпка е за ръководството, където те преглеждат плановете и дават насоки за следващите инициативи за решаване на проблеми. Корекциите на плановете се правят въз основа на предизвикателства, рискове и пречки.

Ден 3

• Започнете деня с корекции в планирането, които вече са в съответствие с предходната среща на ръководството.
• Екипите ще разработят окончателните планове и ще прецизират рисковете и пречките. Собствениците на бизнес ще придадат бизнес стойност на целите на екипа.
• След това отборите ще представят окончателните планове пред цялата публика.
• Останалите рискове на ниво програма се обсъждат и се прилага ROAM (разрешена, притежавана, приета, смекчена) информация за риска.
• Екипите гласуват за доверието си в резултатите от планирането на програмата.
• Ако гласовете са твърде ниски или общото доверие е все още ниско, се извършва допълнително планиране.
• След PI ангажимента, RTE планира ретроспекция за екипите, за да обсъдят как върви планирането и какво да се подобри за следващия кръг. Ръководството посочва какво ще се случи напред заедно с окончателните инструкции.

PI резултат

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

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

Екипите ще документират и проследяват всички рискове на програмата и ще имат точен план как да се справят с тях.

Екипите също така ще заснемат всяка ретроспективна идея, с която са дошли в своята ретроспективна среща, и ще ги маркират като учебни уроци за следващата сесия за планиране на PI.

Що се отнася конкретно до отборите, има малко конкретни очаквания, като например:

• Екипите се ангажират с цели с бизнес ценности.
• Екипите ще изчислят своя капацитет на спринт, така че да могат по-добре да преценят осъществимостта на съдържанието на пътната карта.
• Те също така вземат предвид действителното натоварване за всеки спринт.
• Историите се пренасят в конкретните спринтове на всеки работен поток въз основа на предоставения капацитет.
• Екипите гласуват за доверие в плана на PI и съдържанието, което трябва да се достави.

Заключение

Не е необходимо това да изглежда очевидно, дори след като прочетете всички факти по-горе, но мога да ви кажа, че трансформирането на голяма организация в SAFe е изключително предизвикателна задача. Да, в някои случаи може да изглежда като мисия невъзможна. Въпреки че някои от тези основни принципи се прилагат, обикновено са необходими много итерации, за да се преобразува в състояние, в което спокойно можете да кажете, че вече сте в БЕЗОПАСНОСТ :).

Много често напредъкът разрушава някои йерархични принципи и правила от старата школа, които просто няма да умрат, колкото и да се опитвате. Можете да имате обширно PI планиране и резултати от някакъв вид, които можете дори да назовете с доверие. Но какво наистина означава, ако екипите от работния поток просто няма да работят в подходяща гъвкава методология?

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

Естествено, преди дори да обмислите внедряването на SAFe, просто бъдете наясно с факта, че вече сте усвоили принципите и начините на работа на Agile екипа. Не само от гледна точка на лидерството, но оставете екипите да гласуват и да изразят своето честно мнение. Може да се изненадате от резултатите.

След това вижте добри учебни ресурси за гъвкаво сертифициране.

Беше ли полезна тази статия?

Благодарим Ви за обратната връзка!