Согласен, что на тему "правильного Scrum-а" написано 100500 статей, и кажется, что тема должна уже быть исчерпана.. с другой стороны - все знают, как правильно, но при этом продолжают делать неправильно.. в этом случае остается либо просто принять этот факт, либо пытаться снова говорить о том, как делать не нужно и почему - вдруг что-то все-таки изменится (правда это уже вопрос философский).
Что касается практики - все описанные в статье кейсы - как раз примеры из практики в разных организациях. Где-то эти проблемы получилось решить, где-то нет, и все в итоге загнулось. Было бы интересно рассказать о том, как проблемы были решены - возможно. Помогли бы эти же методы кому-то другому - не факт, т.к. все снова упирается в человеческий фактор, и то, что отлично отработало в одном месте не факт, что поможет в другом. Тут как с книжками про построение бизнеса - полезнее читать не про то, как заработать миллион, а как его потерять.
А по поводу успешного создания продукта - тут надо сначала определиться с критериями успешности, они у всех очень разные:) если такими считать просто создание и развитие продукта, который решает потребности своей целевой аудитории и приносит доход, который от него ждут - да. Правда честно скажу, что там не все работало прям по "правильному" Scrum-у (но в целом близко к нему). Были ли там проблемы из серии тех, что вы описали или сопоставимой сложности - честно скажу, нет. Возможно потому, что старались как раз учесть негативный опыт, и минимизировать вероятность возникновения подобных проблем. Но тут опять же - те подходы, которые помогли в этих случаях, не факт, что помогут в другой среде с другими людьми.
Спасибо за развернутый и интересный комментарий! Мне кажется, это уже следующий уровень проблемы. В статье я описал типовые ошибки именно внедрения Scrum, которые хоть и банальны, но регулярно встречаются. Вы рассматриваете ситуацию, когда Scrum может быть внедрен без этих ошибок, но проблемы возникают уже при взаимодействии между людьми в команде и вне. И для этих проблем сложно предложить какое-то общее универсальное решение, т.к. оно будет зависеть уже от конкретных людей и ситуации, в которой они находятся. Но это реально интересная тема. Тут можно было бы рассмотреть подробнее каждую ситуацию и разобрать, как можно было бы ее решить конструктивно.. но это уже тема для отдельных статей.
Ну назначать ответственного без полномочий - по большому счету, это самообман.. да и закрывать проблему только за счет софт-скиллов (т.е. частных договоренностей) тоже в какой-то мере самообман (проблема остается на уровне организации, просто отдельная команда ее сумела обойти), но это уже философский вопрос:)
в этом случае, если решение проблемы зависит не от команды, или у команды нету возможностей/полномочий на нее повлиять, или перепробовали все возможное, и не работает, то честнее будет признать эту проблему как ограничение, с которым надо жить. и вместе придумывать, как его обходить, минимизировать влияние и т.д. и т.п.
это в любом случае лучше формальных "решений" с формальными "ответственными"
Это да, знакомая ситуация. Если нужно просто разово что-то делать, то тут чуть проще - делается задача, закидывается на доску, можно не забыть и проконтролировать. А вот если результат обсуждения, грубо говоря, состоит в идее о том, что "если произойдет такая фигня, то в следующий раз надо делать вот так", то тут сложнее..
Понятно, что это все можно тоже фиксировать в разных правилах работы, итогах ретро и т.д. и т.п.... но проблема в том, что со временем таких идей накапливается очень много, а "такая фигня" происходит редко.. и со временем такие решения просто забываются... и как это бывает в жизни, когда "фигня" произойдет, то никто уже про этот пункт и не вспомнит.
Для себя в одной из команд решили отдельно фиксировать подобные идеи, которые реально могут быть важными, и просматривать их перед каждым ретро.. как только убеждаемся, что идея уже несколько раз применялась на практике, и мы про нее точно не забудем - удаляем с доски.
Согласен.. как вариант, в этом случае помочь показать более объективную картину может искренняя обратная связь от stakeholder-ов/реальный пользователей. Даже если команда будет с ней не согласна, это все равно дает стимул подумать о том, а действительно ли все круто и эффективно.
Вспоминаю примеры из своего опыта и опыта коллег и, к сожалению, прекрасно понимаю, что вы имеете в виду.. надеюсь, что идеи из этой статьи хоть кому-то и хоть немного помогут улучшить ситуацию.
Согласен, что на тему "правильного Scrum-а" написано 100500 статей, и кажется, что тема должна уже быть исчерпана.. с другой стороны - все знают, как правильно, но при этом продолжают делать неправильно.. в этом случае остается либо просто принять этот факт, либо пытаться снова говорить о том, как делать не нужно и почему - вдруг что-то все-таки изменится (правда это уже вопрос философский).
Что касается практики - все описанные в статье кейсы - как раз примеры из практики в разных организациях. Где-то эти проблемы получилось решить, где-то нет, и все в итоге загнулось. Было бы интересно рассказать о том, как проблемы были решены - возможно. Помогли бы эти же методы кому-то другому - не факт, т.к. все снова упирается в человеческий фактор, и то, что отлично отработало в одном месте не факт, что поможет в другом. Тут как с книжками про построение бизнеса - полезнее читать не про то, как заработать миллион, а как его потерять.
А по поводу успешного создания продукта - тут надо сначала определиться с критериями успешности, они у всех очень разные:) если такими считать просто создание и развитие продукта, который решает потребности своей целевой аудитории и приносит доход, который от него ждут - да. Правда честно скажу, что там не все работало прям по "правильному" Scrum-у (но в целом близко к нему). Были ли там проблемы из серии тех, что вы описали или сопоставимой сложности - честно скажу, нет. Возможно потому, что старались как раз учесть негативный опыт, и минимизировать вероятность возникновения подобных проблем. Но тут опять же - те подходы, которые помогли в этих случаях, не факт, что помогут в другой среде с другими людьми.
Спасибо за развернутый и интересный комментарий! Мне кажется, это уже следующий уровень проблемы. В статье я описал типовые ошибки именно внедрения Scrum, которые хоть и банальны, но регулярно встречаются. Вы рассматриваете ситуацию, когда Scrum может быть внедрен без этих ошибок, но проблемы возникают уже при взаимодействии между людьми в команде и вне. И для этих проблем сложно предложить какое-то общее универсальное решение, т.к. оно будет зависеть уже от конкретных людей и ситуации, в которой они находятся. Но это реально интересная тема. Тут можно было бы рассмотреть подробнее каждую ситуацию и разобрать, как можно было бы ее решить конструктивно.. но это уже тема для отдельных статей.
Ну назначать ответственного без полномочий - по большому счету, это самообман.. да и закрывать проблему только за счет софт-скиллов (т.е. частных договоренностей) тоже в какой-то мере самообман (проблема остается на уровне организации, просто отдельная команда ее сумела обойти), но это уже философский вопрос:)
в этом случае, если решение проблемы зависит не от команды, или у команды нету возможностей/полномочий на нее повлиять, или перепробовали все возможное, и не работает, то честнее будет признать эту проблему как ограничение, с которым надо жить. и вместе придумывать, как его обходить, минимизировать влияние и т.д. и т.п.
это в любом случае лучше формальных "решений" с формальными "ответственными"
Это да, знакомая ситуация. Если нужно просто разово что-то делать, то тут чуть проще - делается задача, закидывается на доску, можно не забыть и проконтролировать. А вот если результат обсуждения, грубо говоря, состоит в идее о том, что "если произойдет такая фигня, то в следующий раз надо делать вот так", то тут сложнее..
Понятно, что это все можно тоже фиксировать в разных правилах работы, итогах ретро и т.д. и т.п.... но проблема в том, что со временем таких идей накапливается очень много, а "такая фигня" происходит редко.. и со временем такие решения просто забываются... и как это бывает в жизни, когда "фигня" произойдет, то никто уже про этот пункт и не вспомнит.
Для себя в одной из команд решили отдельно фиксировать подобные идеи, которые реально могут быть важными, и просматривать их перед каждым ретро.. как только убеждаемся, что идея уже несколько раз применялась на практике, и мы про нее точно не забудем - удаляем с доски.
Согласен.. как вариант, в этом случае помочь показать более объективную картину может искренняя обратная связь от stakeholder-ов/реальный пользователей. Даже если команда будет с ней не согласна, это все равно дает стимул подумать о том, а действительно ли все круто и эффективно.
Да, scrumbag и скрамнюк лучше передали бы смысл:)
Вспоминаю примеры из своего опыта и опыта коллег и, к сожалению, прекрасно понимаю, что вы имеете в виду.. надеюсь, что идеи из этой статьи хоть кому-то и хоть немного помогут улучшить ситуацию.
Да, самое главное упустил:) хотя в жизни этот этап точно никто не забудет:)