Куда двигается Targetprocess / Компания и продукт

Куда двигается Targetprocess / Компания и продукт


Меня частенько спрашивают, что будет с нашей компаний в недалеком и далеком будущем. Честный ответ — я не знаю. Но у меня есть представление, куда мы идем и каким путем мы должны двигаться, так что будет странно не рассказать это всем. Ниже будет много конкретных решений довольно абстрактных проблем. Это мои личные мысли, которые, очевидно, не все разделяют 🙂

Компания

Проблема большинства современных компаний в том, что они созданы для единственной цели — заставлять людей работать (в лучшем случае, давать им возможность работать). Любому руководителю я рекомендую познакомиться с Russell L. Ackoff, который часто говорит прекрасное:

Perhaps the most costly disassembly in which our culture has been engaged is disaggregation of life itself into work, play, learning and inspiration. Each of these aspects of life has been separated from the others by creating institution for engaging in only one at a time, excluding the other three as much as possible. Business are designed for work, not play, learning, or inspiration. • Russell L. Ackoff

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

Обучение

Обычно считается, что люди должны учиться сами. Конечно, это так, но компания может им помочь. Учиться нужно всю жизнь без перерывов. Легко достигнуть каких-то высот и сказать себе “я знаю уже достаточно много, можно переключиться на детективы Марининой и спокойно работать по накатанной дорожке”. Так начинается путь к ДТП (диван, телевизор, пиво по вечерам). Так заканчиваются мечты.

“Единственный способ выжить — это постоянно ставить перед собой новые задачи” • Персиваль Бейли

Для обучения важно делать несколько вещей: читать, смотреть, слушать, говорить, писать и делать.

Если чуть подробнее, то:

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

Компания может помочь во всем этом. Давайте посмотрим, как именно:

  • Покупать любые книги по заявке из любых источников; вручить каждому сотруднику Kindle с годовой подпиской;
  • Организовывать семинары и тренинги; оплачивать хорошие конференции;
  • Создавать зоны, где люди неизбежно пересекаются и беседуют (совместные обеды); приглашать экспертов для Q&A сессий; организовывать митапы;
  • Устраивать внутренние конференции, где люди делают презентации друг другу; стимулировать людей выступать на внешних конференциях, выделяя для этого время;
  • Уговаривать писать блог посты и статьи; лестью и обманом привлечь к написанию книги;
  • Предоставлять 10–20% времени на собственные проекты; организовывать хакатоны; давать возможность стартовать новые бизнес-юниты;

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

Вдохновение

Вдохновлять людей очень сложно. Может быть, это вообще самое сложное в работе любого руководителя. И самому руководителю очень сложно понять, насколько хорошо он это умеет делать. Я лично думаю, что не очень умею. Более того, момент вдохновения сильно размыт.

Потолок Сикстинской капеллы. На картинке, может, и ничего особенного, но живьем неплохо.

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

Для вдохновения людей могут работать (или не работать) следующие вещи:

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

Компания должна давать возможность и помогать сотрудникам найти то, отчего их прёт. Если вдруг окажется, что человеку захотелось стать художником вместо программиста — это же прекрасно, пусть становится. Вместо среднего программиста, возможно, человечество получит гениального художника.

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

Культура доверия в компании потихоньку возвращает веру в себя, поощряя эксперименты и ошибки, исправляя то, что сломали в человеке раньше. Со временем некоторые люди ярко раскрываются и обретают новые источники вдохновения.

Я считаю, что компания должна в идеале:

  • оплачивать посещение ведущих конференций в разных странах
  • предоставлять раз в несколько лет длительный оплачиваемый отпуск на 2–3 месяца
  • выделять 10–20% времени на свои проекты
  • поощрять и спонсировать хобби и увлечения людей, организовывать кружки по интересам (рисование, спорт, whatever)

Свобода и доверие

В идеальной компании человек может делать то, что хочет без всякого контроля со стороны руководства. Руководство доверяет сотрудникам и надеется, что они будут тратить свое время на благо компании и общей цели. Главная идея — объединить людей, которым нравится работать вместе для достижения единой цели. Практически невозможно собрать 100+ человек с единой целью вместе, но крайне важно, чтобы была критическая масса таких людей. Я бы сказал, что 20–30% достаточно.

