Large-Scale Scrum (LeSS)

LeSS или "Крупномасштабный Скрам" - это набор принципов, правил и каркасов для повышения гибкости организаций посредством упрощения их орг структуры.

 

Это Скрам, примененный ко всей организации.

 

Ниже представлен наименьший каркас LeSS, который так и называется "LeSS":

Как вы видите из иллюстрации, множество команд (магические числа здесь от 3 до 8) в одном Спринте работают над разработкой и поставкой одного Инкремента Продукта. Их направляет один Владелец Продукта посредством одного Беклога Продукта.

 

LeSS основан на ряде основополагающих принципов. Вот несколько из них:

  • Scaled Scrum is Scrum: Скрам на уровне организации - это все тот же Скрам со всеми принципами и правилами. LeSS - это не надстройка над Скрам, который применен только на уровне команд, нет. LeSS применяет Скрам ко всей продуктовой организации.
  • Whole Product Focus: внимание на всём продукте, а не его частях. Как вы могли видеть из описания каркаса LeSS, приведенного выше, все команды (сколько бы их ни было) работают вместе, синхронно над одним продуктом. Это существенно упрощает организационную составляющую, вынуждая команды учиться координироваться и кооперироваться.
  • Lean Thinking: LeSS берет очень многое из бережливого производства (философия Toyota). Так, внедрение LeSS основано на принципе "kaizen" (постоянное улучшения), где внедрение не заканчивается, когда завершен "план проекта по внедрению изменений". В LeSS нет понятия "трансформации", "команды изменений", "беклога внедрения" и прочих терминов из традиционных взглядов на внедрение изменений, которые имеют весьма ограниченный, кратковременный и условный эффект. Вместо этого в философии LeSS изменения - сами по себе новое статус-кво, они новая норма, и организация должна постоянно улучшаться, экспериментируя и обучаясь.

 

Чуть больше о принципах в кратком экскурсе по LeSS (на английском):

Больше о LeSS вы можете узнать на официальной странице: www.less.works и посетив тренинг. Также, скоро на русском под редакцией Алексея Кривицкого выходит книга "Large-Scale Scrum" от авторов LeSS.


Не пропустите Certified LeSS Practitioner (CLP)

Киев, октябрь 2017

Описание тренинга

Класс Certified LeSS Practitioner рассматривает вопросы применения Scrum в многокомандных организациях: 3 - 103 команды, работающих над созданием и поддержкой одного продукта.

 

Основной вопрос в таком контексте не в том, как смасштабировать Скрам (хотя, это важно). Сутевой вопрос в том - как упростить дизайн организации, чтобы управлять разработкой в таком масштабе без лишних ролей, раздутой иерархии, избыточной координации. More with LeSS!

 

Так что по сути, это мастер-класс по организационному дизайну и системному мышлению.

 

Конечно же будут детально рассмотрены каркасы Large-Scale Scrum (LeSS и LeSS Huge). Вопросы внедрения этих каркасов и вопросы поэтапного перевода текущих иерархий и структур компаний на LeSS.

 



Culture follows structure

В мае мы провели третью встречу Scrum Master Club. Эта встреча была посвящена работе с культурой компаний. Неисчерпаемая тема. Все мы хотим поменять культуру компаний к лучшему. Но как?

 

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

Посмотрите на два приведённых ниже фото - какая культура более гибкая?

Очевидна вторая. Там и столы для парной работы. И стен достаточно для визуализации. Выходит внешняя среда формирует культуру? Так и есть:

И по сути единственный способ влиять на поведение, привычки и культуру - это менять внешнее окружение. В после мини-доклада мы рассмотрели и проработали в группках три организационно-структурных решения, которые существенно влияют на культуру. Задача участников была изучить влияние определённых орг решений в компании на поведение сотрудников. 

 

Три сценария:

 

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

 

Зачастую подобная структуру приводит в полностью противоположной динамике:  выделение платформенной команды изолирует их лидеров от целей пользователей и бизнеса, что приводит к тому, что у платформа зачастую начинает восприниматься как "продукт в себе". Это в свою очередь ведёт к тому, что в таком отделе заводится свой "технический продакт оунер" со своим "роудпэмом" и "стратегией развития платформы". А это всё локальные оптимизации, мешающие видеть общую систему и общие бизнес цели. И поэтому зачастую такое орг решение (выделение платформенной команды) приводит к повышению зависимостей между командами, усложняет координацию, приводит к избыточным инженерным решениям, усложняющих общую архитектуру, и всё это удлиняет циклы выпуска продукта с точки зрения конечных пользователей.

 

Всё это контринтуитивно и зачастую неявно в организации, от этого в первую очередь страдают инженеры и пользователи. Но кто-то ведь принимал подобные решения? Кто-то ведь решил выделить платформу в "продукт" и наделить властью "технического продакт оунера".

 

