Цель на 2018 год: меньше ловкости и скрам-разговоров

Здравствуйте, и добро пожаловать в Scrum Tawk, я ваш хозяин Джон ...

Одна из моих целей на 2018 год - тратить меньше времени на попытки разгадать #agile и #scrum. Двусмысленность - кроличья нора и слова слишком мягкие. Я потратил кучу времени в 2017 году, перефразируя различные дебаты. Я сильно сомневаюсь, что добавил что-то значимое в совокупность знаний, поэтому я предполагаю, что мое время (и ваше время) лучше проводить в другом месте.

Итак, с этим я буду преуменьшать разговор Agile и Scrum. Вот почему ...

Во-первых, это скучно и повторяется ...

А также…

  1. Упоминание Agile редко продвигает разговор вперед, особенно с людьми вне пузыря Agile-ботаников.
  2. Любой поиск в Google приводит к тому, что многим дебатам по Agile и Scrum уже почти десять лет. Они не решаются ... путаница сохраняется. Я бы сказал, что они ухудшаются, когда «Agile» становится старше, продается / продается и становится дефолтом. Вероятность того, что я собираюсь разгадать эту путаницу, очень мала. Некоторые полезные души обратились ко мне, чтобы сообщить, что у них были одинаковые дебаты с теми же людьми 6+ лет назад.
  3. По крайней мере, для меня Agile включает в себя ряд ценных моделей, практик и перспектив. Это также идет с большим количеством багажа - почти никто, с кем я работаю, не сталкивается с Agile впервые. Высокопроизводительные команды, с которыми я работал, свободно выбирают из целого ряда шаблонов (многие из которых находятся за пределами гибкого зонтика), поэтому я считаю более полезным перейти прямо к полному корпусу шаблонов. По совпадению, эти команды редко говорят, что они «делают Agile» или «делают Scrum».
  4. Я работаю в разных племенах, но в глубине души я являюсь «человеком продукта» (UX, управление продуктом и т. Д.) И типом системного мыслителя. Недавние сплетни в Twitter от различных Agile-людей убедили меня, что Agile (как он существует сегодня) в первую очередь для «разработки программного обеспечения», с большой историей «разработки программных проектов». Хотя есть много призывов к совместной работе «бизнеса» и «команды», я чувствую неявную (а иногда и явную) границу. Ожидается, что у менеджера по продукту будут ответы, и команда покорно предоставит пригодные для использования / проверенные материалы. Я предпочитаю придерживаться более широкого, более целостного взгляда.
  5. Мои друзья из сообщества разработчиков продуктов и UX вложили массу сил в выяснение того, как «включить» лучшие практики этих сообществ в Agile. Опять же, я думаю, что это подчеркивает уклон в сторону Agile как «способа, которым разработчики программного обеспечения делают свое дело», и ставит другие области знаний в тупик, пытаясь научиться «играть» в Agile. Agile-сообщество охватило меня (и других) из мира продуктов - «нам действительно нужны отличные ПО» - но лично это не похоже на суть. Опять же, я всегда воображал, что существует более всеобъемлющий «способ», который объединяет продукт, UX, дизайн org, поддержку, операции и т. Д. Меня беспокоит то, что границы подпитывают фабрику компонентов и ориентируют на производительность.
  6. Около года назад я столкнулся с Джошуа Кериевским и Modern Agile. Когда мне нужен «генеративный» снимок Agile (то, что отражает суть, и может генерировать / фильтровать соответствующие «пути»), я возвращаюсь к Modern Agile, поскольку он целенаправленно свободен от определенных практик и применим для всей организации. … Важная характеристика, учитывая, что большинство «проблем» не являются исключительно проблемами разработки программного обеспечения. Я считаю, что MA является идеальным дополнением ко многим принципам / практикам Lean, которые имеют более широкую системную перспективу. Обычно аргументом является «но М.А. не объясняет как», и я утверждаю, что мы плывем по принципу «как». Они одинаково важны, и такие принципы, как «Сделать безопасность обязательным условием», по-видимому, глубоко резонируют с командами.
  7. Даже среди самоидентифицирующихся «агилистов» существуют совершенно разные интерпретации того, что Agile есть, не должно быть, не должно быть и т. Д. В этом нет ничего плохого (на самом деле это круто), но говорить о Agile очень сложно.
  8. Аналогичным образом, некоторые люди так глубоко отождествляют себя с определенными аспектами Agile - самоорганизацией, устойчивой работой, «доверием [командам] выполнять свою работу» - что любая дискуссия об относительных преимуществах различных практик или дизайн различных «шаблонов» становится сложным из-за глубоких личных вложений. Яростные агилисты пропекают много своей личной идентификации в Agile. По правде говоря, я один из них. Мне трудно говорить об этом.
  9. Все, что продается и продается (и сертифицируется), будет трудно разгадать. Это константа для любой «полезной» вещи (см., Например, DevOps), где есть спрос «купить ее». Диалог вокруг Agile находится под сильным влиянием опыта обучения этому за деньги, попыток внедрить его в потенциально враждебную среду и удовлетворения потребностей людей (и компаний), которые покупают / пытаются установить фреймворки (на данный момент ... позже усыновители) ).
  10. На мой взгляд, Agile-шаблоны / практики - это инструменты, используемые - в сочетании со многими шаблонами, смежными с Agile - для достижения ценных бизнес-результатов. Как недавно отметил Нил Киллик, слишком много разговоров об Agile создает впечатление, что «выполнение Agile» является конечной целью. Я не верю в это ... но чертовски легко сойти с этого пути.
  11. Может быть невозможно (для большинства не методологов, работающих в реальном мире) отделить Agile от Scrum. Скрам 1) контролируется двумя людьми, 2) имеет перспективу, 3) демонстрирует, что перспектива - включая различные страхи - в своем дизайне, и 4) является одним из многих допустимых подходов. Опять же, в этом нет ничего плохого - привет, спасибо Джеффу и Кену, а также фанатам Scrum - но это делает обсуждение намного сложнее в моем мире.
  12. Agile сообщество абсолютно замечательное, и я чувствую себя замечательно (и для меня большая честь) быть его частью. Это никоим образом не является отказом от Agile, но просто признание с моей стороны, что разговоры об этом явно не помогают - n = 1 - мне сильно.

Надеюсь, Agile-фолк найдет содержание интересным. Я буду говорить больше о конкретных практиках и меньше о туманной «гибкой» и гораздо меньше о Scrum.

Лучший

Джон