А еще статья вызвала большой пост Алексея Пименова, в котором тоже идет интересное обсуждение. Я, пожалуй, скопирую сюда сам пост и мои ответы на мысли поста, но там много других веток.
Если есть Agile вне IT, то должен существовать Agile в IT. А его не существует! Парадокс? А вполне! Сейчас объясню.
Да, Agile родился в компаниях с сильной IT составляющей, без которой не может существовать бизнес. Но он возник для чего? Все таки практики, которые за последние 20 лет возникли - это больше к инженерной культуре. Да: возникновение этих практик спровоцировано вызовами организациям, которые бросались через использование таких вещей как Scrum, но.... не это важно!
Важно то, что Agile - это вывод на прямую коммуникацию тех "кому надо" (бизнес) и тех кто может это сделать (в нашем случае IT) ради глобальной цели: короткий TTM или TTD. И вот ради осуществления этой прямой коммуникации и приходится трансформироваться и бизнесу и производству.
А вот представьте как выглядит в глазах обывательского руководителя весь наш "Agile в IT". А выглядит это так: пусть там IT-шники что-то там у себя поделают и будет нам счастье. Вот такое поведение обычно ни к чему хорошему не приводит (пример нужен? да запросто: весь IT департамент поделился на Scrum-команды, а владельцами продуктов стали руководители отделов. Офигеть! Всем Scrum, мы теперь Agile. А по факту: ни команда ни PO не понимают реальных бизнес приоритетов. PO является лишней прослойкой между бизнесом и командой. Никакие HADI циклы не работают, чтобы создать нужный продукт) А такое можно натворить и не только в IT подразделениях. Так можно и в маркетинге устроить псевдо Agile и много где. Я на этот счет больше предпочитаю использовать термины "Производственный Agile" и "Непроизводственный Agile". Первый явно связан с созданием продуктов и процессов или их совершенствованием (не важно IT или нет: у меня были команды из маркетологов, актуариев, продавцов и юристов которые делали страховые продукты. Были команды из сейлов, клиентского сервиса, финансистов и логистов которые оптимизировали процесс работы с клиентом от продажи до отгрузки товара). А под непроизводственным Agile я понимаю использование Agile в обеспечивающих подразделениях, которые напрямую не лежат на цепочке создания ценности.
Поэтому ребята и девчонки, аккуратней в терминах: люди вас могут понять неверно и это убьет напрочь наши светлые идеи!
Мои ответы.
(1) Алексей Пименов, а помнишь лет пять назад было довольно много докладов о том, как применять Agile (тогда Scrum преимущественно был), если заказчик не готов, и люди рассказывали, как делали у себя proxy PO, который получался как firewall, изолирующий команду, а вовсе не прокси :)
Сейчас это ушло, но вообще корни в том, как люди мыслят организацию деятельности - через команды создания ценности, или через функциональные отделы, собранный в цепочку. И пока IT-проект будет выделяться из Проекта модернизации компании как отдельный, с отдельной рабочей группой, а не общей - и IT разработка будет отдельно. с четкой границей, которую не пробьешь, до ценности для потребителя - не дотянешься - независимо от применяемых методов. Сейчас понимание необходимости команд создания ценностей приходит, и цифровизация бизнеса оставляет все меньше шансов на автономность IT - так что это уходит.
(2) Продолжаю, следующая мысль. Деление Agile в IT и за пределами IT-отрасли - это деление на область. где проработаны не только процессные, но и технические (инженерные) практики,- это в IT, и область, где они не проработаны. По мере их проработки будут возникать другие отраслевые варианты Agile. Мне тут Сергей Рогачев (Sergey Rogachev) в комменте хорошую ссылку прислал на статью Evan Leybourn «Domain of Agility» на эту тему https://habrahabr.ru/company/scrumtrek/blog/320158/ ты. наверное, читал, но в комментах к посту она уместна.
(3) И третье. Про производственный и не-производственный Agile. Я тут вспомнил старую схему Минцберга "Структура в кулаке" (в докладе на встрече Agile вне IT в декабре, на AgileDays тоже говорить буду) о структуре организации. Производство и не-производство, с моей точки зрения, заметает только 2.5 сегмента из 5, а надо про все 5 говорить. Но в целом - мысль очень правильная, в эту сторону надо развивать методологию.
[ Хронологический вид ]Комментарии
Большое обсуждение на FB в группе Agile вне IT и в моем репосте. Сергей Рогачев дал ссылку на интересную перевод статьи Evan Leybourn «Domain of Agility», он различает Process Agility и Technical Agility, Примерно об этом говорю я в интервью. Автор еще выделяет Business Agility как отдельный концепт.
А еще статья вызвала большой пост Алексея Пименова, в котором тоже идет интересное обсуждение. Я, пожалуй, скопирую сюда сам пост и мои ответы на мысли поста, но там много других веток.
Если есть Agile вне IT, то должен существовать Agile в IT. А его не существует! Парадокс? А вполне! Сейчас объясню.
Да, Agile родился в компаниях с сильной IT составляющей, без которой не может существовать бизнес. Но он возник для чего? Все таки практики, которые за последние 20 лет возникли - это больше к инженерной культуре. Да: возникновение этих практик спровоцировано вызовами организациям, которые бросались через использование таких вещей как Scrum, но.... не это важно!
Важно то, что Agile - это вывод на прямую коммуникацию тех "кому надо" (бизнес) и тех кто может это сделать (в нашем случае IT) ради глобальной цели: короткий TTM или TTD. И вот ради осуществления этой прямой коммуникации и приходится трансформироваться и бизнесу и производству.
А вот представьте как выглядит в глазах обывательского руководителя весь наш "Agile в IT". А выглядит это так: пусть там IT-шники что-то там у себя поделают и будет нам счастье. Вот такое поведение обычно ни к чему хорошему не приводит (пример нужен? да запросто: весь IT департамент поделился на Scrum-команды, а владельцами продуктов стали руководители отделов. Офигеть! Всем Scrum, мы теперь Agile. А по факту: ни команда ни PO не понимают реальных бизнес приоритетов. PO является лишней прослойкой между бизнесом и командой. Никакие HADI циклы не работают, чтобы создать нужный продукт) А такое можно натворить и не только в IT подразделениях. Так можно и в маркетинге устроить псевдо Agile и много где. Я на этот счет больше предпочитаю использовать термины "Производственный Agile" и "Непроизводственный Agile". Первый явно связан с созданием продуктов и процессов или их совершенствованием (не важно IT или нет: у меня были команды из маркетологов, актуариев, продавцов и юристов которые делали страховые продукты. Были команды из сейлов, клиентского сервиса, финансистов и логистов которые оптимизировали процесс работы с клиентом от продажи до отгрузки товара). А под непроизводственным Agile я понимаю использование Agile в обеспечивающих подразделениях, которые напрямую не лежат на цепочке создания ценности.
Поэтому ребята и девчонки, аккуратней в терминах: люди вас могут понять неверно и это убьет напрочь наши светлые идеи!
Мои ответы. (1) Алексей Пименов, а помнишь лет пять назад было довольно много докладов о том, как применять Agile (тогда Scrum преимущественно был), если заказчик не готов, и люди рассказывали, как делали у себя proxy PO, который получался как firewall, изолирующий команду, а вовсе не прокси :)
Сейчас это ушло, но вообще корни в том, как люди мыслят организацию деятельности - через команды создания ценности, или через функциональные отделы, собранный в цепочку. И пока IT-проект будет выделяться из Проекта модернизации компании как отдельный, с отдельной рабочей группой, а не общей - и IT разработка будет отдельно. с четкой границей, которую не пробьешь, до ценности для потребителя - не дотянешься - независимо от применяемых методов. Сейчас понимание необходимости команд создания ценностей приходит, и цифровизация бизнеса оставляет все меньше шансов на автономность IT - так что это уходит.
(2) Продолжаю, следующая мысль. Деление Agile в IT и за пределами IT-отрасли - это деление на область. где проработаны не только процессные, но и технические (инженерные) практики,- это в IT, и область, где они не проработаны. По мере их проработки будут возникать другие отраслевые варианты Agile. Мне тут Сергей Рогачев (Sergey Rogachev) в комменте хорошую ссылку прислал на статью Evan Leybourn «Domain of Agility» на эту тему https://habrahabr.ru/company/scrumtrek/blog/320158/ ты. наверное, читал, но в комментах к посту она уместна.
(3) И третье. Про производственный и не-производственный Agile. Я тут вспомнил старую схему Минцберга "Структура в кулаке" (в докладе на встрече Agile вне IT в декабре, на AgileDays тоже говорить буду) о структуре организации. Производство и не-производство, с моей точки зрения, заметает только 2.5 сегмента из 5, а надо про все 5 говорить. Но в целом - мысль очень правильная, в эту сторону надо развивать методологию.
Войдите, чтобы комментировать.