Поэтому изучение системной динамики (что от чего зависит и что к чему ведёт) - очень важный навык менеджеров современных компаний. Без этого навыка мы склонны принимать решения, которые лишь поверхностно выглядят разумными, но приводят к совершенно казалось бы неожиданным и случайным последствиям.

 

Вот пример дебрифа одной из групп:

Другие два кейса, тоже по своему интересны. Эти орг. решения приводят к своей динамике, не менее удивительной, чем при платформенной работе:

Системное мышление и "мудрые" продуманные подходы к организации компаний на мой взгляд лучше всего описаны в литературе по Large-Scale Scrum - методу мышления о применении идей и принципов Скрам ко всей организации. 

 

Приходите на наши новые встречи Клуба Скрам Мастеров. Анонсы вывешиваются на нашей facebook-странице.


Слайды выступления:


Доклад на PM Day Kyiv 2016: Complexity and system thinking

Моё выступление на главной (она же "гнучка") сцене PM Day Kyiv 2016 прошло под знаменем сложности, спагетти и японской поэзии.

 

Ниже - избранные фото и слайды, ещё ниже - полная презентация. Видео в процессе - ждём с нетерпением.

Избранные слайды и фото


Слайды доклада


0 Comments

Large-Scale Scrum with LEGO

Мои слайды с воркшопа на AGILEEE 2017 по масштабированию Скрам.


0 Comments

Continuous Improvements в LeSS

Продолжаю цитировать перевод новой книги по #LeSS:

 

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

 

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

Или даже лучше - в некоторых организациях существует отдел трансформаций.

 

Избегайте их!

 

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

0 Comments

Large-Scale Scrum: Законы Лармана об Организационном Поведении

Мне выпала огромная честь выступить редактором русского издания недавно вышедшей книги по LeSS "Large-Scale Scrum".

 

Кроме того, что я давно хотел перечитать книгу полностью, а не частями и помочь с ее адаптацией на наш рынок, сам проект выдается очень увлекательным.  Я не только редактирую текст, с точки зрения LeSS, я правлю перевод, пытаясь найти в русском адекватные переводы таких терминов как к примеру: "cross-functional cross-component end-to-end colocated feature team".

 

Пожелайте мне удачи с этим!

 

Сегодня дошел до законов Лармана из главы про Внедрение, не могу не поделиться:



Законы Организационного Поведения Лармана гласят следующее:

  1. Организации неявно оптимизированы, чтобы избежать изменения существующего порядка вещей (статус-кво), сложившегося среди руководителей среднего и нижнего звена, в должностях узких специалистов и во властных структурах.
  2. Как следствие из первого закона: любая инициатива внедрения изменений будет сведена к переопределению или перегрузке новой терминологии, которая будет, по существу, обозначать то же самое что и существовавший статус-кво.
  3. Как следствие из первого закона: любая инициатива внедрения изменений будет осмеяна как “пуристская”, “теоретическая”, “революционная” и “требующая прагматичной адаптации под локальные потребности”, что отвлечет внимание от устранения слабостей в сложившем порядке вещей среди руководителей и специалистов.
  4. Культура следует за структурой.

Предвосхищая ваши мысли, следует также сказать, что и структура следует за культурой, особенно в молодых компаниях - стартапах. Но это утверждение имеет скорее поэтически емкое, чем буквальное значение.

 

Внедрение LeSS

 

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

 

...

 

При масштабировании следует придерживаться такого принципа внедрения: непрерывное улучшение до полного совершенства.

 

...

 

Так при внедрении LeSS отсутствует как инициатива изменения, так и группа и менеджеры по реализации изменений. Изменения в LeSS происходят постоянно посредством экспериментирования и совершенствования, и сами изменения являются новым порядком вещей.


Не пропустите Certified LeSS Practitioner (CLP)

Киев, апрель 2017

Описание тренинга

Класс Certified LeSS Practitioner рассматривает вопросы применения Scrum в многокомандных организациях: 3 - 103 команды, работающих над созданием и поддержкой одного продукта.

 

Основной вопрос в таком контексте не в том, как смасштабировать Скрам (хотя, это важно). Сутевой вопрос в том - как упростить дизайн организации, чтобы управлять разработкой в таком масштабе без лишних ролей, раздутой иерархии, избыточной координации. More with LeSS!

 

Так что по сути, это мастер-класс по организационному дизайну и системному мышлению.

 

Конечно же будут детально рассмотрены каркасы Large-Scale Scrum (LeSS и LeSS Huge). Вопросы внедрения этих каркасов и вопросы поэтапного перевода текущих иерархий и структур компаний на LeSS.

 



0 Comments

Краткое руководство по масштабированию Scrum встреч до 50+ участников (без дополнительных затрат)

