Согласен. Команда становится командой не просто от того, что людей собрали и объявили им о том, что они команда. Над самоорганизацией нужно много работать. Конечно, если стоит такая задача. А если всем все норм (все честно пилят бабло, например), то, наверное, и баттхертить не должно.
А насчет людей, то на agiledays 2019 был отличный доклад Анны Обуховой, на тему того, что делать с саботажем — agiledays.ru/#speaker-194_733 (к сожалению еще запись не выложили, но как появится, рекомендую посмотреть). И хорошая новость в том, что клинических людей занимающихся саботажем немного. А поменять позицию конкретного человека с «просиживания штанов» на вовлеченность, как мне кажется можно. Но конечно же необходимо, чтобы были заинтересованные в этом люди.
Повторюсь, что подобного реального опыта у меня нет. Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. Вот годное видео про то как через канбан метод это делать youtu.be/-CQOb7e-6sg
Если опишите свой опыт про внедрение Lean через Kanban, то с большим удовольствием почитаю.
В целом я верю, что эффективный Scrum может быть за пределами IT. Например, я был на экскурсии в NPM, где scrum в производстве (Вот тут Сергей Чирва рассказывает, как они это сделали — youtu.be/kj-hyR4-MK8)
Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma?
Вот этот вопрос не совсем понял. Если это про мой опыт, то: нет, сам не делал таких внедрений. Со стороны наблюдал за попытками внедрить Lean. Или в чем вопрос?
То что есть у нас сейчас точно не опубликуем, потому что:
Стыдно: левой пяткой за 12 часов ничего красивого не пишется
Очень специфично: мы решали свою задачу, чтобы было что продемонстрировать на демо-фесте хакатона. Это фактически не переиспользовать нигде в таком виде.
Но в планах все-таки причесать и часть наработок отдать общественности. когда созреет обязательно здесь отпишусь и ссылками поделюсь
Это точно. Если вам потребуются распределенные транзакции, то хорошо подумайте, а нужны ли вам микросервисы в целом и распил в месте, где родится распределенная транзакция, в частности?
Предела конечно же нет, мир изменчив, и желание адаптироваться под изменения открывает команде новые горизонты для улучшений.
как вы определяете критерии для улучшений?
Опять же нет чего-то универсального, критерии определяются задачей. Важно сравнивать команду саму с собой, следить за динамикой.
Критерием и метриками можно брать, например, TTM или размер тех.долга (который может посчитать в Sonar)
Но важно чтобы эти показатели:
Были бизнес ориентированы, т.е. они были как разработке, так и бизнесу. Критерий — как коммуникационный мост для большего взаимопонимания.
Имели чисто информационный характер. Нельзя завязывать мотивацию на такие показатели (Потому что правда будет скрываться от бизнеса, а команда будет работать на показатель в ущерб остальному. В проигрыше все.)
Были прозрачными для всех, т.е. все понимали о чем речь, зачем это нужно и как данные собираются и анализируются.
ApeCoder Я посидел, подумал, понял.
Если funca действительно говорит о «продавцах Scrum, которые всю славу у команд забирают», то я подписываюсь под вопросами. Я не видел таких адептов scrum, которые бы говорили, что «если бы не scrum, то никуда бы ваша команда не побежала.» В agile: «Individuals and interactions over processes and tools»
Правда хочется увидеть пруфы того, что заслуги команд приписываются инструменту.
Demetrikl подумал, что идет речь про ваш собственный маркетинг.
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
ApeCoder несколько раз прочитал ваше сообщение. Но так и не понял вашего вопроса ко мне. Не могли бы вы перефразировать?
Вы говорите про «Маркетинг SCRUM».
Про маркетинг первый заговорил funca, я пытаюсь выяснить ситуацию где он сталкивался с таким коварным маркетингом, который:
При этом маркетинг от scrum стремиться присваивать вообще все достижения себе.
вы хотите сказать, что идея встречаться со стейкхолдерами где они смотрят инкремент и дают обратную связь это чисто заслуга Scrum?
Я хочу сказать обратное. Если в конце спринта команда не проводит sprint review и не получает от стейкхолдеров обратную связь, то это не скрам. И отсюда мой вопрос к вам: Как при таких условиях маркетинг может забирать чужие достижения?
Практика регулярно встречаться со стейкхоледрами прекрасна при любом подходе. Вы молодцы, что так делаете.
При этом маркетинг от scrum стремиться присваивать вообще все достижения себе. Думаю это одна из причин, почему его недолюбливают.
Вы можете поделиться своим опытом? Вы рассказываете жуткие вещи.
Вроде как при scrum на sprint review команда разработки встречается со стейкхолдерами, где они смотрят инкремент и дают обратную связь. Откуда у вас маркетинг? Как и чьи достижения они забирают?
Это правда, scrum можно просто использовать как тактический инструмент в разработки. И часто scrum без agile отлично решает поставленные перед ним задачи.
Просто мой тезис в том, что когда scrum и agile идут за руку, то такая команда может давать лучшие результаты.
Да это правда проблема. Но не знаю куда подробнее. Agile невозможно насильственно привить. Понимание появляется через обучение. Можно попытаться объяснить и научить. И очень легко в работе понять, разделяет человек эти ценности или нет (поступки нагляднее слов). По-моему мнению, нужно просто дать человеку выбор (Морфиус, Нео, все дела), но предварительно объяснив, что такое agile. Agile — это же не серебряная пуля, более того он не всегда полезен.
Но часто непонятно «как» это делать. Мне кажется, что единого и подходящего всем «как» нет. Всегда есть разные особенности у организации и команды, плюс, что более важно, разные задачи ставят перед scrum.
Но вот ошибки на моей практике часто повторяются, поэтому я и стал писывать через эту призму.
Какие ещё правила? scrum, это методология для тех уровней, которые не имеют отношения к разработке.
В первоисточнике немного не так: Scrum is a framework for developing, delivering, and sustaining complex products.
Возможно у нас терминологическая путаница. В моем понимании «разработка» — это общее понятие, по сути от идеи до появления продукта на рынке (т.е. включает в себя анализ, ui/ux, написание кода, тестирование, интеграцию и т.д.). И вот scrum как раз про организацию процесса этой самой разработки.
Это доказывает даже тот факт, что повысить уровень продуктивности работы команды пытаются с помощью посвящения в идеологию scrum.
Это действительно дико, если решают задачу «повысить уровень продуктивности команды» при помощи «посвящения в идеологию». Я уже несколько раз писал, что первое что нужно сделать — это понять для чего нужен scrum? Какая стоит перед ним задача? Это всегда очень индивидуально — нет серебряной пули. Часто scrum внедряют не там, или не для того. Вот отличная статья когда не надо. Например, scrum можно внедрять, чтобы повысить прозрачность: когда бизнес не понимает что там происходит в it департаменте, но очень хочет понять.
культ, о котором Вы говорите не реже, чем посылаете на конференции.
Классный и справедливый подкол! Да, действительно, я постоянно советую scrum master-у учиться. Это очень коррелирует с вашей мыслью, что программисты любят технологии и любят пробовать новое. Без этого ты можешь остаться за бортом профессии. Точно также scrum master должен постоянно учиться и развиваться. Возможно в этом есть одна из бед scrum, что еще нет культуры непрерывного обучения SM.
Программист, это ребенок, который живет в футуристическом мире созданным им самим на основе книг, игр и кино. Накой ему Ваш scrum? Ежедневно программисту нужно только комфортное рабочее место, столько еды, сколько ему нужно чтобы не возникло повода задуматься о голоде и интересные темы не относящиеся к рутине трудовых будней, с помощью которых можно развеяться. Только так можно поддерживать хрупкое чувство комфорта, отсутствие которого просто как бур в голове мешает сконцентрироваться на задаче.
Мне кажется, программисты все-таки сложнее. ИМХО так себе представляют программиста некоторые HR, поэтому часто в описаниях вакансий «печеньки в офисе» представляются как великое благо (на эту тему тоже есть статьи на хабре). Мне кажется, что программист, как и любой человек хочет заниматься чем то важным, делать мир лучше, приносить реальную пользу. Когда ты пишешь код по ТЗ из Jira, то нужна хорошая фантазия, чтобы ощущать силу влияния на мир своей работой. Часто получая ТЗ программист думает: «Ну что за ...? Люди, что вы делаете? Остановитесь!». Scrum помогает такому прекрасному порыву. В scrum программист и конечный пользователь очень сильно приближаются друг к другу (между ними лишь PO). Программист может понять, что хочет пользователь. Он может придумать, как это сделать. Сделать, отдать пользователю и получить обратную связь. И это очень ценно. Ты понимаешь что, для чего и для кого ты делаешь. И ты быстро понимаешь насколько хорошо ты это делаешь. В scrum программист может максимально раскрыться, ведь над ним нет менеджера, который говорит ему «что делать».
Об этом нет ни слова, зато есть постоянные встречи и упоминание о правилах. Такое ощущение, что речь идет не о it компании, а о галере, на которой даже отхлыстать кнутом могут.
Очень жаль, что у вас такое ощущение от прочтения, я хотел противоположного. Не могли бы вы подробнее раскрыть эту мысль с цитатами. Чтобы я мог провести работу над ошибками.
Все крутые it-лэйблы в самом начале ставили интересы своих сотрудников, чуть ли не выше всего. Им давали доли, проценты, возможность самореализации. Это мотивация. А все остальное это галера, где главное выжить как можно соков до того, как кто-то остынет.
Недавно на хабре появилась статья, где разбираются реалии нашего рынка. К сожалению, опционы пока больше приняты на западе. Хочется верить в улучшение ситуации. Но scrum немножко в другой плоскости от опционов.
Поэтому не понятно зачем программистам растолковывать основы scrum идеологии и тем самым попросту захламлять их рассудок. Если управленец считает, что посвятив в тонкости своей работы программистов сделает команду эффективнее, то он просто дурак.
Программист работая в компании, вынужден соблюдать правила, установленные в компании. И он может либо соблюдать эти правила как карго-культ, либо соблюдать их с пониманием того, зачем они введены (И если, например, он с ними не согласен, то может поднимать вопрос об изменении правил). Если мы говорим о scrum, то задача Scrum мастера объяснять и рассказывать участникам процесса, в том числе и программистам, об устройстве фреймворка. Это он делает из уважения к участникам процесса, ведь одна из ценностей scrum — это Transparency. И раскрывая, например, суть событий scrum для программистов, SM повышает прозрачность процессов. Если, например, SM навязывает (т.е. насильственно обучает) программистам знания об основах фасилитации, то это уже странно.
кому-то может показаться, что их отчитывают. Чтобы управленец подумал, если бы программисты, кадждые пять минут пытались посвятить его в тонкости того, как те инструменты, которыми они пользуются, путаются всяческими багами и несовершенствами воткнуть им палки в колеса? Такой подход и есть начало конфликта.
Похоже на личный негативный опыт. То что вы описываете — это конечно же неправильно. Собственно этот вопрос и хотелось поднять. Что часто могут быть поступки и решения, которые вызывают негатив, а идут из-за непонимания.
если хорошие PO и хорошие команды мне встречались, то вот внятных и хороших Scrum-мастеров в живую еще не видел.
Звучит грустно, но легко в это верится.
Что касается Адизеса, то к сожалению его книги не читал (но записал в то что стоит прочесть). Но ваше описание очень похоже на роли заложенные в scrum guide.
А насчет людей, то на agiledays 2019 был отличный доклад Анны Обуховой, на тему того, что делать с саботажем — agiledays.ru/#speaker-194_733 (к сожалению еще запись не выложили, но как появится, рекомендую посмотреть). И хорошая новость в том, что клинических людей занимающихся саботажем немного. А поменять позицию конкретного человека с «просиживания штанов» на вовлеченность, как мне кажется можно. Но конечно же необходимо, чтобы были заинтересованные в этом люди.
Если опишите свой опыт про внедрение Lean через Kanban, то с большим удовольствием почитаю.
Вот этот вопрос не совсем понял. Если это про мой опыт, то: нет, сам не делал таких внедрений. Со стороны наблюдал за попытками внедрить Lean. Или в чем вопрос?
Я сторонник работающих практик, изучать опыт других — это хорошо.
Но в планах все-таки причесать и часть наработок отдать общественности.
когда созреет обязательно здесь отпишусь и ссылками поделюсь
Вот классный, ставший классикой, ролик про это vimeo.com/18951935
Плохо когда scrum без agile — именно эту мысль хотел донести этой статьей.
Опять же нет чего-то универсального, критерии определяются задачей. Важно сравнивать команду саму с собой, следить за динамикой.
Критерием и метриками можно брать, например, TTM или размер тех.долга (который может посчитать в Sonar)
Но важно чтобы эти показатели:
Если funca действительно говорит о «продавцах Scrum, которые всю славу у команд забирают», то я подписываюсь под вопросами. Я не видел таких адептов scrum, которые бы говорили, что «если бы не scrum, то никуда бы ваша команда не побежала.» В agile: «Individuals and interactions over processes and tools»
Правда хочется увидеть пруфы того, что заслуги команд приписываются инструменту.
Про маркетинг первый заговорил funca, я пытаюсь выяснить ситуацию где он сталкивался с таким коварным маркетингом, который:
Я хочу сказать обратное. Если в конце спринта команда не проводит sprint review и не получает от стейкхолдеров обратную связь, то это не скрам. И отсюда мой вопрос к вам: Как при таких условиях маркетинг может забирать чужие достижения?
Практика регулярно встречаться со стейкхоледрами прекрасна при любом подходе. Вы молодцы, что так делаете.
Вы можете поделиться своим опытом? Вы рассказываете жуткие вещи.
Вроде как при scrum на sprint review команда разработки встречается со стейкхолдерами, где они смотрят инкремент и дают обратную связь. Откуда у вас маркетинг? Как и чьи достижения они забирают?
Это правда, scrum можно просто использовать как тактический инструмент в разработки. И часто scrum без agile отлично решает поставленные перед ним задачи.
Просто мой тезис в том, что когда scrum и agile идут за руку, то такая команда может давать лучшие результаты.
Но часто непонятно «как» это делать. Мне кажется, что единого и подходящего всем «как» нет. Всегда есть разные особенности у организации и команды, плюс, что более важно, разные задачи ставят перед scrum.
Но вот ошибки на моей практике часто повторяются, поэтому я и стал писывать через эту призму.
В первоисточнике немного не так: Scrum is a framework for developing, delivering, and sustaining complex products.
Возможно у нас терминологическая путаница. В моем понимании «разработка» — это общее понятие, по сути от идеи до появления продукта на рынке (т.е. включает в себя анализ, ui/ux, написание кода, тестирование, интеграцию и т.д.). И вот scrum как раз про организацию процесса этой самой разработки.
Это действительно дико, если решают задачу «повысить уровень продуктивности команды» при помощи «посвящения в идеологию». Я уже несколько раз писал, что первое что нужно сделать — это понять для чего нужен scrum? Какая стоит перед ним задача? Это всегда очень индивидуально — нет серебряной пули. Часто scrum внедряют не там, или не для того. Вот отличная статья когда не надо. Например, scrum можно внедрять, чтобы повысить прозрачность: когда бизнес не понимает что там происходит в it департаменте, но очень хочет понять.
Классный и справедливый подкол! Да, действительно, я постоянно советую scrum master-у учиться. Это очень коррелирует с вашей мыслью, что программисты любят технологии и любят пробовать новое. Без этого ты можешь остаться за бортом профессии. Точно также scrum master должен постоянно учиться и развиваться. Возможно в этом есть одна из бед scrum, что еще нет культуры непрерывного обучения SM.
Мне кажется, программисты все-таки сложнее. ИМХО так себе представляют программиста некоторые HR, поэтому часто в описаниях вакансий «печеньки в офисе» представляются как великое благо (на эту тему тоже есть статьи на хабре). Мне кажется, что программист, как и любой человек хочет заниматься чем то важным, делать мир лучше, приносить реальную пользу. Когда ты пишешь код по ТЗ из Jira, то нужна хорошая фантазия, чтобы ощущать силу влияния на мир своей работой. Часто получая ТЗ программист думает: «Ну что за ...? Люди, что вы делаете? Остановитесь!». Scrum помогает такому прекрасному порыву. В scrum программист и конечный пользователь очень сильно приближаются друг к другу (между ними лишь PO). Программист может понять, что хочет пользователь. Он может придумать, как это сделать. Сделать, отдать пользователю и получить обратную связь. И это очень ценно. Ты понимаешь что, для чего и для кого ты делаешь. И ты быстро понимаешь насколько хорошо ты это делаешь. В scrum программист может максимально раскрыться, ведь над ним нет менеджера, который говорит ему «что делать».
Очень жаль, что у вас такое ощущение от прочтения, я хотел противоположного. Не могли бы вы подробнее раскрыть эту мысль с цитатами. Чтобы я мог провести работу над ошибками.
Недавно на хабре появилась статья, где разбираются реалии нашего рынка. К сожалению, опционы пока больше приняты на западе. Хочется верить в улучшение ситуации. Но scrum немножко в другой плоскости от опционов.
Программист работая в компании, вынужден соблюдать правила, установленные в компании. И он может либо соблюдать эти правила как карго-культ, либо соблюдать их с пониманием того, зачем они введены (И если, например, он с ними не согласен, то может поднимать вопрос об изменении правил). Если мы говорим о scrum, то задача Scrum мастера объяснять и рассказывать участникам процесса, в том числе и программистам, об устройстве фреймворка. Это он делает из уважения к участникам процесса, ведь одна из ценностей scrum — это Transparency. И раскрывая, например, суть событий scrum для программистов, SM повышает прозрачность процессов. Если, например, SM навязывает (т.е. насильственно обучает) программистам знания об основах фасилитации, то это уже странно.
Похоже на личный негативный опыт. То что вы описываете — это конечно же неправильно. Собственно этот вопрос и хотелось поднять. Что часто могут быть поступки и решения, которые вызывают негатив, а идут из-за непонимания.
Звучит грустно, но легко в это верится.
Что касается Адизеса, то к сожалению его книги не читал (но записал в то что стоит прочесть). Но ваше описание очень похоже на роли заложенные в scrum guide.