Из дневника на един Scrum Master
Един ден Любо ми се обади, за да ми каже, че има идея за „Дневникът на един Scrum Master“. В него той искаше да споделя с всички за нещата, които го вълнуват в ежедневната му работа; за болежките, които го мъчат като Scrum Master и, за които не спира да търси „лек“ (или поне „обезболяващо“); за експериментите и провалите, които му показват „правилния път“ и му помагат да „израства“; за казусите, които успява да „разплете“ (или „заплете“ още повече) и още куп, куп други неща. До края на разговора ни и аз вече бях толкова развълнуван, че без да му мислим решихме да го направим като част от инициативите на agify.me. Смятам, че ползите за общността биха били големи – аз лично не се сещам в българското пространство да има някой, който да споделя в детайли за своите перипетии като Scrum Master? А това може да е безценен ресурс, както за всеки начинаещ, така и за по-напредналите Agile / Scrum практици. A aз обещавам да помагам на Любо, но без да „цензурирам“, „променям“ и „полирам“ преживяното – хихи, или поне не много! 🙂 За да бъде дневникът възможно най-автентичен и така да ви даде възможност да се гмурнете и усетите живота на един български Scrum Master – такъв, какъвто е.
Издание 12
Публикувано на 30.06.2022 г.22/06/2022 г.
Два дена преди края на спринта, не добавяйте таск за някой програмист, защото е останал без такъв. По-добре помислете върху причините това да се случи (лошо планиране и невярно оценяване на тасковете) и нека използва това време за себеразвитие.
21/06/2022 г.
Не е добра идея Епика да се разбие директно на дев таскове. Трябва да се раздели първо на user сторита, всяко едно от тях да има стойност и от тях да произлязат въпросните задачи за разработчиците.
20/06/2022 г.
На Ретрото не могат и не трябва да присъстват хора, извън Екипа. В противен случай, ще се наруши доверието и “безопасната среда”.
16/06/2022 г.
Един от най-сложните въпроси в моята професия е “Каква е ролята на мениджмънта в Скръм?”
Издание 11
Публикувано на 16.06.2022 г.13/06/2022 г.
На Scrum of Scrums е хубаво да се обсъждат и добри практики, а не само казуси.
12/06/2022 г.
Не, няма да ми кажа коя задача да вземеш, ми реши, в To Do са. 🙂
08/06/2022 г.
Единият от екипите си счупи рекорда за разработени стори точки в един спринт (УРАААА!!!)
07/06/2022 г.
СМ трябва да бъде наясно със стратегическите промени в организацията. В противен случай, СМ и организация могат да дърпат едно въже, но от противоположните му страни.
06/06/2022 г.
С един от екипите обсъждаме как ревюто на кода да е по-оптимално. Стъпките са три: не приемай лично коментарите по хода, занимай се с ревю няколко пъти на ден и не бъди дребнав (работи ли функционалността или не).
02/06/2022 г.
Има пробойни в кораба. Корабът е метафора за компанията, а пробойните са напускащите кадри. Една от ролите ми като СМ е да оползотворявам най-добре наличния ресурс. Но не можеш да запушваш пробойни, когато ти е дадена кофа…
Издание 10
Публикувано на 02.06.2022 г.31/05/2022 г.
Идва сезонът на отпуските. Затова трябва да се съсредоточим върху създаването на таскове, които могат да бъдат на щафетен принцип (един колега излиза в отпуска преди да е довършил дадено задание, друг да е способен да я довърши). Това би се постигнало с подробни Refinement и Standup сесии.
27/05/2022 г.
Работейки с международни екипи, понякога се получава езикова бариера. В такива случаи, препоръчвам с много прости примери да се обясни желаното нещо. Или да се намери колега преводач. 🙂
26/05/2022 г.
Добрият СМ не е фокусиран само върху Екипите си, но и върху цялата организация в Компанията. СМ е “Аgile Посланик”.
25/05/2022 г.
Стори точките не служат само за палнирането на спринта чрез следене на скоростта на Екипа. Ако един Епик е оценен с СТ правилно, то може да се изчисли колко спринта ще са необходими на Екипа да го разработи. Тази информация е важна за Продуктовия собственик и Клиента.
23/05/2022 г.
Избягвайте да имате задачи в спринта, които не са свързани с целите му. Доста често се получава тези Ad hoc задачи да разфокусират.
20/05/2022 г.
DoD (Definition of Done) трябва да бъде съгласувана с Екипа, да я ясна, еднаква и прозрачна за всеки негов член.
Издание 9
Публикувано на 19.05.2022 г.17/05/2022 г.
СМ трябва да е асертивен. Да не е началнически-изискващ, но въпреки това да настоява за повече информация, когато е необходима.
16/05/2022 г.
Прочетох пост, който гласеше: „Ако използваш Jira, не означава, че си Agile“. Така е...
12/05/2022 г.
Желанието на Продуктовия собственик на добавяне на задание в Спринта може да не бъде уважено... това е част от работата на СМ, да пречени капацитета на Екипа и да го обсъди с тях в такива ситуации. ПС ще е като Мечо Пух: „Колкото повече, толкова повече“ :)
11/05/2022 г.
Не започвайте нов Епик преди старите да са довършени. Така избягвате проточване на разработката на вече започнатите.
10/05/2022 г.
Ако постоянно се добавят тикети в спринта, освен че става ясно, че Планирането не е било добро, означава, че и на Ретрото трябва да си поговори Екипът дали оценява правилно.
09/05/2022 г.
Ако тикет „играе“ пинг-понг между „In Progress“ и „Code review“, питай екипа каква е причината, ако може да се оправят коментарите в отделен тикет, най-добре. Така въпросното задание няма да отнеме половин спринт.
Издание 8
Публикувано на 05.05.2022 г.04/05/2022 г.
обрите тестови сценарии могат да спестят доста бъгове.
29/04/2022 г.
Когато на стендъпа ти се каже, че има казус с дадена задача, но без много подробности, СМ трябва да задава въпроси, за да разбере корена на проблема. Не само за да има аргументация, ако целите на спринта не са доставени, а и Екипът трябва да свикне, че дейлито е и за това, а не е репортуване.
28/04/2022 г.
Чудеса се случват. Екипът ти казва, че има още работа по тикетите в „In progress“, ден преди спринта, има затруднения и спънки, но магечески са приключени до края му. В такива ситуации, задължително на ретроспекцията трябва да се говори с Екипа дали реално е използвал капацитета си на пълно, дали наистина скоростта му е такава, каквато е показана в чартовете.
27/04/2022 г.
Знаете ли какво е ОКR? Objectives and key results. Реално зад тях седи идеята на базата на стратегическите цели на компанията да не бъдат включвани задания в спринтовете, които не са релевантни с тяхното постигане.
26/04/2022 г.
Мит е, че Скръм се фокусира в двуседмични спринтове (или месечен). Да, екипът трябва да се съсредоточи върху задачите, за които се е съгласил в спринта, за да ги имплементира и да постигне спринт целите. Но част от работата на Скръм Мастъра е да има по-широк кръгозор. Заедно с Продуктовия собственик да се уверят, че има подготвени задания за следващия спринт (най-често това се случва на Kick off или Refinement сесиите).
Специално издание 7
Публикувано на 21.04.2022 г.
11/04/2022 г.
Управлението на конфликти е трудно, защото не винаги членовете на екипа имат желанието, мотивацията и разбирането, че един конфликт трябва да бъде решен навреме и това е възможно само ако си с отворено съзнание.
07/04/2022 г.
Понякога Скръм не е подходящата рамка за даден проект, екип, нагласа, ниво на зрялост на екипите. Като Скръм мастър съм длъжна да прилагам frameworks в името на ефективност, продуктивност и щастие, и да бъда гъвкава.
04/04/2022 г.
Трудно се постига баланс между доверие, servant leadership и приятелска атмосфера, когато навлизаш в нов екип.
31/03/2022 г.
Когато успееш да убедиш и другият да разбере, че всъщност логването на време и обновяването на задачите не е мениджърско следене, а осигурява прозрачност и видимост за всички, които се интересуват от проекта, но не участват активно в живота на екипа, можеш да се потупаш по рамото!
Издание 6
Публикувано на 07.04.2022 г.06/04/2022 г.
Добра практика е продуктовия беклог да е отделен от този на спринта, така се постига по-голяма яснота за текущите цели и резерви.
05/04/2022 г.
Когато на „Estimation“ сесия има разногласия в оценките, нека първо говори най-неопитния, за да изкаже мнението си необременено от по-опитните.
04/04/2022 г.
СМ отговаря ли за доставянето на дадено задание?
31/03/2022 г.
Ревюто/Демото не се прави за мениджмънта. Целта му е да покаже на стейкхолдърите какво е произвел екипът.
29/03/2022 г.
Не е правилен подход един програмист да работи по един епик сам, тъй като се образуват зависимости и не е ефективно що се отнася за ресурси и скорост на имплементация.
28/03/2022 г.
Всички програмисти трябва да участват в разделянето на епик в сторита/тикети. По този начин се прави крачка към самоорганизиращ се екип и към по-добро общо разбиране на задачите за бъдещите спринтове.
25/03/2022 г.
Обясниха ми, че ретрото е за Продуктовия собственик. Но аз не съм съгласен. Ретрото е и за екипа. Ако не са доставени спринт целите, да споделят какви са били пречките, какво може да подобрим. Ако са, дали може да развием още скоростта и ефективността на екипа.
Издание 5
Публикувано на 24.03.2022 г.23/03/2022 г.
Ако имплементацията на даден епик отнема повече време и ресурс от планирането, помогни на продуктовия собственик да разбере дали не може да бъде разделен на две.
22/03/2022 г.
Казус за публиката: Имаш програмист, който е в Русия и не може да си получи заплатата, а друг, който иска да се релокира, иначе напуска. Какво правиш?
18/03/2022 г.
Когато не разбираш нещо или ти се казва, че то няма как да стане, питай въпроса „Защо?“ няколко пъти. В повечето случаи, ще се достигне до извода, че има как да стане.
17/03/2022 г.
Въпрос за публиката: „Кой отговаря за Technical debt?“
16/03/2022 г.
Тикет, който блокиран от една година, по-добре да бъде затворен.
15/03/2022 г.
Трябва да имате „Team Agreement“. Да официализирате правилата на играта в екипите си, за да се уверите, че всички играят по едни и същи, както и да се осигури прозрачност.
14/03/2022 г.
Swimlane-ите в борда е най-ефективно да са по епици или по целите на спринта. Ако искаш да виждаш задачите на всеки програмист, направи „Quick filter” с тяхното име.
11/03/2022 г.
Обясни на програмистите, че тикетът е готов, когато е в колонката „Done“. В тестване или в ревю на кода все още е тяхна отговорност да търсят най-бързото и ефективно приключване на задачата, да не взимат нова преди това.
Издание 4
Публикувано на 10.03.2022 г.09/03/2022 г.
Как да предпазиш Екипите си от спешни таскове, които идват от Горе? Не можеш, ако организационната структура не бъде променена и наистина ПС не приоритизира беклога. Докато това се случи, оставяш „буфер“ х стори точки, на базата на скоростта на екипа.
07/03/2022 г.
Трябва ли СМ да оценява работата на всеки член на Екипа? Не.
04/03/2022 г.
Кой е шеф на СМ? В различните компании е различна роля. В случай, че тя се изпълнява от един човек, който същевременно е и началник на Продуктовите собственици, менторството не е пълноценно.
02/03/2022 г.
Фронт енд програмист няма какво да прави повече в спринта? Добавяш му нови задачи, нали? Не. Предлагаш помощта му на друг екип, който има нужда от него.
01/03/2022 г.
На Grooming сесията няма въпроси по заданията, но в спринта изникват много и процесът се забавя. Решението е подобряването на съдържанието на сторито преди спринта. Въпроси изникват в процеса на работа, разбира се, но броят им ще намалее.
28/02/2022 г.
Пътят към самоорганизиращ се екип е трънлив и дълъг. Поредните тръни са прехвърлянето на таскове от единия в другия спринт. Задача на СМ е да обучи екипа и да му създаде условията, така щото в края на спринт да има готов „инкремент“.
25/02/2022 г.
Не бяхме планирали война за този спринт... Имам колеги украинци, беларуси и руснаци. Те продължават да работят заедно, не се поддават на медийни и политически провокации. Някои от тях се евакуираха, а други – останаха в домовете се. В такива ситуации си припомняме кои са реално важните неща. Спринтът ще почака...
Издание 3
Публикувано на 24.02.2022 г.23/02/2022 г.
Трудно се смята и планира в този болнав период. Все някой излиза болничен и на “burndown chart-a” не му харесва. Затова, ако скоростта на Екипа е 80 стори точки, планирайте за 75. Буферът от 5 точки е именно за да покрие непланираните ситуации.
21/02/2022 г.
Хубаво ми стана, когато тех лийдът ми благодари, че съм поел 1в1 сесиите, за да не ги прави той. Аз му обясних, че така или иначе ми е задължение, но се радвам, че съм му спечелил време за другите му занимания.
18/02/2022 г.
„Продуктовият собственик пише заданието, а аз го изпълнявам.“ - каза ми един програмист. Следователно, менторът в теб трябва да му обясни, че в един идеален случай на себеорганизиращ се екип, ПС приготвя епика, а от там нататък на ход е програмистът. При неясноти, се прави „грууминг сесия“ или просто се доизяснява на „дейлито“.
17/02/2022 г.
Има ситуации, в които се намираш „между чука и наковалнята“ или по-точно, между екипа и мениджмънта, по дадена тема. Двете страни имат различно разбиране по нея. Трябва да се проследят и двете мнения, след това да се синхронизират (до колкото е възможно). В Waterfall организациите никой няма да оита никого, ще се спусне решението от Горе. Но в нашата практика има примери и за обратния подход.
16/02/2022 г.
Моят отговор на долния въпрос е, освен провеждането на разговор на четири очи, да го оставиш без да задача и да видиш колко време ще отнеме да го спомене. След това се използва този пример за надграждане.
15/02/2022 г.
Въпрос към публиката: как се мотивира програмист, който твърди, че всичко е шест, но представянето му и екипният му дух не са на ниво?
14/02/2022 г.
Ако даден таск „пътешества“ из три спринта и още е в „То Do“, защо е в спритна?
11/02/2022 г.
Как да разберете ценностната система на една компания що се отнася за нейните служители? Попитайте лидерите й следното: ако трябва да изберете сърцат човек, който не доставя желаните резултати или хиперпродуктивен такъв, който обаче е токсичен за екипа, кой е вашият избор?
Издание 2
Публикувано на 10.02.2022 г.09/02/2022 г.
Трудно е да спечелиш доверие в даден човек. Това е валидно и за взаимоотношенията на СМ с членовете на екипа. Гради се с времето и с мнооооого разговори.
08/02/2022 г.
Ако Продуктовият собственик или член на екипа пише сторита, „асайнва“ ги на даден програмист, а той ги прави, това не е Скръм, по-скоро Waterfall.
04/02/2022 г.
В оценката на дадено стори трябва да бъде предвиден и ресурс за тестване, не само за разработване.
03/02/2022 г.
Ако все трябва да се добавят таскове в спринта за даден епик, това е признак за отделянето му в Kanban борд, в различен спринт.
02/02/2022 г.
В даден екип има 5-6 епика (Епик: голяма задача, която се разбива на по-малки). Не е добра идея. Scrum подходът е екипът да се фокусира върху няколко епика и да ги приключи възможно най-бързо, следователно, да се премине към следващите. В противен случай се рискува имплементацията им да се проточи, да се създаде зависимост от отсъствие на даден програмист, тъй като само той работи по даден епик.
01/02/2022 г.
За ситуацията от първото издание на „Дневника“ с отдадения член на екипа на друг, за да им помогне: нещо за седмица се прави вече четвърта. „Лизингованият служител“ е отговорност на СМ на съответния екип, на който помага. Въпреки това, добре е да се следят настроенията „помагача“, в противен случай, напрежението, което се създава, ще се върне в титулярния екип.
31/01/2022 г.
Таск, оценен на 3 SP (Story points- оценката на екипа за комплексността за дадена задача), който се прави една седмица, не е оценен правилно. Или се разбива на два таска, или се вдигат точките.
28/01/2022 г.
Продуктов собственик ме попита докъде се разпростират неговите отговорности и тези на Скръм Мастъра. Това е чудесен повод да се предприемат стъпки за обогатяване на Agile културата в компанията. Даже е задължително.
Издание 1
Публикувано на 27.01.2022 г.21/01/2022 г.
Екип X моли за помощ от Екип Y за Frond-end developer за седмица, за да им помогне с дадено стори. Обаче, екип Z също го иска. Няма друг наличен ресурс, така да се каже, затова трябва да си го поделят...
21/01/2022 г.
Когато член на екипа напише в чата: „Питай Scum Master-a“ (Scum = боклук), се чудя дали е пропуснато „r“ или вид послание за работата ми.
20/01/2022 г.
Говорихме си с един колега на тема 1:1 и нашата роля в тях и както каза той „от проповедник до coach“.
19/01/2022 г.
Кажи на програмиста следващия път да не взима таска, ако няма да го работи. Да седи на On hold два дена няма смисъл.
19/01/2022 г.
По-добре една-две цели за спринта, изпълнени, отколкото пет или повече половинчато свършени.
19/01/2022 г.
Отдели повече време за подбор на подходящи въпроси за ретрото, отколкото да мислиш какъв цветен борд да направиш в Miro или някоя друга интерактивна дъска.
19/01/2022 г.
Scrum Master не означава „Адвокат на Agile“. „Адвокат“ е на екипа.
18/01/2022 г.
Един съвет: ако burndown chart-ът е толкова „изкривен“, че се чудиш дали го разчиташ правилно или наистина има добавяне на задачи по време на спринта, не се забивай само в анализ на данните, а поговори с екипа. Така причината ще стане ясна много по-бързо и ще имаш по-голям шанс да предотвратиш подобна ситуация в бъдеще!
17/01/2022 г.
Организацията ти вярва, че анкета на три месеца ще измерва прогреса на екипите в няколко насоки: (1) развитие на експертизата на всеки негов член; (2) взаимодействие и комуникация между колегите и (3) настроенията им спрямо организацията. Екипите казват, че това е безсмислено и няма добавена стойност. Организацията твърди обратното. Как отиграваш тази ситуация и този конфликт?
17/01/2022 г.
Работиш с международен екип от Литва, Украйна, Беларус и Русия. Освен добри познания по Agile, необходимо е да имаш и добра обща култура по история и Източноевропейска политика!