В последнее время намечается движение в сторону демократизации компаний. Фундаментально человечество пока не придумало ничего лучше для управления государством, чем демократия. К сожалению, все эти сдвиги происходят с большим скрипом. Рядовые сотрудники не привыкли участвовать в управленческих решениях, не умеют и боятся это делать, и не всегда глубоко понимают домен. Я вижу две главные проблемы, которые нужно решать:

  1. Погружение сотрудников в контекст (доменная область, теория принятия решений, управление процессами)
  2. Создание культуры доверия и механизмов принятия решений

Возьмем программиста в нашей компании и представим, что ему никто не говорит, что делать. Как ему решить, какую задачу взять? Какая проблема важна для клиентов, а какая — нет? Внезапная свобода выбора не приведет к хорошим последствиям. Оказывается, нужно погрузиться в домен управления проектами, разобраться с процессами типа Scrum, Kanban, SAFe, понять, какие недостатки есть в Targetprocess, посмотреть запросы пользователей, посмотреть другие похожие продукты, изучить рынок и так далее. Без хороших доменных знаний просто нереально требовать от разработчика хороших решений и хорошего выбора. Свобода выбора задачи в контексте незнания домена просто вредна.

Надо понимать, что многие разработчики сознательно не хотят погружаться в домен. Им интересно решать технические проблемы, а не разбираться в управлении проектами. Как с этим быть?

Мне кажется, хорошее решение — создание кластеров с четким фокусом на определенный под-домен. Кластер может состоять из 6–50 человек, среди которых должны быть все роли: сейлс, разработчики, тестировщики, дизайнеры, специалисты поддержки. Тогда свободой выбора обладает сам кластер, а не отдельный человек в нем. И важно иметь в каждом кластере компетентное ядро из 5+ человек, которому реально интересен этот домен.

Может ли такое ядро состоять из одного человека? В традиционных компаниях так и есть. Иногда это работает, но часто может превращаться в чистую диктатуру, когда никто не может оспорить решение лидера в силу отсутствия компетенции. Лидер может обрасти излишней самоуверенностью, что частенько ведет компанию на кладбище.

Второй важный момент — культура компании. В любом случае, все начинается с руководства. Свобода невозможна без доверия, нужно минимизировать контроль. Нельзя все менять резко, нужны этапы.

1 этап. Отмена учета времени, более гибкий рабочий график, отсутствие или хотя бы минимизация овертаймов и дедлайнов, отсутствие учета больничных, участие в выборе задач.

2 этап. Свободный рабочий график, свободные отпуска, возможность работать из любой точки Земли, полная свобода выбора задач.

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

Свобода налагает ответственность и требует понимания контекста. Пока существуют серьезные барьеры в головах, которые мешают компаниям изменять базовые принципы и модели управления. Контроль и авторитаризм все еще преобладают.

Работа

Компании никогда не создаются с целью “обеспечить обучение и вдохновение сотрудников, дать им свободу и независимость”. Обычно цели другие — либо создать что-то новое и полезное, либо просто заработать денег. Для достижения таких целей надо работать, так что работа (сюрприз!) является самым важным в компании. Для меня лично важны следующие подходы к работе:

  1. Работа должна нравиться. Человек должен работать с удовольствием, перемежая сложные задачи на грани своих способностей с более простыми и рутинными задачами. Компания должна сделать все возможное, чтобы интересы человека совпадали с задачами компании. Если это невозможно—есть два выхода: расстаться с человеком или дать ему возможность запустить что-то свое.
  2. Работа должна справедливо оплачиваться. Что это значит? С одной стороны, компании нет смысла переплачивать сотруднику, если рынок труда имеет определенный размер зарплаты. С другой — у компании есть желание избавить человека от мыслей о дополнительных источниках дохода. Поэтому в целом зарплата должна быть немного выше рыночной и нужен механизм распределения части прибыли между всеми сотрудниками.
  3. Карьерный рост не должен быть привязан к зарплате. Если в компании в целом отсутствует иерархия, меняться может только круг обязанностей, продуктивность и экспертиза, вот это и должно оцениваться.

