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

Я делаю так. Мы обсуждаем на планировании сколько максимум в этом спринте можем вложить в НИОКР относительно капасити в сторипойнтах. На оставшееся набираем. На Дейли обсуждаем как там что. Это не так чтобы правильно и канонично, но примерно работает.

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

но в люом случае в СП считать НИ трудно, если вообще возможно

Весь разговор из-за того, что Вы, если судить по сообщениям, не до конца понимате как работает Аджайл-манифест
Если компания использует Скрам, сторипоинты и ДевОпс, видит в этом смысл и это отражается положительно на деньгах, то удалять тот же Скрам и его элементы из-за "Люди важнее процессов и инструментов" не стоит.
Хотя, это только мое мнение. Вполне может не совпасть с Вашим.

я вот хочу немного накинуть, наверное.

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

и это было agile во все поля, как я вижу

но так сверу можно сказать: да, удалил скрам

Тимур, а как работает Аджайл-манифест?

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

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

Чтобы быстро обучаться надо иметь возможность делать small batch деплои, тогда мы после попадания в прод можем смотреть на метрики и после попадания в общую ветку или попадания на код ревью 40 строчек вместо 400 получать быструю критику или советы.

Обучение в девопс проходит на основе экспериментов и опыта всех участников за счёт суперкоротких петель. И на счёт безобвинительных инцидентов

Это супер коротко

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

Ответа выше достаточно? Если нет то можно в личку

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

да, я пчочитаю

плюсую, буду доклад вскоре про это делать как раз

а во что он выродился?

Ретромат видели?

Чато вопросы про "а посоветуйте новый формат ретро? а то старые надоели" видели?

Алексей, у тебя бывает время на просмотр докладов? я в неделю 6-10 июня даю на podlodka crew как раз доклад о том, чем фигово ретро и чем ее можно заменить без всех ее проблем

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

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

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