Скрам масштабируется

Рост - про увеличение в размере, масштабирование - про повышение интеллекта. Рост - о добавлении слоёв иерархии, новых ролей и процедур. Масштабирование - о преодолении сложности её минимизацией.

 

На первый взгляд, Scrum тяжело уживается с ростом организации, ведь этот фреймворк не поощряет создание дополнительных ролей, увеличение состава команд и тиражирования беклогов. Поэтому в поиске “канонических” решений так легко не заметить весь сокрытый потенциал возможностей Скрам по масштабированию.

 

Масштабирование организации по Scrum происходит за счёт повышения внутреннего интеллекта системы, позволяя её компонентам работать независимо, но при этом слажено. Это похоже на молекулы воды, которые уничтожают грязь и помогают нам стирать одежду, мыть посуду, машины и даже детей…

 

Не то, чтобы участники команд буквально уничтожали элементы беклога при планировании спринтов… но ход мысли и общая идея вам должны быть понятны.

 

Вам не нужно управлять молекулами воды, чтобы они выполняли свои функции. Нужно позволить им сделать свою работу. Именно так и Scrum помогает решать сложные и трудоёмкие задачи: спуская их на уровень команд и конкретных людей, позволяя им самостоятельно разбираться во всех необходимых деталях.

Скрам встречи масштабируются

По правде говоря, все Scrum встречи масштабируются настолько просто, что я довольно долго сомневался, писать ли об этом вообще.

 

Для масштабирования Scrum церемоний фасилитатору необходимо сделать следующее:

  • Подготовить место проведения встречи.
  • Пригласить нужных людей.
  • Прояснить ожидаемые цели.
  • Помочь участникам разбиться на меньшие самоуправляемые группы.
  • Предоставить достаточные (но не избыточные) рекомендации по дальнейшей работе.
  • И, наконец, не вмешиваться, давая интеллекту системы разобраться со сложностью.

Давайте посмотрим на практическое воплощение этих идей.

Масштабирование работы над беклогом продукта

Преодоление сложности - не про разбивание больших вещей на мелкие элементы: очень надеюсь, что вы не разбиваете тарелки на мелкие кусочки, чтобы их помыть (я уже молчу о мойке машин и купании детей). Вместо этого вы просто подставляете тарелку под струю воды и позволяете молекулам выполнить свою работу на невидимом (неуправляемом вами) уровне.

 

С продуктами - та же история. Вы не поможете системе преодолеть сложность и трудоёмкость разработки продуктов, если начнёте разбивать их на мелкие под-продукты с множеством мелких беклогов.

 

Как раз наоборот - вы добьётесь обратного эффекта - так как кому-то теперь придётся заниматься склейкой всех этих компонентов. Хотя на первый взгляд это выглядит не очевидно, вы должны разок увидеть это своими глазами, тогда вы поймете, о чём я говорю...

Подготовка места проведения встречи

Когда мы пытаемся масштабировать разработку продуктов, мы часто обращаемся к совету из Large-Scale Scrum: фокусируйтесь на всём продукте. На этом этапе я обычно помогаю группе стейкхолдеров, визионеров и продуктоводов совместно создать общее понимание “большей картины”, чем те, что есть у каждого. Иногда они приносят свои мини-беклоги, и мы начинаем склеивать продукт по кусочкам. Это зачастую довольно длительный процесс.

 

В большинстве организаций это процесс создания “большой картины” может занять довольно много времени. Это связано в первую очередь с тем, что практики сегодняшнего продуктового менеджмента (так сказать его статус-кво) как раз поощряют разбиение больших продуктов на мелкие удобоваримые куски. Поэтому у меня всегда при себе, помимо маркеров и стикеров, есть баночка супер клея. Также с её помощью я могу выделывать всякие штуки, но это совсем другая история.

 

На фотографии ниже группа продакт менеджеров совместно создаёт общую “большую картину” продукта. На доске отображены: общие бизнес цели, цели релизов, “user journeys” и прочее - там также достаточно места для будущего беклога:

 

Как “большая картина” готова - приглашаем всех в комнату!

 

Приглашение участников и объяснение целей

После того, как мы всех собрали ("все" - это те, кто может помочь нам разобраться в деталях работы), один из менеджеров продукта объясняет всем собравшимся принципы организации доски: цели, приоритеты, проблемы и задачи, гипотезы и главные общие вопросы.

Пока детский лепет, не правда ли? А вот теперь будет весело!

Маленькие самоуправляющиеся группы

Один продукт, один беклог продукта, общая работа над беклогом продукта - наша мантра, которую мы используем каждый раз, при работе над продуктом, где задействовано несколько (много) Скрам-команд.

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

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

 

Это то, что гибкость на продуктовом уровне на самом деле означает (помимо других вещей).