При выполнении этих условий, человек будет работать достаточно хорошо. Но периодически все люди теряют мотивацию. Мне кажется, это бывает у всех без исключения. Как раз для этого и нужны вдохновляющие вещи. Стало скучно, поехал на конференцию, вернулся с классными идеями. Стало совсем скучно, поехал в Австралию на 2 месяца, вернулся с желанием улучшить все вокруг себя. И если ты после поездки решил изменить свою жизнь и стартовать свое дело, либо сменить род деятельности—это прекрасно.

Пока у нас в компании с практиками вдохновения не особенно хорошо, так что некоторые попадают в тепличные условия привычки и начинают плыть по течению, или даже стоять в заводи. Это нужно исправлять.

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

В компании должна быть гармония, которая позволяет людям прожить интересную жизнь, достичь высот профессионализма и наполнить существование смыслом.

Размер и структура

На текущий момент наша компания состоит из 100 человек. Мы хотим сделать классную платформу для управления работой, для этого по самым скромным прикидкам нужно человек 200–300. Дальше возможен рост и до 1000+ человек, если платформа окажется хорошей и на базе нее можно будет делать решения в разных областях.

Рост компании неизбежно влечет структурные изменения. Мне нравится вот такая схема:


Что изменится, когда в компании будет 200+ человек? Кросс-функциональные команды будут объединены в доменные кластеры, которые будут развивать направления платформы. В некоторых кластерах будет около 10 человек, а в других может быть и до 30. Примерный список кластеров такой (но можно и другое разбиение придумать):

  • Visualization and BI — how to make visual and smart
  • Integration — how to integrate into company ecosystem
  • Solution Units (PPM, QA, Help Desk, Kanban, SAFe)
  • Design — how to make usable and simple
  • Infrastructure and Performance — how to make things fast
  • Communication — how to share and exchange information
  • Domain Core — how to make flexible and configurable
  • Mobile

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

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

Как же будут формироваться новые кластеры и закрываться ненужные существующие? Тут есть много вариантов, которые в целом завязаны на общую стратегию продукта. Это может решать один человек (CEO/CTO), экспертный совет из ключевых людей из разных кластеров, либо вся компания на общем собрании

звучит странно, но может работать примерно так. У кого-то возникает идея, что нужно стартовать новый кластер. Все собираются и если есть достаточно заинтересованных людей, то кластер формируется и начинает работать над новой темой. Если кластер чувствует, что задачи у него стали какие-то бесполезные, то он может расформироваться, раскидав людей по другим кластерам, либо заняться новой темой.

Руководители

Все чаще делаются попытки создавать компании без менеджеров. Главный вопрос — зачем?

Ну ответ довольно прост: если компания без менеджеров может работать хотя бы так же успешно, как компания с привычной иерархией, то можно иметь на 20–30% меньше людей и создавать те же штуки, что и раньше.

Второй момент — ответственность за свою работу. Вот есть менеджеры, значит всю ответственность можно грузить на них. Они виноваты в том, что я работаю по 60 часов в неделю. Они виноваты в том, что у меня не растет зарплата. Они виноваты в том, что компания работает в целом хреново. Когда вся ответственность переносится на самого человека, становится сложнее сваливать свои проблемы на других, приходится разбираться в них самому.

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

  • Наем и увольнение. Доменный кластер сам нанимает себе людей и увольняет тоже сам. Собеседования программистов должны проводить сами программисты (трех обычно достаточно). С увольнением немного сложнее. Тут может помочь механизм peer review и командные ретроспективы. Но увольнение всегда тяжелый и неприятный процесс, я пока не знаю хорошего решения.
  • Зарплата. Я думаю, в компании должен присутствовать profit-sharing и прозрачные механизмы установления зарплаты. Есть примеры Buffer и FogCreek, где зарплаты прозрачны и всем известны. Неясно пока, насколько все это работает в культурном контексте Беларуси, но в целом должна быть унификация и прозрачность. То есть процесс заменяет индивидуальное решение менеджера.
  • Разрешение конфликтов. Наверное, самое сложное для самой команды. Очень нелегко бывает решать конфликт, когда люди равноправны и ни у кого нет последнего слова. У нас в компании пока этим занимаются руководители. В целом могут работать ретроспективы и привлечение третьей стороны. Есть примеры компаний, где конфликты решаются без руководителей.
  • Менторинг. Тут все довольно просто — опытные сотрудники могут быть хорошими менторами. Могут и не быть, но какой-то нужный процент таких людей обычно имеется. Так что в целом программистам в менторы нужны просто более хорошие программисты.
  • Улучшение процессов. В целом, сотрудники сами должны улучшать свои процессы. На первых этапах им нужна помощь в методиках и практиках, но после пары лет все работает уже само. У нас с этим стало гораздо лучше в последнее время.
  • Видение и стратегия. Еще один сложный вопрос. Как мне кажется, обычно видением обладает один человек, а не группа менеджеров. Поэтому теоретически в компании может быть всего один человек, который задает стратегию развития (CEO или CTO) и убедительно доказывает всем, что стратегия верная. Эту роль может играть и группа экспертов. Другой интересный вопрос, а может ли видение формироваться эмерджентно, как результат независимой работы нескольких кластеров? Я думаю — может. Именно по этому пути шла эволюция живых организмов. Почему бы и компании не следовать таким путем?

