А именно:

• у менеджмента появилось чёткое понимание "новой компании", которую они хотят построить
• компания была побита на бизнес линии (одна основная с 5-ю командами и вторая экспериментальная с одной командой)
• владельцы и совладельцы (C-level) выработали стратегию перехода
• все в компании, кого эти изменения затрагивают, смогли внести свои коррективы, пожелания и в итоге прийти к консенсусу
• детали новой организационной структуры выработаны, найдены люди на новые роли (к примеру настоящие ProductOowner-ы)
• сформированы новые кросс-функциональные команды
• стартовал первый спринт!

Фактически, мы делаем LeSS.

Но что дальше, после старта спринта на все команды?

Я описал вкратце коучинговый план для своих спонсоров (это CTO и CPO).

Эта статья описывает подход построения долгосрочных и среднесрочных планов развития продукта и составлена по следам проведения двухдневного воркшопа в украинской продуктовой компании IPLand коучами из Scrum Ukraine.

Читать всю статью >>>

Мои обе книги по ретроспективам "Быстрый старт в agile ретроспективы" и "Сила интервенций в agile коучинге" доступны для бесплатного доступа с сайта компании Scrum Ukraine!

Качайте и пользуйтесь на здоровье.

Мой класс для Владельцев Продукта (Product Owner, PO) сильно отличается от большинства классов по этой тематике, которые я видел. Это не класс "Скрам для Владельцев Продуктов", где тренер использует свои "стандартные" слайды и лишь вставляет несколько терминов из контекста продакт-менеджмента.

Я стремлюсь, чтобы мой CSPO класс на  85-90% отличался от моего класса для Скрам-мастеров (CSM). Во-первых: участники нередко посещают оба (так что ни одна игра или симуляция не дублируются), во-вторых: этот класс нацелен на другую аудиторию, он даёт другие навыки, хотя нередко посещается Скрам-мастерами и членами Команд Разработки, которые хотят разобраться и начать помогать своим "продуктоводам".

Тренинг проходит под лозунгом "from idea to release roadmap", и я ставлю своей задачей наглядно, на примерах и повторяемых упражнениях показать участникам, как они могут взять практически любую идею продукта и разложить её на столько, что уже завтра можно начинать валидировать первые гипотезы и общаться с командой о рисках, технологиях, ключевых фичах. Хороший Владелец Продукта всегда имеет большой, видимый, известный всем и сделанный со всеми план релиза - долгосрочное видение развития продукта.

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

Мой класс - о том, как это виденье строить, валидировать, обновлять и коммуницировать всем вокруг. И также о том, как вписать эти активности в ежедневные Скрам рутины. Это важно. Ниже - детали.

Условно класс состоит из шести частей:

Infoq был годами ресурсом, где я вдохновлялся видео с разных мировых конференций. В 2016 я выступил на Lean Kanban France (#lkufr2016) и infoq записало и выложило видео и слайды моей сессии. Крутотень!

Выступал я совсем не о Lean и Kanban. Говорил я о сложности организаций и о том, как с этим работать.

Смотреть видео.

Оригинальная статья Рона Джефриз (Ron Jeffreies) "Dark Scrum".

Переведено с разрешения автора.

Давайте поговорим о так называемом «Мрачном Скраме». Слишком часто, по меньшей мере в разработке ПО, создаётся впечатление, что Скрам угнетает людей. Слишком часто Скрам не приносит результата так быстро, надёжно и постоянно, как должен был бы. В результате - все страдают. И  чаще всего сильнее чем все остальные страдают разработчики.

В последнее время я часто размышляю над следующим: 

В мае мы провели третью встречу Scrum Master Club. Эта встреча была посвящена работе с культурой компаний. Неисчерпаемая тема. Все мы хотим поменять культуру компаний к лучшему. Но как?

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

Посмотрите на два приведённых ниже фото - какая культура более гибкая?

"Agile в аутсорсинге не работает" - это цитата, которую слышно из разных источников. Так говорят. И не только те, кому вроде бы не повезло с проектом. Так говорят эксперты.

Так, на недавней встрече украинских аджалистов "Agile Pizza" (я сам не был, но следил в соц сетях и мне пересказывали живые свидетели), говорилось с аргументацией о том, что, мол,  "эх, жаль, agile не работает а аутсорсинге".

Agile - странная вещь.

Я еще помню 12-15 лет назад, как agile не работал совсем.

Затем, 5-7 лет назад - о том, как он не работает в банках.

Потом в гейминге и гейблинге.

Совсем недавно - о том, как в гос структурах его нет и не может быть.

Что же не так с этим аджайлом - он всё время где-то не работает.

Может позвонить в ЖЭК и вызвать мастера. Или вернуть по гарантии пока не поздно?

Оказывается, agile не работает не только в аутсорсинге.

На прошлой неделе один немецкий agile-коуч мне сказал (и об этом также есть скандальная статья), что agile не работает в немецкой культуре из-за любви к предсказуемости. (Жаль, что ребята из Zalando, jimdo, XING, Flixbus об этом не знают.)

Французы считают, что из-за своей любви к иерархии и сплетням, agile культуре на одних круассанах не прорасти.

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

За то все как один соглашаются с тем, что где-нигде, а в Скандинавии аджайл работает "на ура". Там он сокультурен их плоскому менеджменту, личной ответственности и трудолюбию. Почему же мне было так тяжело стартовать Скрам в 2004 в одном датском проекте? Тогда на старт первого спринта ушло полтора года!

Здесь что-то не так. Не находите? 

В аджайле не работает не более четырёх вещей одновременно.

Аджайл - простая вещь. Выходит, что в ней может не работать не так уж много частей:

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

Что ж. Так бывает. Что из этого вызвано именно аутсорсингом? Возможно, как минимум третье. И от части -первое.

Продакт Оунер - как часть контракта. Pourquoi pas?

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

Таких историй много. Более громких и менее громких.

То тут, то там я слышу, как заказчики распукают QA-отделы на Филиппинах и в Индии, и нанимают тестировщиков-автоматизаторов в свои nearshore-рные команды. Пурква бы и не па, в конце-то концов?

А может мы смотрим не в ту сторону бинокля?

То тут, то там практика continuous delivery становится реальностью...

Заказчики соглашаются с наймом локального командного коуча...

Кто-то на выходных настраивает первый раз за историю компании сервер сборок...

Где-то впервые за года разработчик и тестировщик вместе пишут тесты...

В офис тихо заносится первая маркерная доска...

"Scrum is the art of possible".

Эти микро-инновации процесса могут казаться очень незначительными. Но они имеют вес только внутри своего контекста и не могут быть вырваны из него без потери масштаба.

Нет, эти нано-изменения - не финальная победа. Это маленькие инкрементально-итеративные победки, победочки и победульки.

Но разве не в этом состоит суть agile-мышления? Понемногу, где можно и когда можно, менять свою среду своими руками.

Очень давно, на моём первом тренинге для Скрам-мастеров (2007 год), тренер сказал "Scrum is the art of possible". Это очень важная фраза. Она важнее всех фреймворков и ролей. Это про делать то, что сейчас возможно, не смотря на всё остальное, что (ещё) неподвластно.

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

Это про то, чтобы говорить "в этом году (квартале, спринте) мы чуть более agile" вместо того, чтобы сдаться, сказав: "тут аджайл не будет работать". 

C'mon guys!

Вау новость: мы с Наташей Трениной проводим класс в Минске.

Один класс, два тренера.

Ловите нас 3-4 августа на Certified ScrumMaster.

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

После десятилетий изучения команд мы точно уверены в одном - команды меняются, их динамика скоротечна и плохо предсказуема.

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

И наоборот.

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

В течение ряда лет коучинга команд (в качестве постоянного Скрам-мастера или приходящего Agile-коуча), я нащупал некоторую модель, которая кажется наименее неверна, чем другие, которые мне приходилось видеть. Я ничего не изобретал. Это лишь попытка вытаскивания наружу моего “шестого чувства” - того, как я интуитивно подхожу к работе с командами, с которыми мне приходится встречаться.

К слову, я влюбляюсь в каждую команду, с которой работаю. Это, наверное, звучит сверх-романтично, но это так. Командной работе присуща магия, которую невозможно ни предопределить, ни описать. В командах происходят вещи, на которые коуч только и может что надеятся. Но они происходят каждый раз: то вдруг кто-то ни с того ни с сего возьмёт на себя роль фасилитатора недопонимания на совещании и вы, как коуч, только и будете что ахать, не ожидав такого взлёта; то вдруг кто-то вызовется помочь другим в чём-то разобраться безо всяких там “стендапов” или наводящих вопросов; то вдруг тихо и безо всяких предупреждений, кто-то возьмёт и наладит что-то, что вы как коуч уже и не надеялись, что в этой команде когда-то заработает… Вещи происходят. В своей динамике и с присущей магией. Не было команды, которая бы меня не удивляла и не дарила удивительные сюрпризы.

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

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

1. Встретить команду на её уровне

2. Показать команду самой себе

3. Поднять команду над “уровнем моря”

4. Зародить новые привычки

5. Дать команде вести себя дальше

Каждый режим работы подразумевает свой вид и стиль интервенций.

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

И так, пять уровней, пять шапок. Самое сложное конечно же знать, какие носить в каких случаях, а какие нет.

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

Как мы и планировали - в апреле в Киеве прошла "Неделя Скрама" - две встречи и два тренинга, включая первый в Украине тренинге по Large-Scale Scrum.

В рамках двух встреч "Клуба Скрам Мастеров" выступил:

• Алекс Шевчук - скрам-мастер из Сиклума с теорией о развитии команды
• Грег Хатчингз - тренер по LeSS с докладом о принципах масштабирования Скрама на всю организацию
• Алексей Кривицкий - тренер по Скрам с воркшопом о радикальных изменениях

Материалы собраны ниже.

Ждём всех на очередной встрече.

Моё выступление на главной (она же "гнучка") сцене PM Day Kyiv 2016 прошло под знаменем сложности, спагетти и японской поэзии.

Ниже - избранные фото и слайды, ещё ниже - полная презентация. Видео в процессе - ждём с нетерпением.

Мы говорим и часто повторяем "постоянные улучшения", "кайзен", "continuous improvements". Это важные составляющие культуры улучшения процесса. Но стоит помнить, что у каждой практики есть анти-практика, которая так же полезна. Как в прочем и различные их комбинации.

Когда мы говорим по культуре постоянных улучшений, мы чаще всего имеем в виду пресловутый "Kaizen". Дословно с японского означающий "изменения к лучшему". Это плавная эволюция статус-кво, ведущая к оптимизации процесса, изменению среды и адаптации новых практик. Такими плавными изменениями процесса можно добиться до 20% процессных улучшений. И это  одна одна сторона процессного "инь-яня".

Вторая - это не так часто употребляемое "Kaikaku ("радикальные перемены"). Остальные 80% улучшений достигаются, к нашему всеобщему удивлению, именно через внедрение радикальных практик.

К слову, Скрам - это каркас процесса, который прививает философию Kaizen через постоянные циклы инспекции и адаптации. Ретроспектива - это собственно процессная церемония для практики Kaizen-мышления.

Что интересно, само внедрения Скрам - это по своей сути Kaikaku! Так как Скрам не внедряется по кусочкам (делал, не советую), а требует системных структурных измененией (к примеру построение кросс-функциональных команд).

Мои слайды с воркшопа на AGILEEE 2017 по масштабированию Скрам.

Статья написана на основе slidelog доклада. 

Расскажу о трёх вещах: прошлом, будущем и настоящем.

Хочется начать с личной истории. Почему? Да просто потому, что она у меня есть!

На заре моей карьеры я работал в одной компании.

Её названия я не могу назвать здесь. Могу лишь сказать, что оно начиналось на «мира-» и оканчивалось на «-тех». Эта компания  меня вырастила: взяла как полу-разработчика и дорастила до менеджера. Я ей очень благодарен.

Но речь не об этом.

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

Я ушёл.

Но, перед тем как уйти, я распечатал на корпоративном принтере две книги.

Когда впоследствии я стал миллионером, я купил их на амазоне. Вот одна их них: Agile Software Development Элистера Коуберна (Alistair Cockburn).

Я лежал в своей квартире на матрасе (тогда у меня ещё не было диванов) и читал эту книгу.

Она изменила мою жизнь. Я понял: «Вот оно! Вот ответ на вопросы, которые я даже не знал как задать». Эта книга изменила меня. Agile изменил мою жизнь. Я стал тем, кто я есть сейчас.

Шесть лет спустя, сида на том же самом месте, где я когда-то лежа читал книгу Элистера, я получаю имейл. Имейл от самого Элистера Коуберна: он принимает наше приглашение и едет в Киев.

Тот самый Элистер Коуберн едет в Киев. Вау!

Прозрачность и осознанность — одни из чуть ли не главных особенностей agile-подходов в разработке программного обеспечения, поэтому наличие адекватного русского термина сделало бы очевидным их преимущества над другими подходами и методологиями.

Но начнем пока с «начала».

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

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

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

Таким образом ситуация пошла против природной нестабильности требований к ПО. 

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

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

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

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

Прошло 20 лет, технологии усложнились на порядки; толерантность к стабильности требований уменьшилась и стала измеряться неделями; глобализация 21-го века заставила команды стать распеделенными ...

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

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

Давным-давно, обсуждая с коллегами по agile движению, что для программистов означает «agile», я пришёл к следующим выводам:

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

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

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

Если же хорошие отношения не гарантируют наличие agile среды, то должно быть значит что-то ещё, что выделяет эти проекты из ряда других. Я делаю предположение, что это —

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

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

Статья от 03/2007

Что ещё важно понимать для развития agile среды в команде?

«Разработка ПО — это игра изобретательности и кооперации»

Элистер Коуберн

Сразу хочу предупредить, что эта история об историях весьма объёмна. Так сказать, лонгрид из личного опыта.

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

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

Мне кажется, я был не одинок.

К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum, и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории.

Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична. Как говорят: «It’s about common sense».

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

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

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

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

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

Итак., как же проводить ретроспективы?

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

Это же касается ретроспективы по окончанию релиза или другой фазы проекта.

Для простоты я рассматриваю ретроспективы, привязанные к окончанию спринта.

При попытке проведения ретроспективы по вышеописанной структуре, многие команды:

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

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

А что, если ничего не будет сделано? В следующий раз команда cгенерирует очередной список, и так до тех пор, пока практика ретроспектив справедливо (для такого типа ретроспектив) не будет объявлена бесполезной.

Что же здесь не так?

Расскажу вам историю о том, как мы с коллегами-аджалистами несколько лет назад решили обсудить следующий философский вопрос: «Чем является Скрам: не более, чем инструментом или чем-то большим?»

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

Обсуждение началось с поста статьи Тобайаса Мейера (Скрам-тренера, фасилитатора и анархиста) под названием The People's Scrum, где автор утверждает, что он не согласен с теми, кто ставит Скрам наравне с такими инструментами как Канбан. И что (дословно):

To reduce it to “a tool” is to completely miss its magic, and to bring us back into a world of best practices and repeatable process.

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

Это запустило активный поток дискуссий в нашей группе, к которой я приложил (готов это признать) свою нечистую руку.

Поясню.

Когда я начал в нашей письменной дискуссии объяснять, что понимаю под Скрам, я в порыве перечислил такие вещи как:

Очевидно, что моё перечисление, если его сравнить с базовым определеним Скрам как «итеративно-инкрементального каркаса управления сложной работой», может показаться по меньшей мере нелогичным и непоследовательным.

Это меня встревожило. И заинтересовало.

Что же я (человек, который читает тренинги, лекции и ведет активную пропаганду) понимаю на самом делел под «Скрам»?