Краткие рекомендации для команд

 Когда мы сформировали смешанные группы, наш процесс выглядеть следующим образом:

  • Каждая группа берёт непроработанный элемент беклога продукта, приглашает в группу одного из продакт менеджеров и обсуждает эту тему не более 15 минут.
  • Главной целью обсуждения является выработка общего понимания: в чём заключается проблема, как выглядит “user journey”, … - минимальный, но достаточный объём информации, чтобы можно было сказать можно ли это сделать вообще, и если да - не слишком ли тут много работы. В противном случае - элемент бьётся на меньшие части.
  • По истечении 15 минут вся группа решает (с помощью быстрого голосования), насколько готов данный элемент и визуально это помечает на карточке (одна точка - недостаточно понимания; две точки - есть вопросы, но в целом понятно; три точки - alles klar!) и переходит к следующему непроработанному элементу.
  • И, кстати, друзья, наши элементы беклога продукта не хранятся в Jira. На самом деле мы не так давно отменили нашу лицензию Jira, когда перешли к использованию листов A3 для элементов беклога. Эмпирическим путём мы пришли к тому, что этого размера бумаги достаточно для хранения оптимального количество деталей. (И не спрашивайте, как апологеты экстремального программирования умудрялись втиснуть свои истории на пяти-дюймовых индекс-карточках. Получается, размер таки имеет значение).
  • По завершению оценки элемента беклога, участники группы складывают лист A3 и вешают его назад на стену. Таким образом, другим группам тоже будет видно, что этот элемент проработан, так как на нём есть точки.
  • Обычно за часовую встречу мы успеваем проработать около 12-15 элементов беклога, этого нам как раз хватает на две недели работы всех команд.

Не вмешиваться (напоминание менеджерам)

 Эта встреча выглядит довольно неорганизованной, даже хаотичной, и, если посторонний человек случайно войдёт в середине совещания, то ему, скорее всего, покажется, что совещание просто неуправляемое: некоторые рабочие группы иногда распадаются на ещё более меньшие, кто-то спонтанно подбегает к доске и начинает чертить диаграммы, другие внезапно решают пообщаться один-на-один посреди комнаты…

Но мы то знаем - всё идёт путём..

 

На самом же деле, хаос - это признак самоорганизации. Сравните, к примеру, солдат, марширующих на параде; и толпу хипстеров, стягивающихся к стадиону на концерт Red Hot Chilly Peppers. Кто из них кажется более организованным, а кто - хаотичным? Кем из них управляют, а кто самоорганизовался?

 

Так что, на самом деле ничего страшного, если процесс выглядит немного беспорядочным. Более того (и это мой личный вывод) - если Scrum-встреча недостаточно сумбурна - вы что-то явно недоглядели!


0 Comments

Scrum-мастер - не (только) командный коуч и фасилитатор

Или всё, что вы хотели знать о Скрам-мастере, но боялись спросить.

 

Бисексуальность удваивает ваши шансы на свидание в субботний вечер.


Вуди Аллен 

Мне часто задают вопрос: “Ты работаешь Скрам-мастером или agile-коучем”? Слишком часто. А после того, как я сообщаю о том, что работаю независимым agile-коучем, уточняют, работаю ли я как “agile-коуч, “на уровне организации” , или (я так понимаю, имеется в виду “простым смертным” ) Agile-коучем? В таких случаях я тихо ухожу вдаль.

Расскажу вам об одном недавнем случае. Ездил я как-то на open space конференцию (они ещё бывают называются “unconference”, но по-русски это звучит смешно), на которой матёрые agile-тренеры пытались проранжировать все виды agile-коучей: от фасилитатора команды (он же “коуч без власти”) до agile-коуча на уровне организации (он же “agile бог”). Скажем так, дискуссия не задалась. 

Но вот кто обожает играть с этими терминами, так это компании, выдающие сертификаты. Только представьте себе, что они могут продать “обычному” agile фасилитатору команды (мальчику на agile-побегушках) лучшую версию себя - такого себе супер-пупер-эпик-убернагибатора-эльфа-120-уровня-agile-коуча. Ему нужно только заплатить вот туда и получить хрустящую бумажку с печатью и красивой голограммкой... 

Не думаю, что разделение на подобные уровни - хорошая идея. Вообще-то, честно, это весьма плохая идея. Несмотря на то, что, безусловно, есть определённый путь (или пути) самосовершенствования, который каждый нас проходит за время развития в профессии, формальное разделение на уровни agile-коучей уже приносит индустрии больше вреда, чем пользы.

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

Кстати, о ценности...

Потоки ценности

"Scrum helped us to suck less"


Источник неизвестен