Люди vs. Продукт

Компания начинается с людей или с продукта? На первом этапе все же обычно с продукта. Люди, которые работают на первых этапах, посвящают себя одному продукту. Постепенно компания растет в размерах, начинают появляться идеи других продуктов, и на этом этапе возрастает значение культуры и людей. Вообще формирование культуры происходит не сразу, а через несколько лет после основания компании. И если этот момент упустить, то потом изменить базовые принципы компании будет невероятно сложно. Я с трудом могу себе представить, как изменить культуру и развернуть компанию, где работает 1000 человек. Это может привести к массовым увольнениям, серьезным потерям продуктивности и даже к гибели компании.

Мне кажется, что в нашей компании заложена хорошая культура. Возможно, наши несколько новых продуктов пока не пошли, но у нас есть все шансы, что такой командой мы уже способны сделать новые клёвые продукты.

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

Когда в компании работает несколько сотен человек и основной продукт становится достаточно зрелым, нужно развивать экосистему внутренних стартапов.

Я вижу, что со временем компания превращается во фреймворк, который поддерживает инновации и поощряет запуск новых продуктов в силу своих финансовых возможностей. Таким образом можно обеспечить долгосрочное выживание компании и распространение её культуры на самые разные области.

И невозможно предсказать, в каком направлении будет развиваться этот живой организм через 10 лет.

Управление работой. Как меняется мир.

Не секрет, что мир ускоряется, изменяясь все быстрее. Меняются технологии, инструменты, задачи, специальности и люди. Основные тренды, касающиеся Targetprocess, такие:

  1. Скорость обмена информацией возрастает. Медленные каналы заменяются на быстрые (Slack vs. Email). Люди хотят получать важную информацию мгновенно. С другой стороны, растет информационная нагрузка и становится сложно контролировать все потоки.
  2. Экспоненциальный рост данных порождает проблемы их обработки и извлечения полезной информации. Это касается всех рынков без исключения. BigData, Visualization, Business Intelligence входят во все рынки.
  3. Изменяются подходы к организации труда и быстро видоизменяются рабочие процессы. Scrum, Kanban, SAFe, Holacracy, Lean, Teal Organizations. Традиционные методики становятся все менее релевантными.
  4. Инструменты становятся более интеллектуальными, автоматизируя многие действия и стирая из экономики некоторые специальности. AI выходит на заметные роли практически во всех рынках. Простой микс AI+Domain скоро будет работать везде.
  5. Сложность проектов возрастает. Распределённость, тысячи людей, быстро меняющие технологии — все это усложняет управление проектами. Кажется, что это можно решить через разбиение больших проектов на маленькие и трансформацию структуры компаний.

Продукт/ы

Любой продукт, претендующий на решение проблем управления проектами ближайшего будущего, должен обладать следующими свойствами:

  • Гибкость. Подстройка под многообразие рабочих процессов и возможность идти в ногу с изменениями процессов.
  • Управление информационными потоками. Использование всех нужных каналов коммуникации, которые есть в компании, для быстрого доступа к нужной информации.
  • Понимание. Работа с данными и визуализация информации.
  • Автоматизация рабочих процессов, снятие нагрузки с людей.
  • Предсказание и экспертная оценка. Обнаружение проблем, предсказание сроков, советы по улучшению процессов.

