И еще раз о Scrum.

И еще один пинок мяча в те же ворота, что и прошлой статье. Все таки, меня удивляет вот такое отношение к Scrum (взять отсюда):

Scrum creates self organized teams. They organize themselves, they organize their quality. They organize their tools. They organize their engineering practices (TDD, pair programming). Why? Because they are responsible for delivering. No one else is.

Господи, ну какая-же фигня. Объясните почему вдруг у них появляется супер-пупер ответственность за результат.

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

Но вот только не надо мне рассказывать, что из плохо организованной, немотивированной команды Scrum сделает сплоченный коллектив, и все как один с флагами будут responsible for delivering.

Еще раз повторю мысль из предыдущей статьи. Scrum — это методика управления проектами. Все остальное в нем не большые добавки и приятности. Но это никак не методика повышения ответственности команды.

20 комментариев to “И еще раз о Scrum.”

  1. Зато какая реклама: scrum повышает мотивацию и отвественность за результат:) Ничего скоро истерия по поводу scrum закончится и появится новая серебряная пуля:) Возможно это будет Канбан:)

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

    Да, команда не изменится после начала внедрения scrum, люди инертны. В данном случае стоит учитывать кривую эффективности scrum (начало — нормальная эффективность, согласование — низкая эффективность, продуктивность — высокая эффективность). Также существует другая проблема, которая хорошо описана тут — http://dilbertru.blogspot.com/2009/07/20090709.html

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

    p/s
    Анализируя ваши высказывания об авторитарном стиле и scrum, можно прийти к выводу, что результаты труда ваших программистов вас не устраивают. Оно и понятно, деньги идут от вас. Но по моему мнению авторитарный стиль усугубит ситуацию и станет только хуже. Кстати причина скорее всего в том что вы имеете опыт программирования и видите неэффективность ваших подчиненных.

    • Victor Ronin:

      Насчет Scrum истерии — согласен, сейчас его превозносят больш, чем оно того стоит.

      > Также существует другая проблема, которая хорошо описана тут — http://dilbertru.blogspot.com/2009/07/20090709.html

      Не совсем понял, причем тут она к Scrum.
      Но в целом есть хорошая метода — 50% бонуса дается за личные достижения, 50% за достижения компании.

      >результаты труда ваших программистов вас не устраивают.

      М… Не совсем так. То, что я говорю — это суммарный опыт личного бизнеса, работы программистом и team lead’ом. Так что с разных точек зрения.

      Вот тут я описывал с точки зрения бизнесмена, почему «к людям надо помягче» не работает — http://victorronin.com/2008/07/15/biznes-eto-vam-ne-xixanki-xaxanki/
      С точки зрения team lead’а — твердость нужда для того, что команда была организована, а не превращалась в аморфную массу.
      С точки зрения программиста, опять же, приятней иметь твердое руководство, которые проводит какой-то курс действий, чем мягкое руководство, которое пускает все на самотек и потом начинает спрашивать в самом самом конце, когда уже нужно уже кого-то увольнять.

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

      • > Не совсем понял, причем тут она к Scrum.
        Тут все просто, обычно в scrume бонусы делают командными. И когда команда только начинает вместе работать, то наблюдаются проблемы с командной работой. Получается что бонус члена команды зависит от других, а другим он пока не доверяет (нужно время).

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

        p/s
        А бизнес есть бизнес:)

        • Victor Ronin:

          Насчет командных бонусов не знал.
          Тогда очень точно в dilbert’е сказано. Палка о двух концах — пока все работают хорошо и бонусы хорошие — все зашибись, как только бонусы не слишком и кто-то работает не слишком — начнется охота на ведьм.

          • А как в scrume без командных бонусов, иначе командная работа и отвественность за результат не получится:)

            • Victor Ronin:

              У нас не было командных бонусов. Я в Scrum поучаствовал в США.
              Тут вообще с бонусами достаточно странная система (с моей точки зрения).

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

              Бонус выдается 50% за личные достижения и 50% за компанейские (вот это хорошая идея).

              Насчет командным бонусов… М.. Я бы НЕ хотел в таком участвовать. Боюсь, что сам очень быстро бы скатился до рукоприкладства относительно людей, которые активно расслабляются на работе.

              • На счет бонусов 50 процентов за личное, 50 за командное я соглашусь, это правильно. И желательно это все раз в два-три месяца.

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

                • Victor Ronin:

                  >Цель, достижение и результат, награждение должны быть общими.

                  Где-то я это слышал. На похожих принципах СССР вроде пытались строить.

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

      • >М… Не совсем так. То, что я говорю — это суммарный опыт личного бизнеса, работы >программистом и team lead’ом. Так что с разных точек зрения.
        Сложно глядеть на ситуацию с разных точек зрения, особенно когда кругом куча проблем. Любое мнение всегда возникает в контексте. Причем, о контексте необязательно знать другим при высказывании мнения.

    • Victor Ronin:

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

      — небольшая молодая компания (эдак года 3 на рынке)
      — абсолютное большинство сотрудников возраста эдак 20 — 27 лет, причем для многих из них эта первая серьезная работа
      — коллектив вероятнее всего небольшой (ну скажем 7-15 человек)
      — всем интересно развиваться, разбираться в новых технологиях
      — основатель/сооснователь — программист по образованию.

      Примерно попал?
      Если да, то тогда я вполне понимаю откуда это желание стелить помягче. Это самое золотое «детство» фирмы, когда мягкость еще работает.

      • Примерно так, но компании уже 5 лет минуло:) Из них три года я был ceo, сейчас решил сменить род деятельности:)
        p/s
        Кстати период золотого «детства» уже закончился. А процесс «взросления» это поистине сложная штука:)

        • Victor Ronin:

          Та да, взросление проходит м… болезненно.

          Приятно, что моя оценка оказалась достаточно точной 🙂

          • Надеюсь и я был достаточно точен 😉

            • Victor Ronin:

              М… Кое что точно, кое что нет.

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

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

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

              Увы, в тот момент я о Scrum не знал. Так что мои комментарии вообще.

              С Scrum’ом познакомился позже (в США) будучи наемный работником.

              >Но по моему мнению авторитарный стиль усугубит ситуацию и станет только >хуже.

              Если конечно стать диктатором — то пожалуй да. Если найти золотую середину — то должна улудшить.

              >Кстати причина скорее всего в том что вы имеете опыт программирования и >видите неэффективность ваших >подчиненных.

              Согласен. Мне достаточно тяжко видеть, что задачу которую можно решить за 30 минут, мусолят день. Кстати, даже не ведя бизнес, а будучи наемным рабочим — мне все равно тяжко видеть эту ситуацию.

              • Взросление компании это отдельная тема для разговора, там все очень непросто.

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

                >Если конечно стать диктатором — то пожалуй да.
                Человек существо увлекающееся, порой очень сложно сдержать и не переборщить. Я всего лишь предупреждаю.

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

  2. Alex:

    Команда становится более ответственной за проект за проект хотя бы потом, что только команда определяет, сколько задач будет реализовано в течение следующего спринта. Никакой менеджер и никакой заказчик не может сказать команде что-то типа «не, это слишком долго — мне нужно, чтобы вместо месяца вы это сделали за неделю». И команда наверняка догадывается, что если они не смогут организоваться, то над ними поставят человека, который будет их организовывать насильно — разве даже сам по себе это не хороший стимул?:)

    И кстати, никто и никогда не утверждал, что из любая команда сможет самоорганизоваться — это одна из самых сложных задач, но, тем не менее, овчинка стоит выделки.

    И еще прошу прощения, но вы забываете, что Scrum — это не пошаговое руководство «как заработать на феррари за 1 год», а набор идей. Если КОМАНДА СМОЖЕТ реализовать эти идеи — у нее будет очень хорошая производительность, стабильность и предсказуемость результатов, высокое качество кода и пр. Если не сможет — ничего этого, естественно, не будет. Но вопрос — разве в классическом менеджменте не похожая ситуация? Есть набор практик (PMBOK, например). Смог МЕНЕДЖЕР реализовать все эти практики — будет все хорошо, а не смог — будет плохо.

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

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

    • Victor Ronin:

      Согласен полностью с тем, что вы написали.
      Но добавлю несколько «но».

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

      Звучит, как то, что мы ищем стрелочника. На самом деле, просто есть человек, есть задача за которую он ответственнен. Делает хорошо — молодец, делает плохо — не молодец.

      б) Берем команду и вдруг обнаруживаем, что она не смогла самоорганизоваться. Что будем делать дальше? Увольнять всю команду/весь отдел разработки? М… Достаточно сомнительное дело.

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

      Ну и насчет того, что команды самоорганизовываются. Я видел гигантское количество разработчиков, которым можно хоть Scrum, хоть сделай за наделю, то что обычно месяц — они просто приходят в 9 и уходят в 5 и им посрать на все методологии.

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

      • Alex:

        Есть 2 небольших комментария.

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

        б) Никто не обещал, что команда так рррраз — и организовалась 🙂 В Scrum есть определенные практики (ретроспективы, например) для постоянного улучшения процесса, что в итоге все равно так или иначе приведет к увеличению производительности, а ведь именно увеличение производительности должно быть следствием образования самоорганизующейся команды. Менеджеру ведь тоже нужно время, чтобы организовать работу команды, и вряд ли это недели, скорее месяцы. Так что все можно исправить, причем не кардинально (что есть опасно: а вдруг не в ту сторону _кардинально_ подправили), а небольшими шажками, но при этом _постоянно_ улучшая процесс и производительность.

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

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

  3. Victor Ronin:

    Реклама — понравилась.

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

    И вот как раз с самоорганизующемися командами, как по мне, достаточно большая проблема.
    Как ты точно написал, а если из 10 — только 9 самоорганизовалось, а если 5 или 3?
    В этом то и проблема, что в любой команде есть несколько лидеров/активных, которые и так самоорганизованы, а остальные тихонько бредут вслед.