Скрам – это фреймворк для разработки и поддержки функционально сложных продуктов. В основе Scrum (как в и любого другого Agile фреймворка) лежит идея постоянно действующего процесса улучшений, нацеленного на увеличение поставляемой ценности заказчикам как можно быстрее.

Упрощенная схема процесса поставки ценности от идеи у кого-то в голове до кеша на счету компании (также известный как “поток ценности”) в самом простом виде выглядит как-то так:

В реальной жизни, конечно, поток ценности будет выглядеть не так радужно; будут какие-то препятствия, узкие места, задержки, очереди, буферы и прочий кошмар. И всё может усложниться до состояния, близкого к примеру ниже (картинка из статьи Систематизирование Потока Ценности):

Но, в чистом остатке, это всё-равно поток ценности, который, я надеюсь, сквозь все препятствия доходит до конечного заказчика.

Вот почему целью любого agile фреймворка для разработки продуктов (как, например, Scrum) является контролирование (в лучшем случае минимизация) сложности процессов разработки. Это позволяет сфокусироваться на действительно важной вещи - оптимизации потока поставки ценности. Так что, если исходить из этого постулата, главная задача agile-коуча - помощь организации (и её лидерам) в определении потоков ценности и их улучшении … постоянном улучшении.

И, чтобы не быть голословным, приведу вам пример из последнего отчёта State of Agile, который подтверждает, что 60% организаций, переходящих на гибкие методологии, ставят перед собой цель ускорить выпуск своих продуктов.

Стало быть, “просто коучить команды разработки” недостаточно

"Если ваш проект задерживается, вам следовало его раньше начать."


Том ДеМарко и Тимоти Листер, "Вальсируя с медведями"

Постоянное ускорение разработки продуктов и невозможно, если вы работаете только с командами разработки. Разве что они - бесконечный источник проблем, решение которых ускоряет выпуск продуктов, но это, конечно, маловероятно.

Так что, если мы хотим реально ускорить наш поток, - нам нужно держать в уме весь поток и работать на всём его протяжении. Если конкретнее, то нам нужно будет вовлечься намного раньше разработки - на этапе генерации и отбора идей продуктов и фич; во время ранней валидации и отсеивания идей; и на этапах, следующих за разработкой: деплоймент, поддержка и прочее.

К сожалению, я часто вижу примеры Скрам-мастеров, которых организационные структуры загоняют в рамки работы только с процессами разработки. Эти “угнетённые” agile-коучи не имеют полномочий для улучшения потока. Они совершенствуют процесс разработки, как будто это единственное звено в цепочке ... Хотя, конечно же, работать уже давно следует с другими узкими местами потока.

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

Water-Scrum-Fall или Страшный сон аджалиста

Мы используем Скрам в разработке программного обеспечения, но, так как наши команды разработки не контролируют весь процесс создания ПО, то релизами занимаются команда “опсов”. Я коучу команду разработки. А у них там другой коуч, вроде как, они там работают по Канбану” - я слышал подобное, и это меня очень расстраивает.

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

Неудивительно, что некоторые организации вообще упраздняют роль Скрам-мастера. Эта роль и правда не приносит пользы в организации, где никто не работает над целостной картиной. Там улучшения незаметны, и эта роль, естественно, становится просто лишней статьёй расходов. В таких организациях эта роль даже может вредить, так как количество конфликтов и уровень недовольства работой возрастают из-за разницы между возможностями и реалиями. И такие случаи - не редкость. Скрам-мастеров увольняют то тут, то там. И упраздняют как касту.

Дескать, “эта роль не приносит ценности”. Конечно ничего она приносить не будет, если её ограничить “фасилитацией в проведении командных встреч”.

Scrum-мастер = Agile-коуч для продуктовых организаций

Видеть, понимать и оптимизировать целостную систему (не её отдельные компоненты), исследовать динамику системы. Избегать фокусировки на мелочах и частностях, не заниматься повышением “эффективности” и “продуктивности” отдельных людей или команд. Клиенты заинтересованы в общем цикле “под ключ”, не в отдельных шагах.

 

Системное мышление, less.works

Так что, если вы заинтересованы в получении настоящих системных улучшений (а не в чем-то эфемерном, как, например, повышении велосити команд), вам нужно в корне пересмотреть своё понимание работы Scrum-мастеров. Они должны работать со всей продуктовой организацией. Иначе, как сказал Тобайас Мейер: "Удалить Скрам-мастера".

Есть и хорошая новость: на самом деле нет никакой необходимости выбирать между фасилитацией команд и коучингом организаций, пытаясь описать задачи настоящего Скрам-мастера. Это не противополжные вещи, не “или-или”. “Это ложная дихотомия” - так говорит Крег Ларман, объясняя Large-Scale Scrum.

