Поширюю інформацію про платформу при кожній нагоді. Розуміння, як навіть одна сесія може змінити шлях людини — безцінно, і мотивує продовжувати менторити і надалі. Дякую за небайдужість, ідею та реалізацію.

1) Ці розробники примають участь у плануванні та оцінці задач? Якщо ні — спробуйте долучати, хай самі пробують зрозуміти, який спектр робіт всередині, давати оцінки виходячи з того, за скільки вони б зробили.

2) (Говорить по менеджерські) в Менеджмент 3.0 є глава про рівні делегування, корисно разочок сісти та заповнити табличку з усіма своїми активностями, і вирішити, що з ними далі робити) Буває багато інсайтів.

3) Вже радили, підписуюся — не робіть роботу за них, це найгірше. Інвестиції часу в співрбітників або окуповуються і вони стають кращими як фахівці, а ви прокачуєтеся в менторингу, або ви їх вчите — і вони валять з компанії. Як та крилата фаза «Що краще — ми їх навчимо і вони звалять, чи ми їх не навчимо і вони залишаться?»

4) Парне програмування — супер, код ревʼю не тільки вами за ними, але і навпаки — супер.

5) Якщо є можливість — пошукати ментора ще десь в компанії, якщо самому не хочеться. Але змиритися, що вони приходити з чужим «уставом» в ваш монастир

6) Прощатися, якщо реально не вигрібають навіть після менторинга і всіх спроб, що були здійснені

7) Дати відверту відповідь на питання, чи воно вам треба. Якщо так — качатися в софт скілс, без того ніяк і там море всього, починаючи від фасилітації зустрічей до побудови команд, стосунків, вирішення конфліктів і т.і. Ще й емпатію прокачаєте)

+

Герої серед нас! Дякуємо!

Убеждена, что ретроспектива — самая важная встреча в скрам. И какого бы уровня зрелости и слаженности не достигла команда, ценность ее не снижается. Однако формат можно и нужно менять в зависимости от того, где сейчас команда.

Ретроспективы не умрут, если:
1) в команде есть доверие и открытость, поощряется любая обратная связь в корректной форме, команда умеет благодарить друг друга, а не только критиковать
2) формат проведения ретро меняется, и фасилитатор не настаивает на своем плане проведения встречи, а подстраивается под диалог команды, имея в запасе несколько вариантов активностей на разные ситуации
3) на ретро команды договариваются о следующих шагах не ради менеджмента, а ради создания лучшей версии команды и процессов, и эти действия остаются не на доске/стикерах/МоМ, а включаются в беклог и осуществляются

Высший пилотаж скрам мастера — научить команду проводить ретро самостоятельно, например во время его отпуска :) И это возможно, когда команда чувствует ценность этой встречи и понимает ее цели.

Напоследок маленькая, но полезная практика.
Пускай ссылка на доску для ретро будет постоянно доступна, и следующие ретро проводятся рядом с предыдущими — так легче отслеживать динамику договоренностей.
Создайте отдельную зону — «парковку», на которую в течении спринта команда может добавлять идеи для будущего ретро, темы для обсуждения, свои наблюдения. Это помогает «вынуть из головы» ценные мысли, когда до ретро ещё долго, и легко вернуться к ним во время ретро.

Всем осознанных и полезных ретроспектив :)

За двухнедельный спринт, пока разработчики трудились над реализацией продукта, я успевала выяснить все желания клиента по новому функционалу. А также убедить его в рациональности или иррациональности той или иной идеи.

— здесь явно про валидацию гипотез заказчика. Скрам мастер, разъясняющий правила игры заказчику — да, несомненно. Скрам мастер, который решает, взлетит ли фича и стоит ли ее делать — неее, тут явно дисфункция и совмещение ролей, которые лучше не совмещать.

Scrum master говорит «нет» заказчику? What?!