Agile по-бандитски, регулярная армия, фуражиры и спецназ
Возможно ли провести Agile-трансформацию в большой компании, а также сколько это стоит, зачем это делать и что делать потом, когда ты все это начал.
Привет, я Денис. Тренер по Agile, Scrum Master в Luxoft. Называю себя Agile Coach, потому что лечу неправильное понимание Agile, Scrum, Kanban, XP, Lean в головах команд и стейкхолдеров методами коучинга. Еще я повышаю удовольствие и пользу от работы тем, что учу следовать ценностям Agile. Но иногда меня «несет», и я делаю тренинги или воркшопы или даже пишу статьи.
Сначала меня очень обеспокоила тема, когда заказчик просит команду работать по фреймворку Scrum, не осознавая цену и цели. Потом сюда добежала досада относительно аджайл-трансформаций, особенно в компаниях, где это «налазит» на культуру, как сова на глобус.
Хорошо, что коучи, которых я знаю, делают трансформацию степенно и с расстановкой. Ведь на нашем любимом IТ-ресурсе DOU постоянно встречаются комментарии от инженеров ИT-специальностей, объясняющие, что скрам и аджайл уже «не торт». И они злятся, не понимая, зачем так с ними поступают.
Гравюра. Нью-Йорк, США. 1873. Дети разделывают табак. Photo credit: GETTY
О неэффективности Agile вышло много статей в этом году: The Agile Sweatshop, Open Letter to all the People Being Forced to do Scrum, Mockery Of Agile, Agile Does Not Work!. И вишенкой на торте стала презентация с тщательным объяснением и ссылками: Alexander Much «Agile in automotive».
Хочу попробовать еще раз доходчиво все объяснить. Надеюсь, эту статью также увидят собственники бизнесов, которые сейчас проводят или планируют проводить такие изменения.
Важный момент: когда я писал эту статью, то имел в виду моду на аджайл-трансформацию не только в ИТ-компаниях, но и в организациях, где разработка ИТ-продуктов стала видом деятельности, который не отнимает бОльшую часть людского ресурса. Например, вместе с развитием ИТ-продукта есть еще огромная доля его поддержки или основного бизнеса, который сосуществует с этим продуктом. Так, Amazon еще занят продажами товаров, собственных услуг и поддержкой работоспособности платформ.
Такие компании, как Salesforce, работают с подрядчиками, концентрируются на продвижении и развитии партнеров. А вот, к примеру, в Rozetka или Uber — Software хоть и является главным инструментом, но бизнес заключается в работе с партнерами, поставщиками и клиентами. Поэтому если компания начинает разрастаться, то количество людей, занятых НЕ software-инженерией, увеличивается в прогрессии.
И тут у меня рассказ не складывается без аллегорий.
Часто разработчиков сравнивают с... да с кем только не сравнивают! И с дровосеками, и с гребцами, и с каменщиками. И даже с солдатами. Что, если бы мы разрабатывали продукты и проекты, как воинские формирования? Давайте проведем параллели.
Регулярная армия
Знаете, как двигать город с 200 000 населением вперёд со скоростью 24 км в день? «Supplying war», Martin van Creveld. Это задачка «со звездочкой» для военных. Именно так обстоит дело с перемещением войск регулярной армии at scale. Представьте себе логистику этого двигающегося города, где все хотят еды, развлечений, болеют и нуждаются в услугах.
Процитирую из «Голод и болезни: неразлучные спутники войны»:
«Порядок, принятый в большинстве стран Западной Европы в
Представьте себе полвагона зерна, 20 коров, грузовик всякого добра, еще самосвал с ячменем для лошадей, цистерну пива, бочку уксуса (обязательно, иначе холера нападет) — и все это надо где-то взять, распределить и доставить по фронту.
Например, полевая хлебопекарня РККА.
Иногда даже целые тыловые узкоколейки строят для оперативного подвоза провианта, боеприпасов и солдат.
Австро-венгерские вооруженные силы и железнодорожный транспорт
Именно для этого в армии есть фуражиры. Чтобы сократить потребность в подвозе тяжелого и объемного провианта, его можно найти на месте. Так как фуража нужно очень много, а с собой его вести долго и неудобно.
Кто-то из агрессоров печатал фальшивые деньги того государства, куда шел войной, кто-то раздавал крестьянам облигации будущего государства, которое наступит, когда они всех освободят. А некоторые просто силой и угрозами все отбирали.
В условиях лишений военной жизни солдатам часто приходилось восполнять необходимые припасы за счёт грабежа гражданского населения. На гравюре XVII века изображена типичная сцена разграбления деревни.
Попросту говоря, это даже не военная служба, а военный фронтовой рэкет. Узаконенное дозированное контролируемое мародерство.
Идут себе вооруженные небольшие части сразу за разведкой и собирают по селам зерно, колбасу, млеко, яйки и т.п. Солдатам и лошадям нужно хорошо питаться. Иначе начнут бунтовать, и никакой войны не получится.
Прям получилась отдельная доктрина — Military Supply Chain Management. Там сказано, что Supply On-Demand или Just-In-time — слишком рисковая стратегия, всего нужно иметь про запас, много и рядом. Тогда только и можно воевать. Никакого тебе Toyota Way!
Ведь для оперативного обеспечения целая отдельная полевая служба с обозами и складами есть. Если все зерно, топливо, провиант тащить за собой, то это уже не война, а полное переселение.
Становится понятно: с этим всем добром регулярная армия становится очень неповоротливой и медленно меняет свой план действий. Если же план и меняет, то адаптирует логистику заново. Первые дни солдаты живут на сухпайках, пока опять не подтянется весь обоз с провиантом и амуницией. Иногда из-за этого локальные командиры выполняют приказы с легким отклонением, чтобы всех прокормить и обуть.
Если ты уже баню построил, походный бордель соорудил, столовую оборудовал, и под боком у тебя фронтовая узкоколейка, где подвозят вкусняшки, бросать все и уходить в закат наступать куда-то в неизвестность, бросая все, очень не хочется.
И тут — никакого аджайла, никакой гибкости, никакого тебе welcome change. Ага, щаззз!
Все это, несмотря на ужас снабжения, остается достаточно целесообразным и эффективным, если целью является удержание огромной новой территории и наведения порядка, который пожелает новый правитель. Другие формирования, не обладающие такой силой и операционным capability, проигрывают долгосрочные сражения, так как не обладают долговременным запасом прочности.
Регулярная армия должна быть великолепно отлажена и создана для захвата и удержания большой территории. Также она должна уметь организовать работу тыловых служб, возглавить наведение там временного порядка, нормализовать временные административно-социальные и бытовые функции. Ведь старые после наступления или при отступлении прошлых войск — разрушены, а новые гражданские силы и админресурс еще не прибыли на место исполнения обязанностей. Военная администрация временно должна уметь все. Получается, армия, кроме войны, еще и хозяйственно-правовой механизм.
А что же краткосрочные сражения? Специальные операции? Как же обеспечить успешный захват и наступление? Я думаю, вы уже поняли к чему я клоню, но читаем дальше.
Формирования народно-повстанческих армий (спустя некоторое время — бандитские формирования)
Ключевой фактор успеха этих сил:
- маленький размер! Не поймаешь быстро — «сквозь пальцы проскальзывают»;
- фокусировка на месте, времени и на общей важной цели для всех (защитить себя и свое село, губернию или городок);
- быстрое и маневренное изменение места дислокации, планов, методов и принципов группировок;
- мгновенное проведение краткосрочных операций;
- анализ поступающих данных от тех, кто повсюду и наиболее заинтересован в их победе — простые крестьяне, люди, которые все знают, молчат для врагов и все доносят повстанцам.
Часто эти партизанские или добровольческие формирования уходят в полуавтономное обеспечение, питаясь провиантом от местного населения. В первое время народ видит в них защитников и свою надежду на лучшую жизнь, добровольно отдает им еду, одежду, медикаменты, рекрутов. Как правило, это продолжается недолго — один урожайный сезон.
Интересная деталь данного феномена — это небольшое формирование людей, сплоченное общей целью. Это может быть отряд партизан, защитников села, активных противников какого-то режима, но никогда — большое скопление людей. Потому что в большом «огороде» у каждого есть своя маленькая цель, которая превыше общей. Пусть она тоже «правильная и великая», но защитить свою корову — это важнее, чтобы свои детки были целы и сыты.
Не видя смысловой цели, данные группировки распадаются или выходят из-под контроля и общего порыва энтузиазма. Иногда они становятся просто бандитскими шайками или идут под другие знамена, чтобы продолжать быстрое обогащение, ставшее самоцелью. Когда той еды, что давали добровольно, уже не хватает, приходится отбирать ее силой. А там уже до простой жажды наживы рукой подать. Да, господа, дофамин очень подлый :) Кстати, про дофамин инженеров есть отличная статья: Dopamine Driven Development.
Так может быть с компанией, которая на пике своей звездной части Бостонской матрицы потеряла vision и увлеклась краткосрочными целями. При этом, не предусмотрев всех нужных функций и влияния окружающей среды.
Да, тут сложно все предвидеть, поэтому и существуют многие M&A сделки, или компании уступают конкурентам, или просто перестают существовать, «выпав» из успешного сценария. К примеру, Trello: Почему авторы Trello не смогли создать бизнес на 1 миллиард долларов. Они себя вовремя не монетизировали, а «хавчик» сам-себя не завезет же! Вот и рассыпалось отличное народное формирование, отличная продуктовая компания. Даже если бы начали «давать жару» изнутри, какое-то время бы просуществовали, но превратились бы в бандитов для самих себя. Что-то вроде Valve (Жуткая правда о Valve).
Если же кому-то это все удастся удержать, возглавить и сохранить миссию, бизнес нужно будет масштабировать. Любой бизнес должен развиваться непрерывно.
Если Это становится из маленького — большим, а потом очень большим, Оно (формирование, компания, стартап) уже слабо обладает какими-то изначальными преимуществами и все больше нуждается в методах управления аналогичным регулярной армии.
Сначала действительно борются за идею, а потом, наращивая мощность, точно так же требуют контроля, дисциплины и снабжения.
Кроме того, для постоянного роста, и первым, и вторым приходится брать местное население и рекрутов для обеспечения различных функций: сервисного или военного назначения. Прачек, полицаев, лесорубов, извозчиков. Ну и народное хозяйство проще вести местными силами. В итоге, когда свои люди заканчиваются, подойдет уже кт попало, чтобы воевать или готовить солдатам кашу.
В данном случае на общих идеях не поедешь, потому что они у каждого свои. Это
Спецназ
Спецназ не будет возиться с удержанием территории, у них нет к этому никакой предрасположенности. Их не этому учили. Они молниеносно могут совершить диверсию с минимальными данными о местности, даже когда вокруг силы противника постоянно передвигаются и меняется окружающая обстановка.
Небольшая группа, незаметные, уязвимые, но очень опасные. Могут при соблюдении доли осторожности обеспечиваться малым. Им нет дела до общих целей. Цель диверсантов точечная, а в долгосрочном периоде — сохранить себя как слаженный боевой отряд. Именно благодаря этому они и выживают.
Интересно, что они получают удовольствие не от выполнения общей великой миссии, а от того, насколько они профессионально справляются с задачами, самостоятельно их выполняя и наращивая мастерство во всем (в т. ч. и во взаимодействии между собой).
Помните Дэниэла Пинка? — Autonomy, Purpose, Mastery. Для спецназа эта часть особенно актуальна, потому что кроме желания «дайте деняк», они почему-то выбрали именно это занятие.
Daniel Pink, Drive, the surprising truth about what motivates us.
Но эти парни очень дорого обходятся.
Сначала они делают короткое задание, а потом, если его нет, тренируются. Причем без всякого Value и, к тому же, в полсилы. «А вдруг война, а я уставший?!». И если кто-то из этой маленькой группы уйдет, ее нужно сплотить по-новой. Исчезает «чувство локтя» и былая слаженность. Ужасно, но все это время им надо платить зарплату. Иначе пойдут работать охранниками в супермаркет пойдут работать в другие формирования, у которых есть важное дело.
Сейчас физическое противостояние потеряло смысл, империи уже не обогащаются таким путем. Удерживать захваченные территории стало значительно тяжелее, в частности, в связи с ростом гуманизма. Полномасштабная война стала менее окупаемой, чем политика, кибервойна или экономическое мировое соревнование. Физический захват территорий может даже подорвать экономическую стабильность имперского строя, когда удержание территории станет дороже, чем окупаемость этих территорий. Поэтому империи должны постоянно воевать, чтобы не исчезнуть в долгосрочном периоде.
Точно также, как в случае с захваченными территориями, физическое тело бизнеса очень даже ощутимо. И это тело, помимо обеспечения хозяина всем необходимым, является тяжелой обузой для самого хозяина. Нужно постоянно наращивать обороты, чтобы прокормить бэк-офис.
Какая команда может быть самоорганизованной?
Из всех трех описанных аллегорий, самоорганизованной может быть та команда, которая долго делает серию недолгих заданий. Оставаясь в тонусе, целостной, тренированной, хорошо снабженной и оплачиваемой. Не перегруженной административными функциями. Та команда, в которой дисциплина и профессионализм исходят не столько от начальства, сколько от явного осознания, что это необходимо им самим. Иначе прибьют еще на выброске.
Полностью автономное существование такой команды без базы и финансовой подушки я слабо себе представляю. Все-таки, части спецназа к кому-то относятся, кем-то снабжаются. Кто-то держит этот спецназ как статью расходов. Кто-то бОльший, и с определенной целью.
Зачем именно Agile? Почему все туда бегут? В этом ли секрет успеха?
Agile manifesto хотели назвать Adaptive manifesto, но выбрали другое слово, чтобы не повторять название компании одного из его авторов. Представьте, что теперь манифест называется манифестом адаптивности. Давайте с этим жить.
Вызов бизнеса — сделать для кого-то что-то за деньги, и чтобы покупали еще больше. Победить конкурентов и продолжать расти, ведь остановить рост — означает, что конкуренты придавят тебя. Мир, конкуренты, клиенты и способы их восхищения постоянно меняются. И ты меняешься. Это кратко выражено в аббревиатуре V.U.C.A.
Чтобы придумать что-то новое в условиях регулярной вуки, давным-давно описали TRIZ, а консультанты включили его в SixSigma. Простыми словами — постоянно экспериментируй, и ты найдешь хороший способ решения задачи. По-другому это не работает. Так человеки и стали цивилизацией. Постоянно экспериментируя, погибая толпами или развиваясь в мощные империи. Это описано в нашей любимой книге Sapiens.
У людей разумных есть масса заблуждений и верований. Мы думаем, предполагаем, верим и строим догадки. Проверка этих догадок у нас теперь сознательная. Раньше за нас это исполнял мутагенез бессознательно и медленно, теперь мы делаем это специально и быстрее.
У нас есть уникальное свойство: мы мыслим гипотезами и абстракциями, когда нет точных данных и проверенного опыта. А даже когда есть, мы все равно его искажаем личной когнитивной системой. И называется это — когнитивные искажения.
На этой диаграмме 188 плохо изученных когнитивных искажений, выделенных на данный момент
У существ менее развитых — это умение проявляется в меньшей степени. А у нас — это способ быстрой эволюции. Но эволюция — это кто-то погиб, а кто-то адаптировался и стал сильнее. В общей массе.
Если посмотреть на принципы адаптации в разработке (Agile manifesto) с этой точки зрения, они провозглашают следующее: не важно, что мы себе запланировали — это может быть ошибочной гипотезой. И проверишь ты это только тогда, когда дашь своему самому конечному пользователю понажимать кнопки твоего софта и протестить, подходит ли это под его бизнес-процессы и рынок. Пока этого не сделаешь, существует вероятность, что ты делаешь ерунду.
Пока не покажешь это конечному пользователю, ты не узнаешь, что сделал.
Так часто бывает при разработке программного обеспечения. Это однажды подтвердилось исследованием Standish Group. Майкл не верит этой статистике, но всякий раз, когда я спрашиваю своих студентов на тренингах, они подтверждают ее даже в бОльшем масштабе.
В основном, статистика касается Enterprise Solutions. В других проектах, признаю, она не такая драматичная.
О трансформации большой компании
Интеллектуальный труд сейчас называют когнитивной работой. Все потому, что для производства интеллектуального продукта люди задействуют свой когнитивный аппарат, интуицию и багаж знаний, который постоянно трансформируется.
По мере разрастания масштаба решаемых задач и количества вовлеченных людей работа становится сложнее, а результат не всегда получается быстрее или лучше. Однако, одному человеку работы много, и ускорить ее нереально. Нужно много инженеров. Растет количество факторов, которые мешают эту работу делать максимально эффективно.
Вот как это выглядит на схемах:
Если работу делает один инженер, он сам вынужден справляться с непредсказуемостью среды, технологий и запросов рынка/стейкхолдеров. Его собственные когнитивные искажения влияют только в отношениях с последними. Его цели совпадают с общими, т. к. он один.
Когда работают несколько, когнитивных искажений становится больше, и они очень разнообразны в разные моменты времени.
Когда это уже несколько команд, ухудшается коммуникация. Когнитивных искажений нормальных с виду людей становится еще больше. Также возрастает фактор непредсказуемости. Теперь уже изнутри.
И если эти программа или проект состоит из множества команд и нескольких групп пользователей, доменов бизнес-процессов — увеличивается влияние всех помех и препятствий. Как правило, возрастает технологическая сложность продукта и влияет различный технический, интеллектуальный и культурный уровень всех участников когнитивной работы.
Всю эту «королевскую рать» по канонам традиционного менеджмента тянуть в одном направлении уже сложнее. Но давно появилось уже понятие командной работы. Для этого даже есть термин Team-Based organization. Рассмотрим его ниже.
Красное поле на диаграмме демонстрирует то, как меняется влияние
Кому захочется детальнее разобраться, пояснения тут: V.U.C.A. хорошо объясняется через фреймворк Cynefin. Все-таки его сделал Dave Snowden, а он почти 20 лет работал (и продолжает работать) над проблемами tacit knowledge, часть этого времени проработал в IBM.
Для области разработки программного обеспечения, где значительную роль играет изменчивость и непредсказуемость технологического стека, все описанные в Cynefin Framework явления переложены на шкалы в Stacey Matrix.
Список известных малоизученных когнитивных искажений я уже приводил выше. А основное различие целей индивидов и корпорации я попытался объяснить в своем выступлении еще год назад на Agile Rock 2018.
Почему Team Based Organization
В ту эпоху, когда камни были мягкими, а вода сладкой, можно было идеально разложить должностные обязанности по ролям, выстроить бизнес-процессы и назначить зарплаты. Продуктивность и эффективность можно было измерить в четких единицах, а удовлетворить клиента было проще-простого.
Но почти сразу начинали появляться другие конкуренты, которые делали что-то лучше, быстрее или дешевле. И тогда светлым головам менеджеров нужно было придумывать что-то еще, чтобы быть эффективнее, дешевле или качественнее. Но одна голова хорошо, две лучше, а три — это уже «Змей-горыныч». И когнитивный потенциал многих людей стал значительно важнее интуиции умного и опытного менеджера. Поэтому побеждать стали те, кто научился работать в командах, доверяя друг другу, полагаясь на интуицию бОльшего количествава людей, объединенных одной задачей.
Прошу заметить — интуиция, это вполне ощутимый и различимый ресурс. Он зависит от количества релевантного опыта в когнитивном аппарате того, кто решает задачу. Например, оценки сложности и длительности задач человеческий мозг всегда дает интуитивно. За это Daniel Kahneman премию получил. Нобелевскую.
Как это часто начинается, и как это лучше не делать
Тут нужно вспомнить о самом продаваемом фреймворке для ИТ команд — SCUM, ой, нет — SCAM, фу-ты, нет, конечно же, — SCRUM:)
Чаще всего происходило так, что босс большой компании прочел обложку знаменитой книги того самого Джеффа — Scrum: The Art of Doing Twice the Work in Half the Time. Дальше, конечно, читать не стал. И так же все понятно, чего время терять! Потом (или перед тем) послушал слащавые речи консультанта, и решил, что ему и всей его компании надо туда вместе с ним. Правда, сейчас он занят, пусть они сами пойдут первыми. На тренинги сходят и отчитаются о планах по внедрению скрама на следующие пол-года. Прямо все как в той статье про кактусы и розы.
Это же прикольно: чуть процессы поменял, и все, ты первый! Всех конкурентов победил и получил конкурентное преимущество.
Вы сирьознаа-а?
Я управлял мелкосерийной фабрикой кожгалантереи в соответствии с Lean, когда это еще не было мейнстримом когда еще не знал, как это называется. Я построил один завод по переработке гранитного щебня в Польше и затем ликвидировал его. Сделал три контакт-центра, провернул немного «мелких афер» и начинал парочку не взлетевших стартапов.
Накопленный опыт в прошлом и текущий опыт работы в качестве Agile Coach позволяют мне точно сказать, что конкурентное преимущество компания получить сможет. Но оно гораздо дороже, чем рисуют консультанты, и достигается медленнее.
Возьмем пример самоорганизованной школы, которую построил Alexander Neill.
Если кратко: уставший подросток вырос, повзрослел и создал школу-пансионат, где он не заставлял детей ходить на занятия. Безо всякого ущемления они играли, питались и отдыхали как все. Начинали ходить на уроки только тогда, когда сами этого хотели. Нормы в школе были такие, которые устанавливают сами ученики, и наказания они друг другу придумывали сами, если нарушали права и свободы других учеников. Например, не умываться можно и кричать в школе можно, но только до 21:00, чтобы малыши выспались. Чужой велик взял без разрешения? Ремонтируй свой и давай всем неделю кататься.
Но к общественному утопическому порядку и урокам они приобщались с разной скоростью. Иногда, чтобы ребенок или подросток стал самоорганизованным, прошел спираль молчания в школе (Спираль умалчивания. Канал Youtube Denys Ryzhykh) и принял негласные и гласные ценности других детей, проходило
Были случаи, когда детей, которые не могут трансформироваться, отправляли назад. Чем более жесткой была среда, в которой он до этого находился, тем больше был срок трансформации ребенка (ортодоксальная семья, церковно-приходская школа, строгие гувернеры и т. п.).
У людей в командах тоже есть такой период адаптации. В течение него они не могут физически и психологически разделять ценности Agile-манифеста и быть true cross-functional and self-organized, self-governed, self-learning, self-managing и т. д. В это же время они тоже должны получать зарплату. И ее кто-то должен им платить, представляете?!
При условии, что вы всё это выдержите, если ваш запас финансовой прочности и репутация на рынке услуг вам это позволяют, вы можете надеяться, что получите конкурентное преимущество. А ваши конкуренты — не смогут.
Преимущество выяснится по ходу работы. Просто подтвердится одна из гипотез, которые выдвинут ваши люди или вы. Но одной головой придумать сложно. Если у вас 20 людей и вам от них надо только рабочие часы, придумывайте гипотезы сами. Тогда эти 20 голов будут не задействованы в вашу пользу. Это все тот же D. Pink.
Вот как распределение мотивации (тот самый «драйв») выглядит на схеме
Схема «директивный менеджмент»:
А вот схема «Team Based Organization»:
Справедливые ожидания от Agile-трансформации
Agile-трансформация повышает производительность не повышает производительность самих команд разработки, которые трансформировались. Agile-трансформация уменьшает стоимость не уменьшает стоимость произведенных вещей, скорее наоборот — увеличивает, но позволяет раньше спохватиться, что делается что-то не так и не оптимальным образом.
Если же посмотреть на это традиционным взглядом управленца, то в самом процессе будет множество «ненужных» действий и недозагруженных людей. Это нормально. Утилизировать «ресурсы» на 100% нельзя. Доказано здесь.
Повышение прибыльности и увеличение удовлетворенности клиента достигается тем, что снизу виднее, где какой Waste (Lean IT Waste) и как его лучше обойти.
А если научились Fail Cheap Fail Fast, то наверняка благодаря усилиям команды снизу. Уж никак не за счет усилий высшего менеджмента. Скорее вопреки.
Как измерять эффект от Agile-трансформации и как ею управлять
Agile — это делай больше полезных вещей и меньше бесполезных.
Полезные — в минимальном объеме, и скорее показывай их пользователю — вдруг ты ошибся. Делать же это в данной формулировке быстрее и экономнее успеет только сама команда, если она хочет осчастливить клиента/пользователя. Практически это выражается в культуре, которую ты смог поддерживать в своей компании, что можно назвать культурой экспериментаторства. Когда у тебя не просто самоорганизованная, а самообучающаяся команда.
Красивая история описана здесь: «Что делать, если вас копирует Apple».
Обратите внимание: в этой статье разбирается история слаженной команды, ребята в которой объединены общей целью, похожей культурой и близкими ценностями. Команда относительно небольшого размера.
Так какое-же это конкурентное преимущество, где оно и в чем измеряется
Scrum.org устал от того, что все вокруг пытаются измерить эффективность когнитивной работы в часах или стори-поинтах. Наверное, один из самых значимых моментов в 2019 году стал выпуск доктрины Evidence Based Management от scrum.org для команд разработки ПО. По ссылке есть документ, расписывающий все подробно.
Для читателей статьи приведу всего пару примеров из документа:
Key Value Measure: Current Value
| ... | ... |
| Employee Satisfaction | Some form of sentiment analysis to help gauge employee engagement, energy, and enthusiasm. |
| Customer Satisfaction | Some form of sentiment analysis to help gauge customer engagement and happiness with the product. |
| Customer Usage Index | Measurement of usage, by feature, to help infer the degree to which customers find the product useful and whether actual usage meets expectations on how long users should be taking with a feature. |
Key Value Measure: Time-to-Market
| ... | ... |
| Lead Time | The amount of time from when an idea is proposed or a hypothesis is formed until a customer can benefit from that idea. This measure may vary based on customer and product. It is a contributing factor for customer satisfaction. |
| Time-to-Learn | The total time needed to sketch an idea or improvement, build it, deliver it to users, and learn from their usage. |
Key Value Measure: Ability to Innovate
| Feature Usage Index | Measurement of features in the product that are frequently used. This helps capture features that are rarely or never used. |
| Innovation Rate | The percentage of effort or cost spent on new product capabilities, divided by total product effort or cost. This provides insight into the capacity of the organization to deliver new product capabilities. |
| ... | ... |
Последняя метрика вообще прекрасна. Этот показатель галантно и экологично намекнет, когда команда under capacity или over capacity. Но без указания причины. Разбираться опять нужно в контексте.
Представляете, какой это произведет эффект? К примеру, приходит big boss, достает тапок и начинает грозно стучать по столу, но в его гневных возгласах не всем привычные формулировки вроде: «Ааа-а! Ваша эффективность стала ниже! Вы делаете меньше стори-поинтов в спринт! Немедленно мне на стол отчет с последних ретроспектив! Пусть скрам-мастера отвечают за вашу эффективность!».
Вместо этого крики могут поменяться на что-то вроде: «Ааа-а! Наши клиенты стали менее счастливыми! А ну-ка покажите мне, как быстро наши гипотезы проверяются?! А почему у нас стало меньше fails + lessons learned за спринт? Ну-ка, пусть народ напряжется и сильнее коллаборирует с аналитиками рынка и владельцами продуктов, наш Feature Usage Rate стал подозрительно низким, скоро от нас уйдет последний клиент, где тогда я вам буду брать деньги на следующие эксперименты?!»
До scrum.org это явление описал Allen Hollub в своей статье.
Представили? Я — да. В GameDev это чаще происходит. А в связке — Customer-Vendor на проектах Enterprise Solutions — почти никогда. Вернее, я пока не встречал. Может у кого-то получится при in-house разработке, если опытный Agile Coach сопровождал рост команд и руководителей.
Какое конкурентное преимущество можно ожидать
А теперь о реальном конкурентном преимуществе. Его не получают те руководители, у которых не хватает решительности и денег, чтобы довериться и оплатить экспериментаторство команд.
Как это определить и в какой момент это обеспечить
Еще во время того, как вы договариваетесь с клиентом. Вот уровни планирования, описанные в различных Agile-фреймворках:
Как правило, big boss выражает свою гипотезу на уровне Vision и принимает участие в планировании бюджета на этапе Roadmap. С этого момента цели принимают форму Carved-in-Stone. В то время, как более адаптивные конкуренты их постоянно меняют. Бюрократии там меньше или доверия больше, разбираться уже надо на месте.
Если компания любого размера может смириться с тем, что на уровне Daily, Iteration или Release возникло что-то такое, что меняет не просто Roadmap, а и сам Vision, — эта компания имеет шансы опередить конкурентов еще и за счет адаптации под собственные возможности и реалии VUCA World. В стартапах данное явление иногда приводит к такой значимой фазе, как Pivot. В Enterprise solutions это слабо возможно. Там просто OKR могут пересмотреть. Но тоже может помочь.
Как начать Agile-трансформацию
Я приготовлю две дополнительных статьи, где расскажу о подводных камнях трансформаций в командах и в больших компаниях. Начните с малого. Вот вам 2 контрольных пункта.
1. Если вы сможете с командами регулярно обрабатывать вот такие шаблоны или такие, или такие, как на рисунке ниже, то есть шанс на конструктивный диалог с руководством.
2.A. Если руководство может сформировать внятную стратегию при помощи лаконичного Lean Canvas.
2.B. Если клиент сможет с вами как с подрядчиком заключить сделку при помощи такого лаконичного Lean Procurement Canvas, то конструктивный диалог в обе стороны получит еще больше шансов.
Если вместо Value Proposition с вами сразу пытаются обсуждать функциональные требования, техническое задание и заложить это все в контракт — от этого как раз и предостерегали создатели Agile Manifesto, когда описали 3 последних постулата.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
© Agile Manifesto
Извините за Long Read — более лаконично не получилось. MVP по-другому не сложился, и Barely Sufficient-принцип здесь я не выдержал.
Буду внимательно читать комментарии и приглашаю всех к открытой дискуссии. Подписывайтесь на мои странички (LinkedIn, Facebook. Может там что-то интересненькое для себя найдете.