Рабочий процесс удобно представлять классическим циклом Деминга (PDCA)

PDCA цикл с ключевыми аспектами

Если посмотреть на все современные продукты управления работой, то мы получим примерно такую картину (Targetprocess — не исключение):

Зеленым выделено функциональное покрытие фаз работы современными инструментами ALM

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

Интересно пройтись по ключевым фазам работы и посмотреть, что мы имеем сейчас и что должно быть в идеале.

PLAN

  • сейчас / в целом сейчас достаточно хорошо можно добавить работу и планировать её.
  • будущее / планирование на всех уровнях, анализ планов и предсказания сроков, импорт работы из всех систем.

DO

  • сейчас / очень мало автоматизации работы, очень слабая нотификация и довольно слабая интеграция в информационные потоки компании.
  • будущее / полная автоматизация рабочих процессов. Человек должен фокусироваться на value-added вещах, а все прочее должно происходить по возможности автоматически. Например, когда мы делаем юзер стори, работа над ней требует взаимодействия с GitHub, Build Board / Jenkins, Slack, Help Desk, IDE (Visual Studio), Targetprocess, Google Docs, Dropbox. Определенные события могут запускать цепочки действий, экономя время людей (Zapier выглядит неплохим шагом в эту сторону).
  • пример / на закрытие юзер стори посылается сообщение в Slack, закрывается реквест и нотифицируются реквестеры, удаляется бранч в гитхабе, обновляется change log.

CHECK

  • сейчас / достаточно слабые отчеты.
  • будущее / возможность строить отчеты произвольной сложности по всем имеющимся данным, гибкая связка визуальных представлений и возможность data exploration, автоматическое обнаружение трендов и нотификация о проблемах.

ACT

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

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

  • Process mapping and improvement software (Targetprocess)
  • Information visualization software (VizyDrop)
  • Work automation software
  • Communication automation software
  • Work intelligence software

Тесная интеграция продуктов позволит заходить в компании с самых разных сторон (подобную стратегию успешно использует Atlassian, но с другим набором продуктов). Наша ошибка была в том, что мы изначально не думали о тесной интеграции Targetprocess и VizyDrop. Правда, мы все равно пришли к этой идее и начали её воплощать.

Если мы пойдем по пути многих продуктов, то кластеры, описанные выше, будут просто заниматься отдельными продуктами.

Сервисный подход

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

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


Если кратко, то в следующие 2–3 года нам предстоит решать следующие задачи:

  • Разработка гибкой доменной модели, которая позволит создавать свои сущности, связи между ними и бизнес-правила.
  • Замена (эволюционная либо революционная) всего серверного слоя.
  • Разработка единого центра сообщений.
  • Унификация UI компонентов и разработка новых (mind map, например).
  • Разработка новой среды для интеграции и реализации своих приложений (apps).

Резюме

И компания, и продукт двигаются к большей гибкости и свободе. Я внутренне верю в то, что структура компании серьезно влияет на архитектуру продукта, поэтому нужно начинать с нее, если мы хотим создать гибкий инструмент.

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

Agile is Poisonous

I don’t believe in agile development anymore.

Our company applied agile practices from day one. We’ve started agile usage in 2006. We tried almost everything: Extreme Programming, Scrum, Kanban and many many small practices. Did it stick? Hell no. Let’s review the lessons.

Daily Meetings

They are just worthless. We used to gather together at 11 am in a single room and report what was completed, what is not, whether there are some blockers. Well, when there are about 30 people in a room these meetings are not fun. They took up to 10 minutes usually, but sometimes they took as long as 15 minutes (I think this duration just can’t be tolerated). After the meeting, people go and grab coffee, chat about problems, chat about ideas… These useless activities distract people and they spend less time on coding. 

We’ve replaced daily meetings with a weekly status reports sending via email. The format is very simple with just 7 questions like “Please, enumerate all tasks you’ve completed last week” and “How you estimate your personal productivity on a scale from 1 (low) to 10 (exceptional)”. We collect all emails, process them and have a real stats per person, per week, per project, etc. Really cool!

Iterations

