Обимитаторах,тлеющемМанифестеискелете
Аджайл Манифест. В 2001 году был подписан Аджайл Манифест, который был настоящим прорывом на то время для индустрии разработки программного обеспечения. Одна из четырех ценностей манифеста гласит:
Работающий продукт важнее исчерпывающей документации
Теперь это кажется очевидным, но в 2001 году стало настоящим откровением. Компании генерировали тонны ненужной документации, отчетов, которые никто не читал. Чарты и диаграммы плыли, теряли свою актуальность и не отображали реальный прогресс разработки. Прозрачность отсутствовала. Мы рапортовали о готовности проектов «на 90%», но на практике это означало, что до передачи продукта в руки конечных пользователей было очень далеко.
Прошло более 10 лет с момента подписания Манифеста, мы стали лучше и быстрее создавать продукты. Использование Скрама и других гибкие Фреймворков стало стабильным трендом. К сожалению, часто за вывеской «Аджайл» и «Скрам» находится со всем не то, что заявлено.
О вывесках и человеческой природе. Кент Бек как-то подметил, что слово Аджайл было выбрано слишком удачно. Конечно, какая компания не хочет быть гибкой? Природа людей такова, что когда нам что-то очень нравится, то мы начинаем со временем верить в то, что уже обладаем желаемыми качествами. Логика примерно следующая: для компании быть гибкой – хорошо, следовательно, нужно обязательно вписать в корпоративный слоган слово Agility.
Делать Аджайл и Быть Аджайл. За последние 5 лет у меня большой опыт работы в крупных (более 2000 сотрудников) IT компаниях на позициях Скрам Мастера, а затем и Аджайл Коуча. Все компании без исключения позиционировали себя на рынке, как гибкие. По факту же, настоящей культуры Аджайла и Скрама я не нашел нигде.
Тем ни менее, это не мешало нам ставить доски, использовать цветные стикеры, ограничивать работу в прогрессе (WIP), играть в Planning Poker, ходить на Ежедневные Скрамы. Мы гордо называли себя Аджайл Коучами, но занимались лишь внедрением отдельных практик.
Тлеющий Манифест. В итоге я должен констатировать тот факт, что оригинальный Аджайл Манифест для многих в индустрии выродился в Тлеющий Аджайл Манифест, который я привожу в русском переводе здесь:
Тлеющий Аджайл Манифест гибкой разработки программных продуктов
Мы слышали о новых путях развития программного обеспечения от платных консультантов, и мы читали отчеты Gartner. Поэтому мы нам было сказано ценить следующее:
Люди и взаимодействие важнее процессов и инструментов
а еще у нас есть обязательные процессы и инструменты, чтобы контролировать людей (мы предпочитаем термин «ресурсы»)
Работающий Продукт важнее исчерпывающей документации
до тех пор пока продукт имеет исчерпывающую документацию
Сотрудничество с заказчиком важнее согласований условий контракта
в границах строгих контрактов, конечно, и тщательного контроля за изменениями в проекте
Готовность к изменениям важнее следования первоначальному плану
в том случае, если у нас есть строгий план, как реагировать на изменения, и он неукоснительно соблюдается
То есть, не смотря на то, что утверждения слева звучат неплохо в теории, мы – большая компания и не можем себе позволить отойти от принципов справа
Инноваторы, Имитаторы, Идиоты. Уоррен Баффет пришел к замечательной формулировке жизненного цикла любой хорошей идеи:
Сначала приходят инноваторы, которые обнаруживают возможности и создают подлинную ценность. Затем приходят имитаторы, которые копируют то, что было сделано инноваторами. Иногда они улучшают оригинальную идею, но часто делают ее хуже. Последними приходят идиоты, чья жадность подрывает инновацию (Taylor, 2011).
И мне хочется задать вопрос Аджайл сообществу: существует ли опасность того, что мы позволяем окружать себя большим количеством имитаторов и идиотов?
Об инвалидах. Скрам очень прост. При соблюдении простых правил без их изменения внутри Скрам Команды возникают сложные метаморфозы, люди вынуждены менять свое поведение, что в свою очередь оптимизирует продуктивность команды и бизнес ценность продукта. Это похоже на игру жизни.
Роли, артефакты, правила и мероприятия Скрама не подлежат изменению, и хотя возможно использование только отдельных частей Скрама, конечный результат уже Скрамом не является. Скрам существует только в своей целостности и может быть контейнером для дополнительных техник, методологий и практик (Scrum Guide, 2013).
Скрам – это скелет. Сам по себе скелет не жизнеспособен, поэтому для его функционирования необходима кожа, кровь и мышцы (Kanban, TDD, Planning Poker и любые другие практики). Можно регулярно посещать спорт зал и становиться сильнее, покупать аминокислоты, креатин и заедать это большими порциями протеина и гейнеров. Тем ни менее, скелет останется неизменным.
Можно, конечно, отрезать ноющую ногу и избавиться временно от проблемы, но приобрести навсегда другую и, в конце концов, остаться инвалидом. Вы этого хотите? Тогда мой совет – не пытайтесь стать имитатором, меняя Скрам.
Соблюдайте ценности и принципы Аджайл манифеста, становитесь агентом изменений, бросайте вызов закоренелому в ваших компаниях. Находите слонов в комнате (очевидная и неприятная правда, которую все пытаются не замечать) и активно боритесь с ними. Удачи всем нам на тернистом, но благородном пути изменений!
Узнай, насколько ты гугловый
Чтобы работать в Google, нужно обладать гугловостью. Это способность нестандартно мыслить и быть полезным для других. Также гугловость показывает, как хорошо вы ладите с людьми. Пройдите наш тест и узнайте, есть ли в вас гугловость и сможете ли вы устроиться в компанию мечты. Для ответа просто нажимайте на один из вариантов. Фото: Kazuhisa Otsubo, Zombieite, Kevin JarrettПочему это важно знать
Потому что бирюзовые компании сейчас востребованы на рынке. Они быстрее всех реагируют на нужды клиентов и создают привлекательные рабочие места для сотрудников.Кто придумал
Фредерик Лалу в книге «Открывая организации будущего» описал пять типов организаций: красные, оранжевые, янтарные, зелёные, бирюзовые.Признаки бирюзовой организации
- Самоуправление, нет иерархии и системы контроля.
- Сотрудники сами решают, над чем работать, и несут ответственность за свой выбор.
- Все сотрудники стремятся к одной цели.
- Каждый работает с максимальной отдачей, потому что ему это нравится, работа — это продолжение самого человека.
Марк, книга действительно не очень раскрученная, но она великолепна. Единственный минус - нет возможности купить в электронном формате.
Отлично подмечено. Именно этого мы и хотим - создание условий для появления натуральных лидеров, которые будут вести за собой людей, но не потому, что у кого-то на голове корона. И "неявная" иерархия по факту будет и это, по моему мнению, хорошо. Но для того, чтобы это случилось, необходим "клей", который свяжет определенными обязательствами людей, иначе можно запросто уйти в хаос. В книге все подробно описано.
Скрам именно поэтому плоский фреймворк без иерархии. И недаром все члены команды разработки могут именоваться только "разработчик". Титулы строго запрещены и исключений этому правилу нет - пишется в Скрам Гайде. Причина та же - хотим, чтобы появились внутри фреймворка натуральные лидеры, за которыми будут идти люди.
Илья, спасибо! Отдельно - за Beyond Empowerment - не такая известная в широких кругах книга.
Возможно, этот момент там описывается, но как обстоят дела с естественным лидерством в "плоских" системах? От этого ведь никуда не уйти. Это природа человека и лидеры всегда есть и будут. И эти лидеры будут создавать "неявную" иерархию. Да, она будет не менеджерская, но она будет. Разве это плохо? Какое твое мнение?
Спасибо!
Марк,
Марк, позволю не согласиться. Некоторые научились обходиться без упомянутых костылей. Мне кажется в моем первом посте я ответил на этот вопрос и привел пример компании Morning Star, которая эта сделала. Изначально это было классическая иерархическая организация. Подробно о процессе перехода можно прочитать в замечательной книге Beyond Empowerment. Можно еще посмотреть на компанию Valve. Если примеров мало - готов привести еще.
Если это основная цель и менеджмент принимает решения исходя из этого принципа, то я сразу должен сказать, что такая компания - не жилец в принципе. Работать в такой компании я бы не хотел никогда и не буду никому советовать.
Я ОК с этим :) Каждый делает свой выбор. И думаю, поэтому в том числе у Аджайл Коучей в ближайшие 10 лет будет много работы.
Интернет просто пестрит примерами подобных успешных преобразований.
Когда они будут стоять на пороге банкротства, то, боюсь, что они уже не смогут перескочить на Аджайл. Это типичный пример сваливания из Очевидного в Хаосный домен. Компании думают "пересидеть" и подождать "а вдруг эта вся шумиха с Аджайл и Скрамом" закончится и будет как раньше в 90-х. Нет, скорость изменений и турбулентность технологий, рынка только возрастает, причем нелинейно. С каждым годом негибким компаниям будет все тяжелее удерживать свои позиции. Поэтому те, кто не почивают на лаврах и не только считают сегодняшний ROI, но думают на переспективу, могут успеть вскочить в отъезжающий поезд,
С замечанием про Cynefin согласен.
По менеджменту. Безусловно, это процессные костыли, которые своими действиями не добавляют ценность продукту, но без которых мы пока не научились обходиться (не хотел никого обидеть).
Илья, может быть ты слышал/видел опыт эволюционного перехода компании из иерархической структуры в плоскую? Зачастую, вероятность выживания 30% неприемлема для компаний, только если они не стоят на грани банкротства, когда выбора уже нет.
По поводу тлеющего манифеста и лозунгов "Нам нужен Agile". По твоему опыту, чем обычно обосновывали менеджеры подобные заявления? Я встречал три основных причины:
1. Желание следовать за трендами
2. Интуиция менеджмента
3. Желание увеличить прибыль сейчас и всегда
Не стоит забывать, что одна из основных целей компании - генерация прибыли. Даже, если это не является целью, то величина прибыли все равно остается отличным показателем того, насколько правильные действия компания совершает. По идее, какими бы красивыми и мотивирующими не были "agile-преобразования", если при этом прибыль падает на долгосрочную перспективу, то это не то, что нам нужно. Встречались ли тебе примеры экономических обоснований подобных преобразований, когда компании измеряли фактическую выручку в точке А, а потом в точке B и получали инкремент выше ожидаемого?
Марк, спасибо за ваш комментарий.
Рецептов нет и быть не может, потому что мы находимся в Запутанном Домене (модель Кеневин), а вот идеи есть. Сейчас идет много разговоров о "плоских" организациях и структурах. Мне кажется, нам нужно смотреть в этом направлении, тем более, что это прекрасно ложиться на Запутанный Домен, уходить от иерархических структур, спускать принятие решений как можно ниже в организациях и т.д. Рекомендую замечательную статью Let's Fire All Managers о том, почему иерархии вызывают большое количество проблем. Плоские компании уже есть и это не может не радовать )) Можно воспользоваться опытом компании Morning Star (кстати, не из сферы АйТи). В компании, где 1000 сотрудников нет НИ ОДНОГО менеджера. Это хорошие новости. Плохие заключаются в том, что по оценке Джона Коттера подобные изменения переживут только 30% компаний. Увы.
Относительно фреймворков и жесткости. Да, нужен минимальный и прочный скелет (как у терминатора в первой части). Все что сверху него - ваше, ваш собственный процесс, который вы сами "подкручиваете" под вашу организационную культуру и т.д. Если убрать минимальный каркас, то наступит хаос. Необходимы минимальные правила, внутри которых будут "возникать" новые практики и поведения людей. Скрам - это минимальный слуга-процесс, который помогает вам найти свой собственный процесс.
Илья, спасибо за статью.
У тебя есть рецепты/идеи, как в компании с тысячами сотрудников обойтись без жестких процессов и инструментов, но при этом сохранить прозрачность и управляемость? И как в идеале это могло бы выглядеть?
И в продолжение твоего поста. Меня всегда смущало, что Scrum называют фреймворком, и твердят, что Kanban - это метод эволюционных изменений. Да, так и есть. НО. Разве итеративность, роли, митинги и визуализация - это не жесткий процесс и правила работы (даже если они всем нравится)?