В последно време дигитализацията и Agile трансформациите станаха ключови тенденции в съвременния бизнес свят. За да оцелеят в новата динамична среда, много от компаниите преминаха към гъвкав начин на работа, който комбинира насоки от няколко съвременните Agile подходи (frameworks). Тези от вас, които слушаха уебинара ни “Embracing Agility: Roadmap to Scaling Your Agile Transformation”, вече са запознати с различните подходи и как успешно те могат да бъдат приложени и скалирани на ниво организация. Освен това имате и видимост върху потенциалните предизвикателства, които може да срещнете по пътя, както и полезни насоки, с които да ги преодолеете.
По време на уебинара получихме много въпроси, за част от които не стигна времето да ги покрием. Затова ви предоставяме техните отговори в писмен формат като част от тази блог статия. Приятно четене!
Q1: Как използването на Agile методологията се вписва в решаването на инциденти и “first, second, ….. X level” ескалации?
Както във всичко останало, така и в Agile трансформацията няма една рецепта, която да ни подсказва какво решение да вземем в сферата на Incident Management.
Всичко зависи поне от:
- Естеството на инцидентите – например съотношение на „стандартни“ инциденти спрямо такива, които изискват специфични решения;
- Организационната структура или дълбочината на трансформацията – например дали екипите за поддръжка ще се организират на база на веригата на доставка (Value stream) или ще са с функционална структура (Application support, network operations, service desk и т.н.);
- Архитектура или специфични технологии – например loosely coupled vs monolithic, степента на зрялост или стабилност на продуктите и услугите;
- Взаимоотношения с партньори и доставчици – дали части от incident management или въобще услугите за поддръжка се осъществяват от външни организации и ако „да“, какъв тип са ни договорите – договори за услуга с ясен SLA, или Time& Material;
Като основни насоки организациите могат да помислят за следните решения:
- Реструктуриране на традиционния модел на поддръжка „first, second, ….. X level ескалация“ към някои от вариантите на Swarming, който се доближава до степента на сътрудничество, което имаме в agile екипите:
- Структуриране около хоризонтално многофункционален (cross-functional) екип, който работи в много тясно сътрудничество;
- Dispach Swarm:
- Подбира инцидентите с бързи решения и ги разрешава директно, за по-сложните се идентифицират хората, които могат да ги решат в последствие
- Проверява дали имаме необходимата информация за разрешаването
- Backlog swarm – периодично преглежда инцидентите, които са останали неразрешени
- Drop-in swarm – екпертите са постоянно на разположение на service desk агентите
При swarming модела разрешаваме ключовите проблеми, които съществуват при традиционната поддръжка на нива като: инцидентите чакат на множество опашки, което води до съществено забавяне в тяхното разрешаване, ефекта на пинг-понг, при който инцидентите се прехвърлят между различни екипа (по дефиниция се ескалират/пренасочват, когато липсва компетентност за разрешаване), някои функционални групи се претоварват.
- Екипите за поддръжка стават част от agile екипите, като инцидентите се третират като част от backlog-а на екипа и се приоритизират заедно с новите разработки и т.н. При тази ситуация също може да се запази първо ниво и да разрешава стандартните инциденти, останалите да отиват в agile екипа;
- Предоставяне на поддръжката „като услуга“ с ясни SLAs;
- Хоризонтално структуриране на екипа около веригата за доставка на стойност – например регистриране на инцидента, класификация, разработка или доставка на patch за разрешаване на инцидент, прилагане на пача, комуникация с клиенти и доставчици и т.н.
Вероятно има още много варианти, като дори описаните тук често се ползват в комбинация.
Q2: При слагането на общ знаменател на целият екип, как се отличават личните качества на отделните кадри?
Темата наистина е интересна. Общият знаменател обикновено означава, че екипът, включително и Product Owner-a преследва общи цели и това е в основата на подобна конфигурация. В същото време не трябва да забравяме, че всеки екип е изграден от индивидуалности, всяка от тях с различни качества, експертиза, опит и мотивация.
Препоръчваме следната статия на Harvard Business Review, където се разглежда модел, при който индивидуалните награди в екипна среда могат да доведат до подобрено представяне, както на индивидуално, така и на отборно ниво.
Все пак трябва да се внимава да не се получи „ефектът на героя“. Ако хората знаят, че се борят за една и съща награда (да не се бърка с постигането на цел пред екипа), може да се получи така, че някои членове на екипа поемат повече работа, задържат информация и не я споделят, работят повече часове и не си помагат. Затова трябва да сме внимателни.
Искаме да припомним обаче и, че повечето предизвикателства в agile екипа се посрещат от самия екип. В този смисъл препоръката ни е – създайте практика самият екип да възнаграждава най-добрите си членове по тяхна преценка. Например веднъж месечно, на ретроспекция, екипът гласува кой от неговите членове заслужава тяхното собствено признание. Може да е бонус, или някаква друга награда по преценка на екипа. Ролята на мениджмънтa е да подсигури наградата, а не да решава кой да я вземе. В крайна сметка, наблюденията ни са, че членовете на екипите търсят признанието най-вече на своите съотборници. Точно както един футболист бива поздравен от съотборниците си при отбелязването на красив гол, или когато вратарят направи трудно спасяване.
Q3: Ще се радвам да споделите впечатления за имплементиране на SAFe за нетехнически екипи (финанси, ЧР, Правен и пр.).
SAFe и Agile като цяло могат да се използват във всяка една област, продукт или услуга произвеждащи стойност. От перспективата на SAFe, основна стъпка в изграждането на екипа от екипи (влакът или Agile Release Train) е да го сформираме около конкретни потоци на стойността (value streams). Много често конкретни стъпки от тях са подсигурени от нетехнически функции, например маркетинг. Според нуждата можем да им заделим вагон (да са отделен екип) или да са качени на влака като заинтересовани страни и подпомагащи работа, например като участват на PI Planning, което най-малкото ще им подсигури видимост и синхрон.
Друг пример може да бъде активното участие на Legal и Compliance в дефинирането на някои нефункционални изисквания (NFRs), валидни за целия влак.
Разбира се, говорейки за потоци на стойност, може да има такива, които по никакъв начин не са свързани със софтуер. Те могат да се възползват от същите практики – PI Planning, alignment, крос-функционални екипи, итериране и т.н.
Ние, например, имаме случай, в който съдействахме на HR отдел да приложи гъвкави практики като планиране в каданс, приоритизация, беклог и др., вдъхновен от Agile начин на работа в SAFe конфигурация в същата компания.
Q4: Как и доколко се вписва IT инфраструктурата в Agile?
IT инфраструктурата се вписва и е важно да е част от Agile топологията на екипите като честа практика е да е отделен екип или екипи, които предоставят услуги на продуктовите Agile екипи (Agile екипите са техни клиенти). Беклог (backlog) се състои от сторита, които са за нефункционални/технически компоненти, които са нужни на продуктовите екипи, сторита за модернизиране и подобряване на стабилността, производителността, скалируемостта на инфраструктурата, за разрешаване на инциденти и проблеми, за автоматизации и т.н. Честа практика е тези екипи да прилагат повече Kanban отколкото SCRUM като планират проактивната си работа в каданса и в синхронизация с всички останали екипи.
Q5: Бихте ли дали пример кога една Agile трансформация НЕ Е препоръчителна или кога НЕ БИ сработила?
Agile трансформацията е препоръчителна винаги и навсякъде в днешно време. Може да има фактори като регулации, ограничения на технологиите, сложно финансиране и други, които да налагат повече администрация, одобрения и процеси от това, което носи реална стойност за развитието на продукта, но това не трябва да ни спира да прилагаме Agile, а да измислим практиките и ролите така, че да включим тези допълнителни изисквания.
Q6: За всеки тип бизнес ли можем да приложим Agile ?
Да. В недигиталната част от бизнеса като минимум ще развиваме agile култура и поведение, децентрализиране на решенията и доверие. Дори само това ще донесе ползи, а ако с интерпретация на софтуерните практики променим и практиката на работа и направим мултидисциплинарни екипи ще имаме още повече стойност.
Q7: Как могат организациите да предотвратят Agile практиките да се превърнат в микроменажиране?
Темата е изключително сериозна и често причините са дълбоки и не са се появили от вчера. Обикновено такъв стил на мениджмънт е присъствал и преди това, но с Agile се получава едно осветляване на подобни практика, защото концепцията за автономни, самоорганизиращи се екипи се сблъсква с традиционните стилове на управление, и това много бързо става видимо. Традиционно, това е съпротивата на средното ниво на управление към промяната, която е неизбежна при подобна трансформация и начин на работа.
Q8: Бихте ли споделили вашия опит в организации от различни сфери, какви са предпочитаните и работещи подходи, напр. Big bang или поетапно въвеждане на Agile?
Във всеки случай трябва да имаме визия за бъдещата Agile организация от самото начало. След това е най-добре да стартираме с 1-2 скалирани Agile продуктови екипи и постепенно в ритъм да стартираме следващите продуктови екипи, докато обхванем цялата организация. На практика инкременталният подход не работи, ако нямаме цялостна визия и не действаме ускорено в комбинация с добавяне на продукти. Стартиралите екипи може да се окажат изолирани и затруднени, ако корпоративните практики не се променят и екипите, с които имат зависимости продължават по стария начин за прекалено дълго време. Това е основната причина много компании да изберат big bang с по-дълга подготовка за стартиране и това работи добре, ако компанията не е много голяма (около 300 човека).
