Delivery Manager в Grid Dynamics
  • Когда Scrum не работает. Пять основных проблем его применения

    Чаще всего наблюдаю картину, что одни говорят: «Вы тулите скрам везде, это неправильно! Есть кучу других подходов». Другие же говорят: «О боже, скрам все решит, давайте скрам! Больше скрама!»

    При этом мне кажется, что ни первые, ни вторые не понимают его сути.

    Давайте обратимся к PMBoK. Что это такое?
    Цитата:
    «PMBoK — a guide of all the things about Project Management»

    Когда тот же Scrum:
    «Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.»

    Так вот причем тут одно к другому? Каждый из подходов решает определенно свою задачу.
    В частности, весь блейминг на скрам приходит из сферы аутсорса, где отношения команды с конечным пользователем лежат через заказчика, которого интересуют такие вопросы как цена контракта, сроки выполнения, в первую очередь. А вот саму команду интересует качество отработки объёма данного контракта. Что по сути скорее заставляет забить на велью, а наоборот подраздувать таймлайны, для пущего комфорта команды.

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

    Так почему ПМБоК мешает Скраму или наоборот?

    Хотите решить проблему естимирования? Ок, круто! Да, скрам вам тут мало чем поможет.

    Хотите решить проблему трека велью и работы команды над развитием продукта и самой себя? Скрам круто подойдет.

    А почему бы и не совмещать эти прекрасные подходы?? Ведь в том же скрам гайде сказано: Да будет скрам ОБЛЕГЧЕННЫМ фреймворком. Что в моем понимании означает только одно — Вы поменяли подход и вышли за пределы скрам гайда? Ок! Это работает? — Вы молодец!