Вместо того, чтобы приставлять Скрам-мастеров к конкретным командам (тогда у них не будет достаточного понимания целостной картины) и запускать agile-коучей в стратосферу (они тогда отрываются от реалий работы организации), попробуйте представить свою компанию как набор отдельных продуктовых организаций (разделённую по потокам поставки ценности заказчикам или, просто говоря, разделите компанию по продуктам). Тогда, соответственно, Scrum-мастера могут работать группами внутри этих продуктовых организаций, каждый с несколькими командами, фокусируясь и коуча отдельный поток “от А и до Я”.

Этим новообразованным командам и продуктовым организациям в первое время потребуется больше коучинга на уровне команд (командная фасилитация). Но со временем у Скрам-мастеров будет появляться время и необходимость работать и с другими частями процесса, переходя от одного узкого места к другому -  как показано на картинке ниже.


3 Comments

Новейшая история менеджмента компаний (часть 3): Битломания и три типа менеджеров в Скраме

Знаете ли вы этих людей?

Подсказка есть в моей статье "Битлз и самоорганизация".

George Martin
George Martin
Brian Epstein
Brian Epstein

Они – менеджеры. Оба управляли ливерпульской четвёркой. Одного из них даже называли “пятым битлом”. Но немногие меломаны знают их. Почему так?

 

Да и зачем группе нужно было целых два менеджера? Да ещё и такой непростой группе с двумя яркими соперничающими лидерами? Не много ли менеджеров и лидеров на команду из четверых человек?

ТРИ МЕНЕДЖЕРА – В САМЫЙ РАЗ!

Допустим, что вы работаете в команде разработки в крупной продуктовой организации.

Скорее всего, у вас и ваших коллег есть несколько менеджеров.

 

И это всё ещё будет Agile. Не верите? Смотрите.

 

В проекте есть три зоны ответственности:

Три зоны ответственности в проекте
Три зоны ответственности в проекте
  1. Зона бизнеса – что делать?
  2. Зона технологий – как делать?
  3. Зона процесса – каким образом подружить "что" с "как"?

Если мы рассматриваем отдельно взятую Скрам-команду из трёх-десяти человек в вакууме, то тут будут ярко выражены два типа менеджеров:

  • Менеджер-предприниматель;
  • Менеджер-фасилитатор.

МЕНЕДЖЕР-ПРЕДПРИНИМАТЕЛЬ

В задачи менеджера-предпринимателя входит весь тот набор, который в Скраме мы обычно предписываем роли Product Owner:

  • Беречь видение продукта;
  • Нести ответственность за финансовый результат;
  • Управлять объёмом работ;
  • Связывать команду с экспертами предметной области и пользователями для привнесения обратной связи в процесс;
  • Быть доступным для детализации и приема работы.

МЕНЕДЖЕР-ФАСИЛИТАТОР

В задачи менеджера-фасилитатора (в Скраме это Скрам-мастер) входит:

  • Поддержка и оберегание Agile-ценностей в отдельно взятом проекте и компании в целом;
  • Обучение команды, Владельца Продукта (Product Owner) и стейкхолдеров применению Скрам-каркаса и его правильному использованию;
  • Визуализация ситуации и коучинг команды, Владельца Продукта и стейкхолдеров по вопросам улучшения процессов и повышению эффективности;
  • Фасилитация процессов: встреч, генерации идей, принятия решений.

ЗАЧЕМ НАМ ЕЩЁ И ТРЕТИЙ ТИП МЕНЕДЖЕРА?

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

Так вот, в крупном проекте возникает ещё один – менеджер-профессор – тот, кто заботится о том, чтобы  работа выполнялась профессионально, а также поддерживает производственные процессы.

Эти менеджеры-менторы обычно фокусируются внутри специальностей: архитектура и проектирование; тестирование и автоматизация; дизайн и UX и т.д.

Три типа менеджеров и Скрам-команды
Три типа менеджеров и Скрам-команды

Члены кросс-функциональных Скрам-команд (т. н. “feature teams”) посещают различные мероприятия, организованные этими менеджерами, где обсуждаются конкретная специфика и тонкости специальности: как рефакторить код, как автоматизировать приёмочное тестирование, как улучшить дизайн и прочее.

Часто такие кружки называют “communites of practice”  или сообщества практик.

ИТОГ: ТРИ МЕНЕДЖЕРА – ТРИ ЗОНЫ

Итак, в крупной компании у каждого члена самоорганизующейся Скрам-команды будет три менеджера:

  • Менеджер-предприниматель (владелец продукта);
  • Менеджер-профессор (наставник специальности);
  • Менеджер-фасилитатор (Скрам-мастер).

POST SCRIPTUM

Brian Epstein – менеджер группы the Beatles, который успешно занимался вопросом прибыльности группы, организовывал выступления, занимался контрактами со студиями грамм-записи и паблишерами.

