Один из самых популярных вопросов у интересующихся: «Когда этот ваш Agile применять можно, а когда нет?»

Можно ли применять Agile в управлении бухгалтерским отделом? В юридической компании? Работает ли Agile в банках или в строительстве?

Agile это множество различных методик, объединённых одними и теми же принципами, описанными в манифесте.

Если посмотреть на эти принципы, становится ясно, что изначально Agile появился в разработке программного обеспечения. Это так. Но с тех пор Agile далеко вышел за пределы IT. Тем не менее, исходя из этих принципов, можно и определить границу применимости Agile. Рассмотрим некоторые их них.

Принцип: изменение требований — это нормально и приветствуется

• Важно ли это в разработке программного обеспечения?

Да, на каждом шагу! Продукты постоянно эволюционируют, взгляд заказчика на них тоже. Значит, судя пока только по этому одному принципу, методика, берущая за основу нормальность изменений, в программировани ... Читать дальше »

Скопировано с купюрами у #Jehy.

Немного о наболевшем. Есть люди, которые в общении (скажем, в скайпе) пишут тебе “привет”. И ждут потом. Могут ждать минуты, часы, дни. А суть вопроса так и не напишут, пока не ответишь. Видимо, они считают это вежливым общением.

1) Когда вы пишете “привет”, я знаю, что вы о чём-то хотите спросить. И вы не просто так здороваетесь и интересуетесь, что у меня нового. Так что всё это лирическое вступление без какого-либо наполнения по определению является мусором.

2) Вы упрямо ждёте, что я окажусь онлайн вместе с вами. А что если нет? Тогда мы потратим трое суток на обмен любезностями, прежде чем вы мне, наконец, расскажете, в чём дело?

3) Не знаю, как у вас, а со мной так здороваются в день несколько человек. В итоге, у меня полчаса на раскланивания.

Быть вежливым в электронном общении очень просто – пожалуйста, пишите сразу и своё приветствие и суть вашего вопроса. Целиком, одним сообщением. Подробно. Тогд ... Читать дальше »

Вот и закончилось внедрение Agile в строительной компании Gravion Group. Если быть более точным — в компании занимающейся инвестиционными проектами в сфере недвижимости. Работал в команде архитекторов, инженеров, конструкторов. Хотя в итоге ими дело не ограничилось. Об этом дальше.

Это был мой первый опыт применения Agile в сфере строительства. Но как набор принципов и методик Agile себя полностью оправдал. Как оказалось, ключевые проблемы в проектировании зданий — такие же как в проектировании программного обеспечения. Не поговорили вовремя с заказчиком. Неправильно расставили приоритеты. Изменения Технического Задания на каждом шагу.

Последнее было особенно неожиданно. В сфере IT люди свято уверены, что уж в строительстве-то ТЗ незыблемо. Как бы не так. На стадии проектирования постоянно изменения. Проектируешь дом на 40 квартир, а заказчик потом просит сделать их меньше, но 50, и ещё добавить детскую площадкуб и чтобы фасад был нестандартный, но чтоб всё дёшево.

Оказалось, и в строительстве надо быть гиб ... Читать дальше »

Этим летом выпала необычная работа. За внедрением Agile обратилась строительная компания. Речь шла о внедрении Agile в проектировочном отделе: архитекторы, инженеры, конструкторы.

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

• "не хватает ресурсов"
• "заказчик не знает чего хочет"
• ТЗ постоянно меняется (да-да! В строительстве, оказывается, тоже так! Не только в IT)
• сроки всё время сдвигаются

Все те проблемы, которые в IT успешно решает Agile. Поэтому за проект я взялся и вот уже два месяца мы работаем вместе.

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

 Сразу видно рисовали не программисты, а архитекторы зданий =) У которых было 5+ по черчению =)

А из кубиков для тренинга, конечно же, построили дом:

... Читать дальше »

Когда ко мне обращаются с вопросом внедрения Scrum или Kanban для удалённой разработки, географически распределённой команды или для любой другой ситуации, когда разработчики не сидят в одном офисе, я обычно отвечаю так:

Scrum и Kanban, конечно, увеличит эффективность работы, но гораздо больше увеличило бы эффективность работы просто посадить всех в одном офисе.

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

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

Заказ от SemRush поступил очень неожиданно :) Я уж думал, что летом буду отдыхать, а, оказывается, меня порекомендовал в SemRush директор AviaSales Костя Калинов, у которых я как раз накануне закончил внедрение. Рекомендация это всегда приятно, значит работу оценили.

Приехав в офис SemRush, обнаружил там 4 очень разных команды. Давно не видел такого разнообразия :) Обычно все команды в одной компании исповедуют более менее одну идеологию. А тут прям совсем разные люди, впрочем, мирно уживающиеся друг с другом.

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

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

Последние несколько лет я много времени провожу в Таиланде, иногда выезжая на заказы по внедрению Agile в России. И вот поучаствовал в мини-конференции русских It-шников тут.
Весёлый живой формат — 15-и минутные доклады о самых разных вещах.

Я рассказал об опыте удалённого управления по Agile в не-IT компании. А именно про опыт удалённого управления Квесторией.

Нарезка видео по итогам конференции.

Слайды презентации.

Год прошёл с момента окончания проекта по внедрению Scrum в AviaSales и можно подводить итоги. Проект для меня, как тренера и консультанта по Agile, был очень интересен: работать с прогрессивной, готовой к изменениям командой - одно удовольствие. Мы почти не останавливались на технических деталях, а шли сразу к цели - увеличению эффективности работы и достижению ответственности за результат.

Комплекс мероприятий включал в себя как работу с программистами по объяснению Scrum и созданию благоприятной обстановки для внедрения, так и работу с ProductOwner'ами по формированию чёткого видения и донесения его до команды. Радует, что программисты сразу поняли идею и мы с самого начала говорили о последующем переходе от Scrum к Kanban - как к более подходящему для команды процессу. И судя по отзыву у ребят получилось перейти на Kanban! Это круто! Поздравляю! С вами было очень и очень здорово работать! :)

Отзыв от CTO AviaSales, Бориса Каплуновского: 

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

В декабре в ScrumTrek поступил заказ от стартапа AviaSales.Ru. Компания занимается подбором и продажей дешевых авиабилетов. А базируются они в Таиланде на острове Пхукет, в удобной вилле, переоборудованной под офис, на берегу моря. Куда я и приехал.

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

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

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