Підвищіть свою спритність у 2026 році - остаточний посібник

Як ви знаєте, економічна ситуація за останні місяці кардинально змінилася.
У 2022 році відсоткові ставки все ще були близькими до 0 %, і ці “дешеві” гроші забезпечили дуже високий рівень приватного споживання. Це спонукало компанії надавати пріоритет зростанню та впроваджувати інновації.
Однак із різким зростанням відсоткових ставок і, як наслідок, падінням споживання, ці пріоритети змінилися. Замість зростання, основна увага приділяється прибутковості, а замість інновацій ключову роль відіграє оптимізація витрат. А оскільки розробка програмного забезпечення є дорогим бізнесом, ми спостерігаємо не лише хвилі скорочень у великих технологічних компаніях, але й зростаючу популярність вимірювання продуктивності команд розробників програмного забезпечення. І саме цей новий фокус означає, що тренери Agile та скрам-майстри зараз більш ніж будь-коли повинні брати на себе відповідальність за свої команди та надання нових функцій.

Саме через це я зібрав 5 порад, які допоможуть вам відповідати вимогам на посаді менеджера “Agile Delivery”.

Тільки якщо ви розумієте, які поточні пріоритети у вашій компанії, ви можете вживати цілеспрямованих заходів. Поставте собі ці три запитання, щоб отримати більше ясності в цьому питанні:

• Що зараз дуже важливо для керівництва?
• Як цей фокус змінився за останні місяці?
• Як ви узгоджуєте свої пріоритети з керівництвом?

Тепер, коли ви задалися питанням, чи знаєте ви пріоритети компанії, вам потрібно перевірити, чи ваші команди також чітко розуміють пріоритети компанії. Як коуч чи лідер, ви також повинні перевірити, чи відповідають ваші команди пріоритетам компанії. Для цього ви можете поставити собі три запитання:

• Як зараз команди дізнаються про пріоритети в компанії?
• Як команди домовляються про те, в чому полягає їхній основний внесок у досягнення загальної мети?
• Які зміни можуть допомогти гармонізувати очікування керівництва та команд?

Незважаючи на те, що однією з основних цілей гнучкої роботи є створення самоорганізованих команд, багато скрам-майстрів, коучів Agile та тімлідів все ще страждають від таких явищ, як “мікроменеджмент” або надмірна підтримка команди. Це, в свою чергу, призводить до того, що нібито “самоорганізовані” команди не можуть діяти повністю самостійно. Тут ви також можете поміркувати над тим, чи дійсно ваші команди є самоорганізованими:

• Чи є у вашій команді спільне розуміння того, що означає “добре виконувати свою роботу”?
• Чи здатна ваша команда точно оцінити, що вона може зробити за певний час і з певними ресурсами?
• Чи обговорюється в команді значущість завдань, чи вони просто виконуються?

Якщо щось працює неоптимально, часто вважається, що команда та її члени потребують вдосконалення. У більшості випадків, насправді це означає, що системи, в яких працюють члени команди, потребують вдосконалення. Реальність часто виглядає так:

Як можна вдосконалити системи?

• Чи отримує команда всю інформацію, необхідну для досягнення своїх цілей, вчасно?
• Чи швидко зворотній зв’язок від користувачів досягає всіх відповідних підрозділів компанії?
• Чи достатньо свободи у вашій команді, щоб самостійно організовувати роботу?

Однією з причин, чому багато “Agile тренерів” тепер мають титул “Agile Delivery Manager”, є те, що вони чітко символізують, що відповідальність за ефективність команди береться на себе. Ще у 2020 році в Scrum Guide було сказано наступне: “Скрам-майстер відповідає за ефективність роботи команди”.
Наразі це не лише важливо, але й очікується, що через економію коштів, яку роблять компанії, вони також візьмуть на себе відповідальність.

Оскільки економічна ситуація стає жорсткішою, вимірювана ефективність є більш важливою, ніж будь-коли. Щоб максимізувати її у 2024 році, візьміть до уваги ці 5 пунктів:

#1 Відображати пріоритети організації

#2 Гармонізувати очікування

#3 Розвивати справді самоорганізовані команди

#4 Удосконалення системи

#5 Візьміть на себе відповідальність

Щоб забезпечити це, важливо регулярно розмірковувати над питаннями, які я дав вам у цій статті. За допомогою нашого інструменту Agile “Echometer” під час кожної ретроспективи ставиться кілька запитань у формі Health Check, щоб ви завжди могли тримати їх в актуальному стані.

Якщо ви хочете протестувати інструмент безкоштовно, ви можете зробити це тут:

Як це зробити

⚙️ Agile Delivery Ретроспектива: Як проходить ретроспектива

1. Випадковий Icebreaker (2-5 хвилин)

   Echometer надає вам генератор випадкових питань для реєстрації.

2. Огляд відкритих заходів (2-5 хвилин)

   Перш ніж почати з новими темами, слід поговорити про контроль ефективності того, що сталося з заходами з минулих ретроспектив. Echometer автоматично перераховує всі відкриті пункти дій з минулих ретроспектив.

3. Обговорення ретро-тем

   Використовуйте наступні відкриті питання, щоб зібрати ваші найважливіші висновки. Спочатку кожен окремо. Echometer дозволяє відкривати кожен стовпець ретро-дошки окремо, щоб потім представити та згрупувати відгуки.

   • Коли наш спосіб роботи призводив до неоптимального робочого процесу? (наприклад, нечіткі, невідповідні або недотримані інструкції)
   • Коли наш спосіб роботи працював добре?
   • Які нещодавні приклади інкременту, який не спрацював/не був доставлений в кінці спринту?

4. Універсальне питання (рекомендовано)

   Щоб інші теми також мали місце:

   • Про що ще ви хочете поговорити на ретроспективі?

5. Пріоритезація / Голосування (5 хвилин)

   На ретро-дошці в Echometer ви можете легко розставити пріоритети для відгуків за допомогою голосування. Голосування, звичайно, є анонімним.

6. Визначення заходів (10-20 хвилин)

   За допомогою символу "плюс" на відгуку можна створити пов'язаний захід. Ще не впевнені, який захід буде правильним? Тоді відкрийте дошку для обговорення з цієї теми за допомогою символу "плюс", щоб провести мозковий штурм щодо основних причин і можливих заходів.

7. Виїзд / Закриття (5 хвилин)

   Echometer дозволяє збирати анонімні відгуки від команди про те, наскільки корисною була ретроспектива. Це створює оцінку ROTI ("Retrun On Time Invested"), яку ви можете відстежувати з часом.

⚙️ Agile Delivery Ретроспектива

Коли наш спосіб роботи призводив до неоптимального робочого процесу? (наприклад, нечіткі, невідповідні або недотримані інструкції)

Коли наш спосіб роботи працював добре?

Які нещодавні приклади інкременту, який не спрацював/не був доставлений в кінці спринту?

Відкрийте це ретро зараз