We tried 1 week and 2 weeks iterations. Neither worked out. With short iterations there was a constant pressure to get shit done and technical debt accumulated like a huge garbage heap. It is impossible to squeeze a good solution into a short timeframe. There’re so many meetings like iteration planning, planning poker sessions, iteration demo, iteration retrospective… These meetings are killing productivity, you know. 

QA were struggling with short iterations as well. It is impossible to test a user story thoroughly in few days. We tried mini-waterfall in a single iteration — didn’t work, testing phase started just 2 days till the end of the iteration with miserable outcome. We tried to write many unit tests and acceptance tests — didn’t help, since requirements were changing so rapidly. We tried to force developers run manual tests… Well, we lost some very cool developers as a result and removed this practice.

The last nail in the coffin was a loss of a Scrum Master. He fed up with constant rants and got back to coding. He refused to play a Scrum Master role. Without a Scrum Master everything was doomed. Developers reverted to hack-and-fix mode, QA reverted to post-bugs-and-forget mode. Chaos replaced everything. Then we decided to try Kanban.

Kanban

We draw a very cool board with 23 states and placed everything into it. It looked awesome. We used color coding, we used real photos and some clever rules. For example, when a user story stayed too long in some state, we stick some funny blame words above the assigned person’s photo (like “stupid snail” or “you’ll never complete this task, hahaha!”). This really motivates to get shit done faster, you know. 

With Kanban you have a luxury to implement feature as slowly as needed. No pressure at all. Well, we didn’t like the overall velocity though and decided to bring deadlines back. Deadlines were set by top management.  All features started before the deadline should be completed and released. It lead to quite a few games between developers and managers: developers resisted to take new features when deadline was close, managers tried to put as many features as possible before the deadline. Sometimes developers had to work 100 hours per week to make a release. And that is NOT a joke! 

We tried to put limits in states and review the flow (23 states are too many). It helped a little, but managers decided that limits restrict them and removed the limit from the In Progress state. A month later everything was In Progress. 

So Kanban didn’t help us as well. However, we learnt that visualization is good and tried to apply it everywhere. We’ve tried various visualization techniques to increase transparency and productivity. For example, we tried to visualize builds statuses, work progress, future plans and roadmaps — without any success.

Here are the things that are really helpful:

Wall of Blame

We had a nice and visual “Wall of Blame”. Developers with the worst individual velocity for the last month were mentioned in a Dilbert-like comic strips. It was updated every 1st Friday of the month and this day even got a special name in our company: ”Blame Day”. People that appeared on a Wall of Blame were no rights to defend themselves in a Nerf Battle this day. Oh, these days were so funny!

Wall of Heroes

This board was right opposite the Wall of Blame. Naturally, top coders and top performers occupied this board. Their photos were very professional (we hired a good photographer to make them). The photos were in gold frames with engraved titles like “Jonny Summer. Top Lead Developer. March 2012”. Well, some photos required a serious makeup, it is hard to look good after a 100 hours work-week.

Curses Chart

We invented Curses Chart to measure fuck ups in projects. Every room has a recording device. We record everything. Speech analyzing software is used to extract curses from all records. These records are accumulated and a day-by-day chart shows how many curses there were. This chart is displayed on a large TV in the kitchen. Also it rotates recent exceptional curses. We found out that the correlation between curses and fuck ups is perfect.

Pair Programming

We tried to enforce pair programming and decide how good it is. Did it work? Nope. People were constantly arguing about things, trying to find the best solution. In the end they we reluctant to talk to each other at all. There was a case when a lead developer hit his teammate with a Microsoft keyboard and broke his nose. After this incident we replaced all Microsoft keyboards with Logitech keyboards (with soft keys) and banned pair programming practice forever. Now people can’t talk near a workstation, they have to walk into the meeting room and talk there, sitting in soft chairs.

We tried many more other practices, but this post is already too long. I’ll post more exactly a year later.

UPD: Hacker News Discussion

UPD: OK, it was 1st April post. Truth is here.

You and Your Research

Joe Armstrong, creator of Erlang, mentioned  Richard W. Hamming’s talk “You and Your Research” in his interview. I read it today. Well, it is great. So many gems that can be applied to software development easily. You should read it.

Here are several cool quotes. Some of them are quite long, but I believe they will give right feeling about the speech.

——

Courage

One of the characteristics of successful scientists is having courage. Once you get your courage up and believe that you can do important problems, then you can. If you think you can’t, almost surely you are not going to. 