George Martin – продюсер группы, который проводил с группой месяцы в студии, записывая дубли и экспериментируя с новыми звучаниями и экзотическими инструментами.

Скрам-мастера у группы, по факту, не было! =) 

POST POST SCRIPTUM

Самая большая ошибка менеджеров – попытка управлять людьми.

Управлять нужно продуктом, технологиями и процессом.

Люди же умеют самоорганизовываться и самонаправляться.

Статья переопубликована с http://scrumguides.com.ua


0 Comments

Новейшая история менеджмента компаний: часть вторая, в которой страсти накаляются

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

 

Теперь коридоры компании полны вывесок вроде: Integration Manager, Iteration Manager, Quality Manager,

Development Manager, Account Manager, Change Manager, Crisis Manager, Retention Manager и т.д. Похоже, что наша компания отлично укомплектована и готова к дальнейшему развитию!

 

Но позвольте спросить: "Насколько место, изображенное на фотографии, приведённой ниже, безопасно?

Должно быть, это самое безопасное место на планете, ведь его охраняют так много специалистов, готовых отдать свою жизнь за безопасность.

 

Когда мне говорят: "У нас работают отличные менеджеры по удержанию сотрудников!", или "У нас самый сильный отдел архитекторов!", я про себя думаю: "Хм, наверное у них немало проблем с удержанием и архитектурой…".

Недавно, к слову, одна компания громогласно хвасталась в соцсетях о том, что её HR-специалисты – самые привлекательные девушки в индустрии. Интересно, что в этой компании призван компенсировать такой необыкновенный бонус? Надеюсь, что не высокую текучку кадров из-за убогости проектов.

Так или иначе, в нашей компании становится всё больше менеджеров на любой вкус. Они заточены под решение любых проблем: от создания сладкой жизни для сотрудников до управления проектными рисками и удовлетворения заказчиков.

А что происходит в голове человека, чья должностная инструкция называет его «менеджером»? 

Всё просто – он начинает "менеджерить"!

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

 

А когда начинается кризис, тот самый, под который он заточен, он автоматически начинает раздавать указания. Ведь он эксперт в этой области!  Ведь нет времени объяснять…

 

Что происходит в тот самый момент, когда менеджер дал инструкции и указания? Он затоптал на корню всё то, что agile призван бережно культивировать и оберегать, а именно: автономность команд и их самоорганизацию.

Не нужно менеджерить проблемы!

Делая это, вы автоматически начинаете менеджерить людей. А этого делать ни в коем случае не нужно, так как это деструктивно для всех. И для вас не в последнюю очередь. Вместо этого нужно делать нечто большее.

Но что?

Об этом чуть позже.

А для начала давайте посмотрим, как себя чувствует наш CEO: штат вырос вместе с расходами на его содержание, ожиданиями инвесторов и клиентов, но процессы существенно эффективнее не стали. С чего бы?

И тогда наступает момент прозрения: нам нужны метрики!

Давайте найдем слабое звено и оптимизируем его!

Звучит прекрасно.

На деле же это обычно сводится к следующему захватывающему шоу.

К примеру, у вас в компании четыре отдела.

И KPI выявили страшную неэффективность второго отдела (читай: "Там работают лузеры!").

Что вы будете делать?

Не спешите ломать себе голову. Упростите себе задачу. Представьте, что вы далеки от высокотехнологических бизнесов, и готовите блюдо из картофеля. Постоянно. Пять дней в неделю. Ну, такой у вас бизнес (не всем же писать стартапы).

Первый отдел, к примеру, чистит картошку. Второй – режет. В третьем её варят. В четвертом, ну скажем, давят на пюрешечку. Нормальный такой конвейерный процесс.

Вы - менеджер второго отдела (вам не повезло). Вы – самое слабое звено, ваши KPI ни к чёрту.

Что делать? Как оптимизировать нарезку картофеля? Что вам подвластно? Насколько вас интересует общая эффективность фабрики?

 

Помните: ваша карьера под угрозой! Самый лёгкий способ – изменить стандарты нарезки картофеля. Всё просто: режем крупнее, выпускаем быстрее!

Решение найдено! KPI ползут вверх. Ваш менеджерский бонус тоже!

Правда, в третьем отделе теперь как-то не очень. Но это уже не ваша проблема.

И вообще, улучшения – это  поступательный процесс. Сначала одно слабое звено, потом второе…

Они там ниже по потоку что-то придумают. Не зря же у них работает самый толковый менеджер по варке!

Узнаёте ситуацию?

Статья переопубликована с http://scrumguides.com.ua


В третьей части статьи вы узнаете о формальных и неформальных структурах вашей организации. О том, как функционировала «ливерпульская четверка». И о трёх типах менеджеров, которые по-настоящему смогут улучшить ситуацию в компании.

0 Comments

