Что такое team-development

Определение факторов, важных в создании и развитии группы. Объяснение Stages of Team Development (Этапы развития группы) Bruce Tuckman. ('65)

Что такое Stages of Team Development (Этапы развития группы)? Описание

Stages of Team Development (Этапы развития группы) Tuckman можно использовать для определения факторов, важных в создании и развитии группы.

Модель Stages of Team Development (Этапы развития группы) Tuckman пытается объяснить, как группа развивается с течением времени.

5 этапов развития: Cтадия формирования (Forming), Cтадия шторма (Storming), Cтадия урегулирования (Norming), Cтадия результативной деятельности (Performing) и Стадия завершения (Adjourning). Стадия завершения была добавлена позже в 1977г.

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

Происхождение концепции Этапы развития группы. История

Bruce Wayne Tuckman (1938 -) опубликовал в 1965г. короткую статью под названием «Developmental Sequence in Small Groups». В 1977, он добавил пятый этап: Стадию завершения (Stages of Small Group Development Revisited). Модель группы стала влиятельной в теории развития группы, отчасти благодаря своей формулировке.

Применение концепции Этапы развития группы Tuckman. Формы применения

Создайте и развивайте группы. Проанализируйте поведение групп.

Этапы развития группы. Процесс

Cтадия формирования. Начальная фаза проектной группы.

Проектная группа изначально проходит ориентацию, осуществляемую, главным образом, посредством испытания. Такое испытание необходимо для определения границ межличностного поведения и поведения в отношении задач. Параллельно с испытанием в межличностной сфере происходит установка отношений зависимости с лидерами, другими членами группы или стандартами, которые существовали ранее. Члены группы действуют достаточно независимо. Они могут быть мотивированы, но обычно относительно плохо информированы относительно вопросов и задач группы. Некоторые члены группы могут проявлять признаки неопределенности и беспокойства. Менеджер проекта должен интегрировать группу, убедившись, что члены группы доверяют друг другу и способны наладить рабочие отношения. Директивный или «указывающий» стиль лидерства. Информирование сотрудников о концепции «Forming, Storming, Norming, Performing» может быть полезно.

Cтадия шторма. Конфликт различных идей.

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

Cтадия урегулирования. Устанавливаются правила, ценности, поведение, методы, инструменты.

Эффективность Проектной группы увеличивается и группа начинает развивать идентичность. Члены группы корректируют свое поведение, по мере того как налаживают взаимодействие. Сознательное усилие разрешить проблемы и достигнуть согласованности в группе. Уровни мотивирования повышаются. Менеджер проекта допускает большую автономность в группе. Стиль лидерства с участием персонала.

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

Проектная группа может теперь действовать как подразделение. Она выполняет работу беспрепятственно и эффективно без неуместного конфликта или потребности во внешнем контроле. Члены группы имеют ясное представление о том, что от них требуется на уровне задачи. Они теперь обладают компетенцией, автонономией и способностью принимать решения без контроля сверху. Присутствует уверенность в своих способностях. Предлагается взаимная помощь. Менеджер проекта позволяет группе принимать большинство необходимых решений. Делегирующий стиль лидерства.

Стадия завершения. Задачи выполняются, и группа распускается.

Проектная группа. Некоторые авторы описывают этап 5 как «расформирование и оплакивание», указывая на чувство потери, ощущаемое членами группы. Уровни мотивирования Членов группы могут снизиться, по мере того как возникает неопределенность в отношении будущего. Менеджер проекта: Подходящий момент для того, чтобы начать реализацию новых проектов для того, чтобы возобновить стадию формирования в развитии группы. Разделяющий стиль лидерства.

Преимущества модели Этапы развития группы. Преимущества

Обеспечивает уровень руководства для развития группы.

Ограничения концепции Этапы развития группы. Недостатки

Стоит отметить, что модель была разработана для описания этапов в Небольших группах. В реальности, процессы группы могут быть не настолько линейными, как описывает их Tuckman, а скорее циклическими. Параметры для каждого этапа не фиксированы, и так как модель касается человеческого поведения, иногда неясно, когда группа осуществила переход от одного этапа к другому. Может присутствовать совмещение между этапами. Модель не учитывает индивидуальные роли членов группы. Сравните: Belbin Team Roles (Роли группы Belbin) Нет указания относительно временных рамок по переходу от одного этапа к другому. Это субъективная модель.

• Словарь по управлению персоналом

Оцените публикацию

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике. Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса — доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

• определение элементов бэклога продукта;
• правильное расположение элементов для оптимизации достижения цели;
• обеспечение понятности и прозрачности Product Backlog;
• обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
• общая оптимизация для достижения наибольшей ценности работы Development Team;
• ответственность за понимание бэклога командой разработки.

Scrum Team (скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.

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

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.

Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся.

Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер.

Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов.

Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи.

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

Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

1. Основные поля в карточке: id, название, важность, оценка, релиз, описание, автор, исполнитель;
2. Дополнительные поля в карточке. Например, поле «Тематика» – рейтинг товара в интернет-магазине сейчас не нужен, а в рейтинг входят пара задач.

   Тогда можно изменить «важность» всех задач с этой тематикой;

3. Задачи лучше разбивать по одинаковым типам.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени. 123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

1. Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
2. Формулировка User Story: Будучи пользователем я хочу сделать , чтобы получить .

   Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение; Формулировка без ЧТОБЫ (так лучше). Как , я , .

   Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ.

3. Разделение «актеров» на группы: целевая, важная, менее важная и т.д. Присвоение уникальных названий актерам в этих группах, даже если есть одинаковые роли «Пользователи системы»;
4. Написание истории с точки зрения этих актеров с указанием уникальных названий;
5. В результате можно увидеть, какие истории необходимы для актеров целевой группы, важной группы итд. Следовательно можно выстроить приоритет;
6. Действие. Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
7. Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
8. Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
9. User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.

Уточнение и оценка Product Backlog Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

1. Первая часть митинга могут участвовать все. Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;

   Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения.

2. Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog.
   Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;

Scrum Poker (Planning Poker). Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок. Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

1. Scrum Master ведет собрание;
2. Product Owner представляет краткие обзоры каждой задачи;
3. Происходит обсуждение, задаются вопросы;
4. Участники Developer Team выбирают по одной карте, потом переворачивают;
5. Если в результате ания есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
6. Затем голосуют вновь и присваивают задаче Story Points.

Daily Scrum Meeting Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

1. Проводится в одно и то же время;
2. Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
3. Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?

Sprint Review Meeting Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала. Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта. Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды? Время на ретроспективу для 2-х недельного спринта не более 2-х часов. Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Feature Teams

Представленная на Рисунке 1 Feature Team — это достаточно долго существующая вместе кросс-функциональная кросс-компонентная команда, которая самостоятельно, в одиночку, реализует множество пользовательских фич.

Рисунок 1 Feature Team

Пояснения к Рисунку 1

Ниже перечислены характеристики Feature Team команды:

• достаточно долго существующая вместе команда, которая не расформировывается, с целью достижения высокого перфоманса (высокой производительности); спустя какое-то время она берет на себя новые функции, принимая вызовы и наращивая собственные компетенции
• кросс-функциональная кросс-компонентная команда
• в идеале команда территориально размещается в одном месте — офисе или кабинете
• работа, которую выполняет команда для реализации фич, сквозная для всех компонентов и затрагивает разные сферы компетенций (аналитика, программирование, тестирование и далее)
• команда, состоящая из специалистов широкого спектра — имеющих много компетенций и знающих продукт не только в какой-то одной достаточно узкой области, то есть не узко специализированные
• согласно scrum-у состав такой команды не превышает 7 человек, идеальный состав по численности обозначен как 7 ± 2 человека (другое название two pizza team).

Применение современных инженерных практик и особенно CI (continuous integration) — это достаточно важный, существенный и неотъемлемый момент в адаптации, “сбивании” Feature Team.

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

https://www.youtube.com/watch?v=DZbmIg0c2s4

Существует всеобщее заблуждение. Оно связано с представлением о том, что каждый член такой команды должен обладать знаниями обо всей системе. В реальности это не так потому что:

• Команда как единое целое, а не каждый ее участник в отдельности, требует скилов по имплементации разработанной фичи целиком. Сюда включаются компонентные знания и такие навыки как тестирование, проектирование взаимодействия и собственно программирование. Однако внутри команды люди все же специализируются исходя из своих компетенций и возможно сразу в нескольких областях.
• Фичи распределяются внутри команды не рандомно (случайным образом). Текущее состояние знаний и навыков команды является основополагающим при принятии решений по тому, какая команда с какими фичами будет работать.

В том случае, когда специализации оказывается недостаточно в пределах команды запускается процесс самообучения и шаринга знаний.

Важный момент

Feature Team приносит пользу по скорости т.е. показывает достаточно высокую скорость по разработке фичей ровно столько времени, сколько требования мапятся на скилы команды.

Feature Team показывает высокий перфоманс в случае, если требования по работе с фичей соответствуют знаниям и навыкам команды.

Однако когда эти требования перестают соответствовать знаниям и навыкам команды, обучение усиливается и ограничения по специализации таким образом разрушаются.

Компонентная команда vs. Feature Team

В таблице ниже рассмотрим основные отличия и особенности каждого из форматов — компонентной команды и Feature Team.

Рисунок 2. Взаимодействие с владельцем продукта и внутри командное взаимодействие в компонентных командах и в Feature teams

Пояснения к Рисунку 2

В таблице выше мы рассмотрели основные отличия и особенности компонентной команды и Feature Team.

В таблице ниже рассмотрим отличия между традиционными проектными командами (фича группами) и Feature Team командами.

Еще больше минусов по работе в формате компонентной команды вы можете найти в разделе Scaling Lean & Agile Development. Ниже на Рисунке 3 мы приводим лишь некоторые из них.

Рисунок 3. Недостатки работы в формате компонентной команды

Пояснения к Рисунку 3

Хочется отметить еще один момент в компонентном подходе. Компонентная команда поддерживает подход последовательной разработки при водопадной модели, с меняющимися приоритетами и объемом работ, ориентацией на WIP (work in process), происходит множество переключений контекстов, происходит рост многозадачности и некоторое распыление, “размазанность”, расфокусировка.

Компонентная команда или Feature Team, что же выбрать?

Feature team в чистом виде — это идеальное и перспективное решение с точки зрения стоимости и гибкости.

Однако стоимость и гибкость не является единственным определяющим критерием при организации работ на проекте. Поэтому многие организации скорее используют гибридную модель — особенно во время перехода с компонентной модели к Feature Team.

Обратите внимание на то, что гибридные модели имеют недостатки обеих сторон и могут оказаться весьма болезненными.

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

Однако все эти активности спокойно могут делаться и в Feature team формате — без создания временных компонентных команд.
Как? Путем добавления инфраструктуры, переиспользуемых компонентов или проведения работ по очистке бэклога продукта — и передача всего этого существующей Feature team, как если бы это было клиент ориентированной фичей.

В этом случае Feature team — явление временное, она существует так долго, как это потребуется Product Owner-у. То есть Feature team какое-то время работает так, а в дальнейшем возвращается к созданию клиент-ориентированных фич.

Переход на Feature Team формат

Различные организации требуют различных транзитных стратегий по переходу с компонентной модели на Feature Team формат.

Безопасной, но достаточно медленной переходной является стратегия, которая заключается в организации одной Feature Team в рамках существующей и работающей по компонентной модели организации.

После того, как пилотная Feature Team показывает хороший перфоманс, можно запускать вторую Feature Team. Этот процесс должен проходить постепенно и двигаться со скоростью, подходящей для каждой конкретной организации.

Этот процесс отображен на Рисунке 4.

Рекомендовано к изучению

Материал является переводом.
less/structure/feature-teams.html

Feature Team, scrum, команда, командная работа, компонентная команда, техническая статья

5 stages of team development every leader should know

Let’s look at each stage in details and see what involvement is needed from a leader.

Forming

In this stage, most team members are usually positive and polite. Some are anxious because they are in the uncertain environment surrounded by new people. And sometimes without a clear understanding of what the project is about.

This stage lasts for some time, as people start working together, getting to know each other and their responsibilities.

Role of the leader: as the leader, you play a dominant role at this stage, because team members’ roles and responsibilities aren’t clear. I recommend having personal talks with all the team members to find out their personal goals and interests in the project which is essential information for a leader on further stages.

Storming

After some time, a team moves to a storming phase. Team members start to push against the boundaries established at the forming stage. At this stage where many teams fail.

Storming is an inalienable part of any team experience. It usually starts if there is a conflict between team members’ natural working styles.

Everyone has their own working approach, and the success of the team depends on a proper communication and willingness to compromise. However, if different working styles cause unforeseen problems, they may become frustrated.

The leader must feel such negative trends within the team and efficiently manage conflicts.

Storming can also happen in other situations. At this stage, they know each other better, as well as their responsibilities.

They may feel deceptive overconfidence and therefore challenge your authority or jockey for position.

Or, if you haven’t defined clearly how the team will work, people may feel overwhelmed by their workload, or they could be uncomfortable with the approach you’re using.

Some may question the team’s goal and resist taking on tasks because of that.

Team members who keep working hard may be even more stressed without support from other and established processes.

Role of the leader: reduce tension within your team, manage conflicts, stay committed to the team goal and lead by example. If things go worse and conflicts are often, organize a feedback session or hot chair exercise with an external moderator.

This stage requires the maximum of the leader’s attention and involvement.

Norming

Gradually, the team moves into the norming stage. Your team members understand your role in the project and start respecting your authority as a leader. They learn how to deal with their differences and appreciate colleagues’ strengths.

Now your team members got to know each other better, they may start socializing together, and even asking for help or providing constructive feedback. Team members develop a stronger commitment to the team purpose, and the first results appear.

The leader should be warned that a prolonged overlap between storming and norming is a usual thing, because, new difficult tasks may lapse the team back into behavior from the storming stage.

Role of the leader: motivate team members with first results, show them that you are on a right track, encourage them to move to the performing stage. It is huge for nutritioning motivation to show the first results. People understand that the painful storming stage was not in vain and start to value each other and the project even more.

Performing

During the norming stage, the team worked well, and you reach the performing stage when hard work is a king, and you move your way to the achievement of the team’s goal very fast. The processes that you have set up support this well.

This is the stage of the maximum efficiency and productivity, everyone enjoys working together and see the progress towards the goals.

Role of the leader: as the leader, you can delegate much of your work and can concentrate on developing team members. Here is your time to improve your talent development, mentoring and coaching skills, because your team manages all working process without your direct involvement.

How cool is this — to know what each one of a team is capable of and fully rely on a team. And for the team leader, it is so amazing to see the team running clockwork.

Adjourning

Many teams will reach this stage eventually. For example, some teams exist only for one project, and even permanent teams may be re-allocated through organizational restructuring.

Team members who are afraid of changes, or who have become close friends with colleagues, may find this stage difficult because their future now looks uncertain.

Role of the leader: facilitate the values reinvention and experience reflection. Also, the work of the team leader is to suggest the ways to stay in touch with other team members even after the project.

An intense experience you all got through working together is a great bonding tool, so it is no surprise if you become good friends afterward.

I still keep in touch with my previous teammates, we do care about each other and chat a lot, despite it’s been more than 3 years since we finished the project.

«,»author»:»Marina Paych»,»date_published»:»2021-04-06T15:14:43.830Z»,»lead_image_url»:»https://miro.medium.com/max/1200/1*k-4PgZnmgYP0MhWqmrZByA.png»,»dek»:null,»next_page_url»:null,»url»:»https://medium.com/swlh/team-development-stages-51df5606c0a2″,»domain»:»medium.com»,»excerpt»:»Each team goes throuth 5 stages of team developig and the role of a leader is to facilitate each stage to differently to maximize the…»,»word_count»:810,»direction»:»ltr»,»total_pages»:1,»rendered_pages»:1}

5 Stages of Team Development

The first stage of team development is forming, which is a lot orientation day at college or a new job. You could even compare it to going out on a first date.

The team has just been introduced and everyone is overly polite and pleasant. At the start, most are excited to start something new and to get to know the other team members.

During this stage, you may discuss:

• Member’s skills, background and interests
• Project goals
• Timeline
• Ground rules
• Individual roles

As the group starts to familiarize themselves, roles and responsibilities will begin to form. It is important for team members to develop relationships and understand what part each person plays.

But, because this stage focuses more on the people than on the work, your team probably won’t be very productive yet.

Have you ever reached the point in a relationship where you become aware of a person’s characteristics and they frustrate or annoy you?

Perhaps they squeeze the toothpaste from the top of the tube instead of the bottom? Eat with their mouth open? Or they listen to the same Drake song 15 times in a row?

Well, congrats, you’ve entered the storming stage.

Being in a team is being in a relationship. At first, you may think someone is perfect and flawless. But, then you realize that they aren’t. Once you’re aware of their flaws, you either learn to embrace them or the relationship will end quickly.

In the storming stage, the reality and weight of completing the task at hand have now hit everyone. The initial feelings of excitement and the need to be polite have ly worn off.

Personalities may clash. Members might disagree over how to complete a task or voice their concerns if they feel that someone isn’t pulling their weight. They may even question the authority or guidance of group leaders.

But, it is important to remember that most teams experience conflict. If you are the leader, remind members that disagreements are normal.

Some teams skip over the storming stage or try to avoid conflict at whatever cost. Avoidance usually makes the problem grow until it blows up. So, recognize conflicts and resolve them early on.

During the norming stage, people start to notice and appreciate their team members’ strengths. Groups start to settle into a groove. Everyone is contributing and working as a cohesive unit.

Of course, you may still think that your tech guy’s choice in music is obnoxious. But, you also admire his knowledge of web design and coding skills, and value his opinions on anything tech-related.

Storming sometimes overlaps with norming. As new tasks arise, groups may still experience a few conflicts. If you’ve already dealt with disagreement before, it will probably be easier to address this time.

If you’ve reached the fourth stage, pat yourself on the back. You’re on your way to success.

In the performing stage, members are confident, motivated and familiar enough with the project and their team that they can operate without supervision. Everyone is on the same page and driving full-speed ahead towards the final goal.

The fourth stage is the one that all groups strive to reach. Yet, some do not make it. They usually fail to overcome conflict and can’t work together.

In 1977, Tuckman added a fifth stage called adjourning. (Sadly, not a perfect rhyme.) Once a project ends, the team disbands. This phase is sometimes known as mourning because members have grown close and feel a loss now that the experience is over.

Start Tracking Your Team

Why are the 5 stages of group development important?

Groups are so in-sync during the performing stage that it seems to happen naturally. But, don’t be fooled. The most effective and high-functioning teams are cultivated.

Throwing a group of talented people together doesn’t mean that they will form a great team. Hoping that your company or project will be a success won’t make it happen.

Understanding Tuckman’s development process can increase your chances of reaching project goal(s).

How can you help your team advance in their development?

Business owners, managers, and entrepreneurs are often viewed as team leaders. If something fails, you may blame yourself. If it succeeds, you’ll receive the praise.

Whether you are leading your entire company or a smaller project group, you have a huge influence on team development and performance. It’s almost being Captain America to The Avengers or Steve Jobs to Apple. Of course, those are some big shoes to fill.

You don’t have to gain superpowers from a serum or create one of the most iconic brands of your generation to be a great leader.

Guide your team through each stage of the process with the following tips:

1. Set a clear purpose and mission and revisit it throughout the process

Why does your team or company exist? What values matter to you? What problem will you solve? Why do you need to solve it?

All these questions should be answered with a clear purpose and mission statement. It is the framework that will help you make decisions. It gives you direction. Without it, you’ll go nowhere.

People get so lost in a specific task that they forget why they are doing it in the first place. It is easy to lose sight of the “big picture”. Teams need a clear purpose and mission and should be reminded of them often.

2. Set ground rules and make sure they are followed

Rules may not sound fun, but they clear up confusion. Without them, no one will know what is considered acceptable behavior. Everyone will have their own “style” of doing things. Groups without rules are disjointed, prone to conflict and inefficient.

One of the first tasks that teams should do is establish ground rules. These can cover how to interact in the group to how to complete tasks efficiently. Some examples are:

• Don’t interrupt another member when they are speaking.
• Turn off your phone during working meetings.
• Track your time transparently with Toggl.
• Create a weekly work plan with tasks and share it with the team.

Remember that rules are created to help your team stay focused on what matters most─performance.

3. Let other members act as leaders or facilitators

Every team should have a facilitator─a person who leads and guides meetings and discussions. Someone who drives the group towards a common goal.

As a company founder or manager, you may be the designated team leader. But, that doesn’t mean you should always be the one leading.

Leading a team is tiring. Try to do it all on your own and you’ll burn out fast.

Sometimes, there may even be another member of the group more qualified to lead a discussion than you. If you are discussing the security of a mobile app you are building, the best facilitator could be the cyber security expert on your team?

High-functioning teams work so well together that facilitator roles can rotate without impacting their performance.

4. Don’t try to avoid conflict. It is normal and can be healthy

If everyone in your group thinks and acts the same, then why do you have a group? The benefit of working in a team is that you have access to diverse experiences, skills, and opinions that aren’t possible alone.

When members disagree about something, listen to each side. But, don’t take one. Search for common ground. For example, each person wants to reach the end goal.

When conflicts are resolved, it can improve existing processes and bond members together.

5. Remind group members to listen

Each person in your group holds some value, otherwise they wouldn’t be there, right? Remind your team to listen to each person’s insight.

Early on, create an environment that is open and non-judgmental. Hold brainstorming sessions. Write down every idea that is offered, no matter how ridiculous it sounds. Some of the greatest entrepreneurs and inventors have had failed companies and ill-conceived ideas.

For every brilliant idea, there are 100 terrible ones. Encouraging your team to share their ideas and opinions is the key to finding the “big ideas”.

6. End each meeting with insightful and constructive feedback that improves the group process

When you lead a group, part of your responsibility is to observe. Study how the team functions as a unit and individually.

What are they doing well? What do they need to improve? Give individual feedback in one-on-one meetings. But, you can point out areas of improvement or strengths to the group as a whole, without pointing fingers.

Don’t scold teams for their mistakes and failures, without showing them what went wrong. Don’t point out problems withfering solutions and advice.

It is important to give criticism in a way that empowers them to do better.

Nobody s a Negative Nancy or Debbie Downer either. Tell teams what they are doing right as well as what they need to improve.

As a leader, don’t think that you are flawless though. Give and ask for feedback from your team. That could mean sending out a weekly or monthly anonymous survey.

2. Close your speech in a memorable way: compliment your audience, deliver a punchline or share a shocking information or quote that suggests urgency.

7. To progress, everyone must contribute and participate

The point of having a team is to work together. Each person plays a part and has something to contribute. When one person fails to complete a task, the rest of the group suffers.

It is important to instill this sense of responsibility in a group. But, you may still need to remind and motivate members to be productive.

This is another area where time-tracking can help. With Toggl, team members can track the work that they do. This is especially useful if you have some people that are working remotely.

Even if your group has two or three leaders, you can’t always monitor your team. You can’t look over their shoulders and make sure that everyone is doing their work. Ideally, your team is made up of reliable people that know and fulfill their responsibilities.

There are other advantages to tracking your time with an app though. When you know how long a process takes, you can identify areas that could be made more efficient. Then, develop more productive habits. It can also help you predict how much additional time your group might need to complete the current project.

If powerful superhero and entrepreneur teams have taught us anything, it is that working with others can increase your strength and success. Some projects you just can’t tackle alone.

Building a team isn’t easy. It is a process. Knowing each stage of development can help you create all-star teams that deliver amazing results.

Try Toggl for Free

💡 Видео