Age

Most mathematicians, theoretical physicists, and astrophysicists do what we consider their best work when they are young. It is not that they don’t do good work in their old age but what we value most is often what they did early. On the other hand, in music, politics and literature, often what we consider their best work was done late. I don’t know how whatever field you are in fits this scale, but age has some effect.

Drive

You observe that most great scientists have tremendous drive. I worked for ten years with John Tukey at Bell Labs. He had tremendous drive. One day about three or four years after I joined, I discovered that John Tukey was slightly younger than I was. John was a genius and I clearly was not. Well I went storming into Bode’s office and said, “How can anybody my age know as much as John Tukey does?” He leaned back in his chair, put his hands behind his head, grinned slightly, and said, “You would be surprised Hamming, how much you would know if you worked as hard as he did that many years.” I simply slunk out of the office!

Given two people with exactly the same ability, the one person who manages day in and day out to get in one more hour of thinking will be tremendously more productive over a lifetime.

The misapplication of effort is a very serious matter. Just hard work is not enough – it must be applied sensibly.

Commitment

It comes down to an emotional commitment. Most great scientists are completely committed to their problem. Those who don’t become committed seldom produce outstanding, first-class work.

If you are deeply immersed and committed to a topic, day after day after day, your subconscious has nothing to do but work on your problem. And so you wake up one morning, or on some afternoon, and there’s the answer.

Problems

If you want to do great work, you clearly must work on important problems, and you should have an idea.

Most great scientists know many important problems. They have something between 10 and 20 important problems for which they are looking for an attack. 

By changing a problem slightly you can often do great work rather than merely good work. 

Open/Closed Doors

Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don’t know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, “The closed door is symbolic of a closed mind.” I don’t know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing – not much, but enough that they miss fame.

Selling

There are three things you have to do in selling. You have to learn to write clearly and well so that people will read it, you must learn to give reasonably formal talks, and you also must learn to give informal talks.

Educate your boss 

Now you might tell me you haven’t got control over what you have to work on. Well, when you first begin, you may not. But once you’re moderately successful, there are more people asking for results than you can deliver and you have some power of choice, but not completely. I’ll tell you a story about that, and it bears on the subject of educating your boss. I had a boss named Schelkunoff; he was, and still is, a very good friend of mine. Some military person came to me and demanded some answers by Friday. Well, I had already dedicated my computing resources to reducing data on the fly for a group of scientists; I was knee deep in short, small, important problems. This military person wanted me to solve his problem by the end of the day on Friday. I said, “No, I’ll give it to you Monday. I can work on it over the weekend. I’m not going to do it now.” He goes down to my boss, Schelkunoff, and Schelkunoff says, “You must run this for him; he’s got to have it by Friday.” I tell him, “Why do I?”; he says, “You have to.” I said, “Fine, Sergei, but you’re sitting in your office Friday afternoon catching the late bus home to watch as this fellow walks out that door.” I gave the military person the answers late Friday afternoon. I then went to Schelkunoff’s office and sat down; as the man goes out I say, “You see Schelkunoff, this fellow has nothing under his arm; but I gave him the answers.” On Monday morning Schelkunoff called him up and said, “Did you come in to work over the weekend?” I could hear, as it were, a pause as the fellow ran through his mind of what was going to happen; but he knew he would have had to sign in, and he’d better not say he had when he hadn’t, so he said he hadn’t. Ever after that Schelkunoff said, “You set your deadlines; you can change them.”

After all, if you want a decision `No’, you just go to your boss and get a `No’ easy. If you want to do something, don’t ask, do it. Present him with an accomplished fact. Don’t give him a chance to tell you `No’. But if you want a `No’, it’s easy to get a `No’.

Anger

Another fault is anger. Often a scientist becomes angry, and this is no way to handle things. Amusement, yes, anger, no. Anger is misdirected. You should follow and cooperate rather than struggle against the system all the time.

Summary

In summary, I claim that some of the reasons why so many people who have greatness within their grasp don’t succeed are: they don’t work on important problems, they don’t become emotionally involved, they don’t try and change what is difficult to some other situation which is easily done but is still important, and they keep giving themselves alibis why they don’t. They keep saying that it is a matter of luck.