Новейшая история менеджмента компаний: от эры стагнации к Ренессансу

С 2008 года я в качестве консультанта и бизнес тренера посещаю различные IT компании. В некоторых провожу день-два, с другими работаю довольно долго. В последнее время я плотно работаю с 10-15 компаниями в год.

Недавно у меня появилось новое хобби – угадывать основные проблемы, с которыми сталкиваются проекты в таких компаниях, по описанию структуры компании.

Я не гений и не пророк. Далеко нет. Просто мне кажется, что я нашел некоторую очень типичную линию развития компаний (pattern, если хотите), которая позволяет довольно точно воспроизводить текущую фазу развития компании со всеми присущими характеристиками.

В 2012 году я осмелился обобщить свои наблюдения в виде доклада, с которым выступил на нескольких крупных конференциях. В частности, на Agile Eastern EuropeAgile Turas и PM Conf. Доклад, к моему удивлению (он несколько упрощенно представляет мою модель), был хорошо принят аудиторией и привлек довольно много  дискуссий после конференций.

Эта статья – не слайд-каст, а скорее описание моих наблюдений о типичной эволюции компаний с использованием иллюстраций из доклада.

  • Как типично развиваются компании?
  • Откуда и когда появляются менеджеры?
  • В чем суть правильного менеджмента?
  • Какова роль менеджера в Agile-проектах?
  • Что такое Agile-организация?
  • Как в ней выглядит роль менеджера?

Этими вопросами я задавался готовя свой доклад и эту статью. Но, чтобы понять всю цепочку эволюции компаний, нам нужно начать с самого начала…


В книге “Founders at work” приводятся десятки историй известных компаний – от первых дней компаний до миллиардов на счету:

 


Говоря обобщенно, компания начинается вокруг нескольких идеологов.


Они настолько громко начинают мечтать о завоевании мира, что к ним присоединяются еще несколько человек.

Так формируется первая команда компании.


Чем интересна эта команда?

 

Во-первых, структурой.

Эта команда объединяет все роли и все виды специальностей, которые совместно могут реализовать идею в продукте – “from concept to cash”.

 

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

 

В-третьих, как следствие из предыдущего, своей когерентностью.

Все настолько сильно объединены общей идеей, что работают как единый организм. И обычно по много часов в сутки. И при этом без выделенного менеджера, который бы раздавал задачи, контролировал прогресс и замерял мотивацию персонала.

 

Идеальная Скрам-команда, не правда ли?

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


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


Слева растет как на грибах отдел аналитиков. Справа – отдел разработчиков.

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


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

И ведь правда – они были взяты на работу в “dream team” в первую очередь благодаря своим профессиональным навыкам. Они были первоклассным аналитиком и супер-программистом. А теперь всё, чем они занимаются – это менеджмент своих подчиненных.

Согласно принципу Питера ”работники компании растут до максимума своей некомпетентности”, и где-то наступает предел.


Первые люди уходят из компании, сетуя на то, что “она уже не та, что была раньше”. Или же само-понижаются от руководителей до инженеров – туда, где работа в кайф (пример всем известного Стивена Возняка из Apple).

 

Тут-то и начинается поиск и найм менеджеров, которые “придут и все исправят”.

И вот именно с этого момента компания уже больше никогда не будет такой, как прежде…


Но давайте копнём глубже – что вызвало необходимость построения дополнительной прослойки менеджмента?


Устранит ли привлечение новых менеджеров причины проблемы?

 

Поможет ли найм новых менеджеров решить проблему отсутствия вовлечённости сотрудников, которые не видят основателя, не знают стратегию и цели компании?

 

Смогут ли менеджеры компенсировать нехватку синхронизации между растущими отделами?

 

Я считаю, что зачастую найм менеджеров призван лечить симптомы, а не глубинные причины, вызванные ростом компании. Это всё равно, что вычерпывать воду из дырявой лодки.

А проблем в большой компании обычно немало:


Теперь наша компания выглядит примерно так:


И сказать, что стало сильно лучше, нельзя. Ведь теперь обычные работники ещё больше отдалены от основателя, менеджеры заняты микроменеджментом своих отделов, а работники – своими узкопрофильными задачами.

 

Компания начинает стареть. Ведь она все дальше и дальше уходит от своей начальной успешной структуры – самоорганующейся высокомотивированной команды первоклассных специалистов, верящих в идею и совместный успех.

Во второй части статьи я покажу, как в компаниях типично внедряются процессы оптимизации, основанные на метриках. И к чему это обычно приводит.

 

А в третьей части мы попробуем омолодить компанию, перестроив её по первоначальному принципу цельных команд.

 

Но сначала подбавим кризиса метриками…

 

Не переключайтесь!

Статья переопубликована с http://scrumguides.com.ua


0 Comments