Бути менеджером команди та розробником у команді Scrum

Я керую командою з 6 чоловік, яка нещодавно переїхала до Scrum.

У нас є майстер Scrum (один із розробників у команді) та власник продукту.

Оскільки у мене досить багато вільного часу (тому що багато управлінських робіт, якими я займався, зараз займається майстер Scrum і власник продукту), і оскільки я хочу залишатися технічно актуальним, я займаюся деякими технічними розробками.

Я виступаю частиною команди розвитку, займаюся деякими історіями у кожному спринті та беру участь у всіх зустрічах як частина команди.

Як ви вважаєте, це гарна ідея? Чи може це суперечити «самоорганізації» колективу?

Ознайомтеся з розвиваючими думками Роя Ошерово щодо керівництва командою в Agile світі на 5whys.com

Він багато розповідає про три ключових етапи, якими проходить команда, коли вона розвивається від водоспаду до Scrum.

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

Етап навчання - коли команда встигає навчитися та використовує її - вимагає тренера, як керівника, із сплесками контролю, коли все займе занадто багато часу, щоб навчитися важкому шляху (наприклад, без контролю джерела)

Фаза самоорганізації - де команди можуть вирішувати власні проблеми - потрібно більше керівника типу фасилітатора, який не говорить людям, що робити, а просто забезпечує обмеження та кінцеві цілі. Команда потрапить туди самостійно.

Коли я натрапив на ідеї Роя, на OpenVolcano '10 , я був повністю втрачений, чому моя команда перестала вдосконалюватися. Тоді я зрозумів, що команда перейшла від виживання до навчання, і я зовсім не змінив свій стиль управління. Я так і зробив, і це дуже допомогло.

Тому я пропоную розібратися, в якій із цих трьох фаз ви перебуваєте, і керуєте відповідно.

Також прийміть рішення вже зараз і будьте лідером або розробником. Не потрапляйте в пастку думки, що у вас є вільний час, поки ви не перейдете у фазу самоорганізації. І, якщо ви туди потрапите, зрозумійте, що ви хороший лідер команди (це важко ), і перейдіть до іншої команди, а не реінтегруючись.

Коментарі pdr є дійсними, і я погоджуюся з ними. Але я не вважаю їх універсальними для всіх випадків.

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

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

Варто зазначити, що ви не можете усунути всі наслідки невідповідності. Будуть часи, коли вам потрібно покусати язик і стримуватися від бурхливої ​​дискусії. Будуть інші, коли вам потрібно витягнути козир і зазначити, що остання відповідальність за команду лежить на вас, тому ви робите диктат.

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

Мені чесно подобається, коли мій безпосередній керівник вважає себе технічно актуальним. Це полегшує їхнє розуміння моїх труднощів, і я думаю, що ми закінчимось командою з кращими показниками.

Раніше я переживав подібний досвід, очолюючи команду з 6 розробників в команді Scrum. Окрім того, що згадували pdr та GlenH7, те, що допомогло:

1. Найкращий тестер команди QA справді був хорошим у тому, щоб ми відповідали за якість нашої роботи, включаючи роботу, яку я зробив. Коли я писав баггі-код, вона зателефонувала мені на нього так, що іншому розробнику було б важко зробити.
2. Я зазвичай робив спринтські демонстрації, особливо коли у нас були погані спринти. Оскільки я демонстрував генерального директора, мені було ніяково, коли речі не працювали. Крім того, щоб зрозуміти, що я розумів особливості, які розвивали інші, це також означало, що мої речі повинні бути такими ж твердими, як і всі.
3. Я дозволяю іншим приймати рішення. Мій досвід відрізняється від досвіду GlenH7, я завжди вважав помилкою витягнути козир. Натомість я обговорив різні наслідки рішень і дав зрозуміти, хто коли-небудь розробник працював над тим, які наслідки були для тієї речі, яку я вважав "неправильним" способом щось робити. Причин для цього багато, але найбільша з них полягає в тому, що, коли команда веде, ти не встигаєш прийняти всі рішення.
4. Використання продукту типу Sonar може зробити такі об'єкти, як якість коду, більш об'єктивними.