Желтая оранжевая культуры. Лучше почитать об этом у Фредерика Лалу "Reinventing organizations".
Но в России самый распространенный вариант — организации-оборотни: красная культура, завернутая в желтую и оранжевую мантии. То есть самый худший вариант. Культура двойных стандартов. Когда вроде бы в конторе есть правила, стандарты, а в политиках прописано как люди и уважение к ним наша ценность, а на деле любые правила нарушаются руководством, из персонала, давят соки и главная парадигма "я начальник ты дурак"
Обьяснение простое. Уровень культуры другой. Если в корпоративной культуре силы и авторитарности пытаться внедрить инструмент бирюзового уровня, то в результате он либо совсем не работает, либо искажен.
Вот поэтому то надо не "внедрять" Agile, а трансформировать компанию в духе Agile. И начинать надо не с команд, а с владельца бизнеса, а потом с топ менеджмента. И вот когда они трансформировались, тогда уже и в народ запускать.
Но это всё вещи о которых в России начнут задумываться лишь через 3-5 лет. Так что пока надо только понимать природу этого феномена и практиковать стоицизм
«Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. „
На самом деле абсолютно просто. Более того, и Agile и Scrum могут применяться вообще отдельно от IT, потому что по сути это не об IT, а об управлению проектами. Точнее Scrum об управлении проектами, а Agile — вообще о любом взаимодействии людей в рамках рабочих отношений.
То есть если абстрагироваться от разработки ПО. Берём любой проект. Например строительство дома. Легко реализуемо в Scrum формате. Ваш объём работ — это ваш бэклог. Ваши будущие владельцы дома, плюс владельцы вашей компании (ваши боссы)+надзорные органы = ваши клиенты.
Ваши каменщики, электрики, сантехники, маляры — ваша кроссфункциональная команда (Если коллектив небольшой, то очень часто они вообще мастера на все руки, так что взаимозаменяемы).
Дальше вешаете КАНБАН или лучше СКРАМБАН доску и вперёд — ежедневный чекин поможет всем быть в курсе происходящего, вовремя заказывать материалы, не штукатурить стены, которые предстоит штробить и т.д.)
Все точно также можно распланировать на спринты, точно также можно воспитывать самоорганизацию в командах и т.д. Плюс применять lean production 6 сигма и другие вещи где надо.
В принципе мы точно также делаем Scrum проекты по внедрению Lean — для внедрения есть некоторый набор действий (провести интервью с руководством, напечатать раздаточную инфу, проводить семинары, обучения, практические занятия и т.д.) — все эти вещи по сути ничем не отличаются от “создать страницу, разработать фичу для сайта, подправить шапку на главной и т.д.) то есть без разницы какие действия вы производите — для Scrum это вообще пофиг.
Но правда мы кроме проектов в виде Scrum идём дальше и внедряем Agile management на уровне организации. То есть ломаем „колодцы“, создаем кроссфункциональный Скрам ов Скрамс для внедрения решений по операционным улучшениям, которые влияют на всю цепочку создания ценности компании.
Так что чем больше работаю, тем больше убеждаюсь — Agile/Scrum — это вообще не про IT. Просто IT первые взяли их на вооружение, учитывая специфические требования в скорости к этой отрасли и её свободную культуру, которая изначально склонна к такому гибкому типу взаимодействия.
Сварили общество, как лягушку в кастрюле, нагревали хололную воду постепенно, чтоб не рыпалась. И вот уже полное бесправие народа, и судебный террор — это реальность, в которой мы живем. И уже страшно становится что дальше — «право первой ночи», инквизиция и т. д.
Нет. Я про применение фреймворка SCRUM для проекта по внедрению Lean. Lean — не проектная методология, это набор инструментов, и в данном случае просто продукт проекта. А вот организовать проект по Agile/Scrum — вполне возможно. У меня просто есть определенный опыт и интересно было бы найти людей с похожим опытом. Поэтому поинтересовался
Интересная статья. А есть какие-нибудь мысли по поводу применения SCRUM для проектов в других отраслях. Например не в IT, маркетинге или финансах, а в например в производстве: добывающих отраслях, металлургии, машиностроении и т.д.
Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma? В первом приближении и там и там проекты, и там и там сложный продукт в меняющейся среде и условиях.
а выясняется это по ходу дела, потому что в голове держать всё — такого человека нет
В том то и плюс коротких итераций что выясниться это должно гораздо раньше чем при уотерфоле, и цена ошибки будет гораздо меньше.
потому что в голове держать всё — такого человека нет. Или например все таски имеют мажор/критикал приоритеты и лежат и тухнут месяцами/годами. Еще вариант когда со стороны заказчика эксперт в бизнес-области уходит, а появившиеся на его месте просят отреверсить код чтобы восстановить логику, а полноценного документа нет, только скудные наметки в трекере.
Это либо плохой бэклог, либо чек-ин чекаут делается неправильно и члены команды не знают что делает другой либо продукт оунер не делает свою работу. Ничего из этого не должно произойти в скрам-проекте, если он сделан правильно, в том то и дело.
Отдельный момент — конфликты по оценки трудозатрат с заказчиком. Тот просит сделать «мелкую но важную фигню», а ему выкатывают срок два месяца.
Опять я вижу плюс аджайл подхода. В вотерфолле он бы продавил неделю, заложил свои планы и планы компании, а потом ругаясь и матерясь два месяца терроризировал бы команду и получил бы что-то ужасного качества в итоге, а пол-команды уволилась бы в процессе. А вот если делать в реальности действительно неделю — то значит опять же надо работать над качеством команды и умением её оценивать сроки выполнения работы короткими итерациями.
В общем говоря, достоинства аджайла как раз и могут быть его же недостатками (яд/лекарство вопрос концентрации). Проблема в том, что аджайл часто внедряется как «карго-культ», когда организация внутренне не готова к нему но уже слышала что это стильно-модно-молодежно и уже все так делают.
Вот тут полностью соглашусь, внедрение в стиле «карго-культ» — это широкая практика и именно такие внедрения дают Agile плохое имя.
Да но для выдерживания сроков agile тоже хорош. Теоретически если все операции проекта так предсказуемы и идентичны, что каждому члену нужно просто садиться и делать их с достаточной быстротой без привлечения и интерактива с другими людьми и необходимости учитывать их пожелания, то да, эджайл там не нужен, но это не проект тогда а конвейер.
А в реалиях я никогда не видел, чтобы какойнибудь мало-мальски крупный проект внедрялся без многочисленных согласований, изменений требований и т.д. чтобы можно было сразу распланировать его от начала и до конца.
Понятно. Но я поэтому и спрашивал про ваш проект, потому что все мои реальные примеры не из IT я внедряю Agile в другой отрасли.
Но если говорить о моих реальных примерах сейчас, то это будет: «Разработать систему учёта и регистрации простоев», «повысить КТГ на 10%» и т.д. В общем операционная эффективность. Но в своё время был опыт работы на проектах внедрения IT-систем, и могу сказать, что мы могли бы тогда избежать многих проблем, если бы знали про agile
Допустим проект — создать рекламный сайт. Экспертно и по бенчмаркингу определяем, сколько приблизительно затраты на создание, на сколько приблизительно он увеличит траффик и объёмы продаж, считаем прибыль. Из общего дохода вычитаем сумму инвестиций, получая конечную прибыль, и делим результат на сумму инвестиций. Умножаем на 100, чтобы получить результат в процентах.
Конечно качественно. Другое дело, что понятие качественно для всех разное. В статье я имел в виду, что демонстрироваться должны базовые функции бехз маркетинговых фишечек и WOW-факторов. Профессионалам будет достаточно, а вот некоторые конечные юзеры возможно подумают, что это «недопиленные уродцы»
Желтая оранжевая культуры. Лучше почитать об этом у Фредерика Лалу "Reinventing organizations".
Но в России самый распространенный вариант — организации-оборотни: красная культура, завернутая в желтую и оранжевую мантии. То есть самый худший вариант. Культура двойных стандартов. Когда вроде бы в конторе есть правила, стандарты, а в политиках прописано как люди и уважение к ним наша ценность, а на деле любые правила нарушаются руководством, из персонала, давят соки и главная парадигма "я начальник ты дурак"
Обьяснение простое. Уровень культуры другой. Если в корпоративной культуре силы и авторитарности пытаться внедрить инструмент бирюзового уровня, то в результате он либо совсем не работает, либо искажен.
Вот поэтому то надо не "внедрять" Agile, а трансформировать компанию в духе Agile. И начинать надо не с команд, а с владельца бизнеса, а потом с топ менеджмента. И вот когда они трансформировались, тогда уже и в народ запускать.
Но это всё вещи о которых в России начнут задумываться лишь через 3-5 лет. Так что пока надо только понимать природу этого феномена и практиковать стоицизм
«Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. „
На самом деле абсолютно просто. Более того, и Agile и Scrum могут применяться вообще отдельно от IT, потому что по сути это не об IT, а об управлению проектами. Точнее Scrum об управлении проектами, а Agile — вообще о любом взаимодействии людей в рамках рабочих отношений.
То есть если абстрагироваться от разработки ПО. Берём любой проект. Например строительство дома. Легко реализуемо в Scrum формате. Ваш объём работ — это ваш бэклог. Ваши будущие владельцы дома, плюс владельцы вашей компании (ваши боссы)+надзорные органы = ваши клиенты.
Ваши каменщики, электрики, сантехники, маляры — ваша кроссфункциональная команда (Если коллектив небольшой, то очень часто они вообще мастера на все руки, так что взаимозаменяемы).
Дальше вешаете КАНБАН или лучше СКРАМБАН доску и вперёд — ежедневный чекин поможет всем быть в курсе происходящего, вовремя заказывать материалы, не штукатурить стены, которые предстоит штробить и т.д.)
Все точно также можно распланировать на спринты, точно также можно воспитывать самоорганизацию в командах и т.д. Плюс применять lean production 6 сигма и другие вещи где надо.
В принципе мы точно также делаем Scrum проекты по внедрению Lean — для внедрения есть некоторый набор действий (провести интервью с руководством, напечатать раздаточную инфу, проводить семинары, обучения, практические занятия и т.д.) — все эти вещи по сути ничем не отличаются от “создать страницу, разработать фичу для сайта, подправить шапку на главной и т.д.) то есть без разницы какие действия вы производите — для Scrum это вообще пофиг.
Но правда мы кроме проектов в виде Scrum идём дальше и внедряем Agile management на уровне организации. То есть ломаем „колодцы“, создаем кроссфункциональный Скрам ов Скрамс для внедрения решений по операционным улучшениям, которые влияют на всю цепочку создания ценности компании.
Так что чем больше работаю, тем больше убеждаюсь — Agile/Scrum — это вообще не про IT. Просто IT первые взяли их на вооружение, учитывая специфические требования в скорости к этой отрасли и её свободную культуру, которая изначально склонна к такому гибкому типу взаимодействия.
(и наверно всё-таки по переработке, заводов по добыче не существует).
Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma? В первом приближении и там и там проекты, и там и там сложный продукт в меняющейся среде и условиях.
В том то и плюс коротких итераций что выясниться это должно гораздо раньше чем при уотерфоле, и цена ошибки будет гораздо меньше.
Это либо плохой бэклог, либо чек-ин чекаут делается неправильно и члены команды не знают что делает другой либо продукт оунер не делает свою работу. Ничего из этого не должно произойти в скрам-проекте, если он сделан правильно, в том то и дело.
Опять я вижу плюс аджайл подхода. В вотерфолле он бы продавил неделю, заложил свои планы и планы компании, а потом ругаясь и матерясь два месяца терроризировал бы команду и получил бы что-то ужасного качества в итоге, а пол-команды уволилась бы в процессе. А вот если делать в реальности действительно неделю — то значит опять же надо работать над качеством команды и умением её оценивать сроки выполнения работы короткими итерациями.
Вот тут полностью соглашусь, внедрение в стиле «карго-культ» — это широкая практика и именно такие внедрения дают Agile плохое имя.
А в реалиях я никогда не видел, чтобы какойнибудь мало-мальски крупный проект внедрялся без многочисленных согласований, изменений требований и т.д. чтобы можно было сразу распланировать его от начала и до конца.
Но если говорить о моих реальных примерах сейчас, то это будет: «Разработать систему учёта и регистрации простоев», «повысить КТГ на 10%» и т.д. В общем операционная эффективность. Но в своё время был опыт работы на проектах внедрения IT-систем, и могу сказать, что мы могли бы тогда избежать многих проблем, если бы знали про agile