Методы разработки стратегии развития и Scrum

 

Методы разработки стратегии – совокупности подходов, способов и технологий создания стратегии развития предприятий, основанные на определённой научной базе и логике, обеспечивающей заданные параметры стратегического плана.

Методы разработки стратегии отличаются значительным разнообразием и включают в себя весь спектр стратегических методов и инструментов, начиная от наиболее простых и заканчивая сложными и многоэтапными подходами. Такое разнообразие обусловлено различными целями, которые преследуют авторы методов. Цели разработчиков методов разработки стратегии часто отличаются от задачи реализации стратегии.

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

Разработка стратегии организации – нетривиальная задача. Не только из-за того, что этот проект требует (1) особых компетенций, (2) специального состава участников, но и потому, что он требует (3) особой организации работы. Первые два требования (участники и компетенции) очевидны и сложны для реализации большинством компаний. Именно поэтому далеко не все организации разрабатывают стратегию самостоятельно, а у тех, кто решается на это, качество стратегии оставляет желать лучшего.

Проблемы организации процесса разработки стратегии

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

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

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

Какие методы разработки стратегии помогут повысить качество управления?

В ходе организации разработки стратегии развития для клиентов мы создали настоящую управленческую инновацию: сплав из метода разработки стратегии развития Strategium и метода гибкого управления проектами SCRUM.

Данный метод разработки стратегии имеет наименование Strategium Space Scrum, и, помимо упрощения и ускорения процесса разработки стратегии, увеличивает вероятность её реализации. Расскажу об этом подходе чуть позже, а сейчас немного предыстории, почему такое сочетание методов оказалось возможным.

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

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

Классификация методов разработки стратегии

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

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

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

Поэтому мы продолжили исследования в этой области и рассказываем о новом методе разработки стратегии с применением гибких подходов к разработке сложных продуктов.

Могут ли методы разработки стратегии включать Agile подходы?

Для логической завершенности концепции стратегической трансформации организаций не хватало одной важной детали – проверенного и признанного метода практической реализации изменений.

Мы нашли метод, который отлично вписался в целостную концепцию – динамическую многослойную систему стратегической трансформации организаций (Dynamic Enterprise Strategic Transformation System – DESTS). С помощью этой концепции мы обеспечиваем повышение квалификации руководителей и команд и делаем компании стратегически сфокусированными.

Так какой же метод мы нашли?

Это SCRUM – революционный метод управления проектами, разработанный Джеффом Сазерлендом и Кеном Швабером. Метод отлично подошел к разработке и внедрению стратегий.

Метод Strategium Space + Scrum = качество + скорость разработки и адаптации стратегии

Стратегия – сложный, творческий, итеративный и динамически изменяющийся продукт интеллектуального труда.

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

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

*Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми возможностями, для которых определён наибольший приоритет. […] строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. Источник: https://ru.wikipedia.org/wiki/Scrum

Кто-то может возразить, что SCRUM, в частности, и AGILE подходы вообще, предназначены для создания программного обеспечения.

С одной стороны, они будут правы.

Но что такое стратегия развития, если не программа?

Вполне себе программа, только не для компьютерной, а для организационной (или социальной) среды.

Компьютерная программа – это план действий составных частей компьютера, включая программное обеспечение, по достижению требуемого результата. А что такое стратегия развития? Это план действий для составных частей организации для достижения результата (видения и стратегических целей).

Революционные методы разработки стратегии с применением SCRUM

Сходство объектов управления и метода достижения результата дало возможность применить метод гибкой разработки под названием Скрам в нашем методе. На схеме ниже вы можете видеть принципиальную схему применения нашего метода для разработки стратегии компании.

Схема отражает не последовательность этапов разработки стратегии Strategium Space Scrum, а порядок выполнения организационных шагов для использования этого метода. Эта последовательность выглядит следующим образом:

1. На основании периодической системы стратегических элементов (инструментов и методов разработки стратегии) выбрать актуальный для конкретной компании состав методов разработки стратегии.
2. В соответствии с процессным подходом к управлению определить последовательность применения каждого из выбранных методов стратегического анализа и планирования.
3. Осуществить планирование стратегической сессии по инструкциям к каждому выбранному инструменту разработки стратегии.
4. Последовательно провести стратегические сессии по разработке стратегии в соответствии с выбранными методами разработки.
5. Оформить результаты каждой стратегической сессии. Так мы последовательно продвигаемся по каждому из этапов метода разработки стратегии и создаём конечный продукт: стратегию развития.
6. Результаты каждого из этапов необходимо согласовать с вышестоящими и смежными стратегиями. В случае расхождений принять меры по их устранению и согласованию позиций.
7. После согласования результатов каждой сессии запланировать и провести следующую стратегическую сессию в соответствии с методом разработки стратегии Strategium Space Scrum.

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

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

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

Как быстро разработать вашу стратегию развития?

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

1. Изучить метод разработки стратегии развития Strategium Space Scrum.
2. Применить этот метод при разработке реальной стратегии: стратегии компании или личной стратегии.

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

Мы распространили эту новую разработку и на смежную область – разработку личных стратегий.

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

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

У каждого руководителя и того, кто хочет стать руководителем, есть выбор:

А. Лихорадочно пытаться решать проблемы в порядке их поступления в условиях управленческого хаоса.

Б. Работать по чёткому и качественному долгосрочному плану, адаптируя его к изменениям по необходимости.

Новые методы разработки стратегии от Strategium Space помогут перейти из точки А в точку Б.

©Дмитрий Рыцев - автор является основателем проектов Strategium.Space и NooSphereum

https://strategium.space/

Official 5-Day Design Sprint

 

About the official Remote 5-day Design Sprint template

What Is a Design Sprint?

The big idea with the Design Sprint is to build and test a prototype in just five days. You'll take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution using a proven step-by-step checklist. It's like fast-forwarding into the future. 

Why use this Design Sprint template

The experts who literally wrote the book on design sprints created this template, just for Miro. First, facilitator Steph Cruchon of Design Sprint Ltd gathered the agency’s combined experience of physical design sprints and looked for ways to make it efficient and enjoyable in a remote setting. At the same time, the creators of the methodology at Google, Jake Knapp and John Zeratsky, teamed up with Jackie Colburn to write an in-depth guide to run full five-day remote design sprints. 

Together, they created this official template for remote sprints, invested personally in writing crystal clear instructions, and even added new exercises that don’t appear in the Sprint book but were part of their workshops. This template works hand in hand with the book and will help you run excellent 100% remote design sprints.

How to use the Design Sprint template

Using the Design Sprint template is easy. Typically how it works is, the facilitator will prep the event before guiding participants through the one big goal for each day of the sprint – to map, sketch, decide, prototype, or test. 

For those new to participating in Design Sprints, one of the biggest challenges will be to trust the process. Remember that times it will be overwhelming but that’s part of the process and it’ll all work out. 

Miro’s whiteboard tool is the perfect canvas to use for your design sprint — remotely or in person. Here’s one way to use it when you're preparing for your next sprint:

1. Get started by selecting this Design Sprint template.

2. Read the  for advice on tools, preparation, facilitation, and modified tactics. 

3. Give the sprint a name. E.g. “User signup flow.”

4. Clarify the goal of the sprint. E.g. “To improve the user’s experience as they sign up.”

5. Ensure you get the right people in the room and assign the roles within the team. Make sure to clarify and brief the role of the facilitator and decider in advance.

6. Then take the template to the session, because you’re ready to get started!

Invite your team to start collaborating, and don’t forget to share the finished product with the wider company. Be sure to tell everyone about the process and help them understand what you’ve explored and learned about the topic.

Какие побочные эффекты у методик Agile, Scrum, Lean, Kanban?

 

Индустрия программного обеспечения зародилась в начале 1960-х с появлением компьютеров в образовательных учреждениях и крупных компаниях. С появлением персональных компьютеров в конце 1970-х отрасль стала переживать взрывной рост, который, по сути, продолжается уже более 60 лет. Помимо развития самих языков программирования, средств разработки, платформ в постоянном развитии находятся и методики управления разработкой программного обеспечения (Software Development Methodology- SDM). Практически каждый год появляются новые методики и подходы к программированию и организации совместной работы; на сегодня достаточно широко известны более 40 концепций. Некоторые методики становятся по-настоящему популярными, о них пишут книги, ломают копья в сетевых баталиях, проводят конференции, ну, и, соответственно, упоминание этих модных аббревиатур становится практически обязательным для указания в резюме.

Лет 10 назад, для того, чтобы тебя принимали за серьезного разработчика, нужно было обязательно говорить о свободном владении инструментами RUP(Rational Unified Process) и PMBOK(Project Management Body of Knowledge). Если ты себя позиционировал как супермодный хиппи-программист, то можно было указать в резюме о применении методик экстремального программирования (XP) и приверженности методики водопада при управлении проектами (waterfallmodel). Сегодня модно стало говорить о применении гибких методик управления проектами. Ключевые слова — пропуска в современный мир разработчиков теперь: Agile, Scrum, Kanban, LEAN. Включение названий данных методик в резюме обычного начинающего программиста автоматически превращает его в модного ХайТек-хипстера, который уже не «пишет код», а работает с командой над стартапом, в роли не меньше, чем Scrum Master.

Сейчас, как и 10 лет назад, модные методики постоянно на слуху, но мало кто углублялся в их суть глубже, чем прочитать статью в Википедии. Чаще всего для свободного овладения современным сленгом хватало общения на форумах, да и редкого присутствия на конференциях, где докладывал об успехах использования модной концепции тот, кто удосужился прочитать о ней чуть больше, чем статью в Википедии. Регулярное появление новых методик ведения софтверных проектов обусловлено не сменой сленга, они нужны не для того, чтобы отделить программистов-мамонтов от современного разработчика-хипстера, а реальной потребностью отрасли. Кто-то слышал о новых прорывных методиках ведения строительных проектов? Нет, индустрия капитального строительства существует уже достаточно давно, методики устоялись, и потребности в активном поиске новых решений уже нет. Прорыв, кончено, возможен, но скорее, как случайная находка. Можно сослаться на тысячелетнюю историю развития данной отрасли, на то, что софтверному бизнесу еще и 60 лет нет… Хорошо, индустрия бизнес и финансового консалтинга существует не так долго, сопоставимо с разработкой ПО, о каких новых методиках ведения бизнес-консалтинга вы слышали? Причина в том, что строительная отрасль хорошо регламентирована стандартами и нормами, они устоялись, общеприняты, есть методики разработки строительной технической документации. В консалтинговых проектах, например, нет общепринятых стандартов и норм, но у каждой компании есть набор наработанных шаблонов, методик, подходов, при помощи которых можно получить неплохой результат работы команды, на 80% состоящей из стажеров.

Продолжающийся поиск решения для проектов разработки программного обеспечения обусловлен одной ключевой проблемой — очень высоким уровнем неопределенности, при том, что неопределенность во всем, от того, что будем делать, до как это будем делать и что в итоге получим. Когда заказчик хочет построить новый дом, то он более-менее представляет, что хочет в итоге получить, исполнитель знает какими технологиями и материалами это можно обеспечить, ну и все хорошо понимают, что в итоге будет построено. Когда клиент заказывает новое программное решение, то, скорее всего, почти все из того что будет сказано изначально, будет так или иначе изменено. Для решения поставленной клиентом задачи можно придумать миллион разнообразных решений, от адаптации готовых решений, до разработки с нуля своего решения. А в финале, затратив пару лет и несколько миллионов долларов клиентских денег, можно столкнуться с тем, что требуемого результата так и не достигли.

Классические методики управления, во многом, адресованы для снижения рисков исполнителя, связанных с плохой постановкой задачи клиентом. Выполнение работ разбито на четкие этапы, сначала делается устав проекта, потом состав работ (ProjectScope), далее фиксируются все работы в иерархическом плане работ, потом диаграмма Ганта, ну и, самое важное, все отклонения строго документируют в заявках на изменение. При четком соблюдении такой методики утилизировалось много человеко-часов, и, соответственно, бюджета, получалось много документации, но мало готового продукта. Рисков для исполнителя мало, но клиент не доволен. Современные проектные методики предлагают разнообразные способы решения проблемы нечеткости изначальных требований клиентов. Можно использовать поэтапную разработку, принцип водопада или спирали, если отношения с клиентом хорошие, то можно гибкую — Agile. Так или иначе, у софтверной отрасли сегодня есть инструменты решения данной проблемы.

Инструменты работы с динамичными клиентскими требованиями есть и работают, но отрасль продолжает поиск новых методик разработки. Может есть еще фундаментальные не решенные проблемы? Гибкие требования, большой диапазон возможных задач, все приводит к сложности фрагментировать работы и грамотно организовать командную работу. Классические методики предлагали сначала создать документ Требования к продукту (Product Requirements Document), потом провести анализ и приоритизацию задач, далее по каждому пункту создать функциональную спецификацию, к ней тест-кейс, и только потом отдать в разработку. Хорошо прописанные функциональные спецификации можно было распределить на разных программистов. Проблема была только в том, что часто нужно потратить времени на создание спецификации не меньше, а то и больше, чем на само написание кода. Современные методики, например, Scrum, предлагают решать эти задачи лучшей организацией командной работы, больше времени тратить на коммуникации, больше времени тратить на совместное обсуждение планируемых подходов к решению, ежедневными 15 минутками и т.д.

Улучшение коммуникаций с клиентом, переход на личные, фактически неформальные, коммуникации, позволит быстрее получить готовый продукт при продолжающемся непрерывном потоке клиентских «хотелок». Но у этого решения есть и цена — риски, если вдруг что-то по проекту пойдет не так, то, грубо говоря, бумажками прикрыться не получится. Отказ от формального и детального описания работ и переход на командную работу, обострил другую проблему, фактически, современную эпидемию — дефицит внимания. Все как-то забыли, что продукт — то, что несет в себе клиентскую ценность, получается не в результате обновления бэклога, ни на совещаниях, а после написания кусков работающего кода. А для того, чтобы написать этот код, нужно создать уникальный продукт, это как небольшое, но изобретение, что-то новое, чего раньше не писали или не делали. Даже если задача стоит вполне тривиальная, то создаваемое программистом решение будет вполне уникальным в своем роде. Как можно помочь разработчику быстрее найти самое лучшее решение поставленной задачи? Да, просто не мешать ему, дать возможность сосредоточиться и полностью сконцентрироваться над задачей. Но как это сделать, когда все сидят друг у друга на голове, постоянно кто-то с кем-то говорит, регулярно проходят какие-то короткие совещания… У каждого действия есть противодействие, у каждого лекарства — побочные эффекты. В данном случае современные методики типа Scrum«лечат» одно, но «калечат» другое, не менее важное — возможность полностью погрузиться в написание кода.

Широко используемая методика спринта (Scrum-sprint) предлагает устраивать краткосрочные, от одного дня до месяца, марафоны. Намечать планируемые результаты и буквально, как солдаты бросаться в атаку, чтобы занять следующую высоту. Секрет в том, что ни каждый командир сможет поднять солдат в атаку, а для организации успешного марш броска нужен еще более опытный командир. Такие методики работы в режиме «аврала» возможны, но они не работают в режиме правила. Невозможно долго работать в режиме маленького подвига, у людей начинает вырабатываться толерантность и каждый новый спринт все сложнее становится организовать, да и люди устают, выгорают и начинают искать другую работу. Решение этой проблемы я предлагаю искать в области психологии. Основная задача, получается в том, чтобы помочь разработчикам войти в состояние потока «flow», а для этого нужно добиться того, чтобы как можно меньше отвлекающих факторов — деструкторов (Distractors) мешало работе. Когда мы находимся в таком состоянии, то мысли текут свободно, ровным потоком, ничего не отвлекает, не мешает работе, все внимание сосредоточено только над выполняемой задачей. Какие-то стандартные рутинные задачи можно выполнять в режиме многозадачности, но для эффективного выполнения интеллектуальной работы, умение войти в такой продуктивный режим критически необходимо.

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

https://cutt.ly/b2UbOXK

Scrum: A visual guide

By Simon Buehring

If you and your team are new to the Scrum methodology, you have come to the right place! We have developed this visual guide to help you understand how the Scrum Methodology works. You can download a poster version of the graphic to print and display in your office! If you think the poster is useful, feel free to use it on your blog and share with your networks.

What is Scrum?

Scrum is probably the most popular agile development framework used for managing product development. Like all other agile frameworks, Scrum boasts flexibility, team collaboration and iterative delivery. This helps teams adapt to changes easily, especially when customers change their minds about what they want.

Follow this visual guide to Scrum and find out how it works (click the image to view it on full screen). You can also download a PDF of this graphic ready for printing. If you’re looking for Scrum training or agile project management training then you can find those from the main menu.

The graphic was created to help you learn about Scrum. If you like it, please show your appreciation by linking back to this page.

1) Select Scrum team

One of the most difficult parts when creating a project is figuring out roles and responsibilities. Begin by identifying the roles people will take for the project.

The three roles on a Scrum team are:

Product Owner

The Product Owner should be someone with authority, availability and vision. They represent the customer and continuously communicate the priorities and vision to the team.

Scrum Master

The Scrum Master acts as a facilitator between the Product Owner and the Development Team. The Scrum Master will also work to remove impediments that may inhibit the Development Team reaching the sprint goal. The person does not, however, provide day-to-day directions or give instructions to the Development Team.

Development Team

The Development Team are self-organized and responsible for developing the product.

Do

• Train or orient your team on Scrum and agile development so that they know the roles they are playing once the sprint starts

Don't

• Force anyone to take on the role of the Scrum Master. This role is important to the entire Scrum process and an unwilling person might not give enough dedication to the project

Top Tip

• Pick a strong Scrum Master. The Scrum Master plays a highly important role in the Scrum process. They ensure that the entire team are focused and have everything they need to get the work done. The Scrum Master is also responsible for removing obstacles that might keep the group from performing optimally or from reaching the deadline. Overall, the Scrum Master determines the success of the whole team.

2) Sprint Planning

Once the roles have been identified, it’s time to start planning the sprint. The whole team decide on a sprint length together, overseen by the Scrum Master. Sprints are typically 2-4 weekly cycles.

Product backlog

The Product Owner creates a product backlog which is essentially a ‘prioritized wish list’. The backlog is owned by the Product Owner, but everyone can add to it. The product backlog contains a list of user stories.

User stories

User stories serve as a guide for the team to show why they are working on something. They speak from the end user perspective and can look something like this:

As a	I want	so that
Music lover	uninterrupted music streaming from my device	it doesn’t use up storage space while letting me play music on the go
Music streaming app user	to receive recommendations based upon my current playlists	I can hear new bands that are suited to my taste

Sprint backlog

The Product Owner presents the highest priority user stories from the product backlog to the Development Team.

The Development Team decide on what they are able complete for the sprint and break user stories into tasks, estimating the effort and transferring them to a sprint backlog.

Definition of “done”

It is essential that the Scrum Master and Product Owner provide a set of acceptance criteria for each user story. Acceptance criteria is what determines whether the user story is complete. It can also be referred to as the definition of “done”.

The table below shows two user stories with two sets of acceptance criteria.

As a	I want	so that	Acceptance criteria
Music lover	A small-sized streaming app with no adverts	it doesn’t use up storage space and interrupt my listening experience	1. App allows user to stream music without downloading 2. App size is 60MB or under 3. App offers premium subscription with no ads
Music streaming app user	to receive recommendations based upon my current playlists	I can hear new bands that are suited to my taste	1. Radio feature created based upon user’s playlists 2. Daily “Have you heard..” notification to be sent to users

Do

• Work on high priorities first
• Break down each user story into small and manageable tasks

Don't

• Bite off more than you can chew. Make sure that no one in the team is committing to more than what is feasible to do in the set timeframe

Top Tip

• Use INVEST to prioritize your user stories. INVEST stands for: I-independent, N-negotiable, V-valuable, E-estimable, S-small, and T-testable

3) The Daily Standup

To make sure that everyone is in sync, the team must meet every day to discuss what they worked on the previous day, what they will work on today and identify any impediments. To make sure that time is used efficiently, the meeting should be timeboxed into a maximum of 15 minutes. The Scrum Master oversees the meetings and makes sure that the team focuses on the subject at hand.

Do

• Use burndown charts to track your progress. A burndown chart shows you how much work remains in your sprint and whether you are on schedule
• Keep the meeting short and concise. Make sure that everyone is speaking straight to the point
• Answer questions like: What have I done since the last Scrum meeting? What do I plan to do before the next meeting? What are the issues I need help with?

Don't

• Bring up topics unrelated to the user stories you’re working on from the backlog

Top Tip

• Don’t cancel a Scrum Meeting, even if you are busy or if the attendance is poor. The Daily Scrum meeting is an essential component to a Scrum project. When you cancel one, it becomes easier to cancel others and this disrupts the team’s focus.

4) Sprint Review

By the end of each sprint, the Development Team should deliver a potentially shippable product increment. In other words, the product increment should be in a useable condition. No incomplete work should be presented during a sprint review.

During a sprint review, the team present what they have accomplished during the sprint. They demonstrate the functionality of the product increment to the Product Owner and customer. The purpose of the sprint review is to get feedback from everyone on the product increment. After the feedback is shared, the next set of product backlog items can be discussed.

Do

• Let everyone provide feedback and suggest new ideas
• Make changes to the product backlog when necessary

Don't

• Use the sprint review as a signoff or user acceptance meeting

Top Tip

• Don’t forget to focus on the end users. Make sure to fully involve them during the sprint review. It may seem difficult collaborating with your customers because of the fear of making changes or hearing criticism, but it is easier to hear everything sooner rather than later.

5) Sprint Retrospective

During a sprint retrospective, the team evaluate the whole sprint. The two main questions that are asked are “what went well?” and “what can be improved in the next sprint?”

Do

• Make a list of what to start, stop, and continue

Don't

• Point fingers or blame. Try to be constructive instead

Top Tip

• Get creative! Play games and keep people moving. Engage in mentally stimulating activities and help to break down tension

6) Product increment

The product increment is the output of all the product backlog items completed during the sprint (plus any previous sprints). It must be fully functional, in a useable condition and meet the allocated acceptance criteria or definition of done. The Product Owner decides whether to release the product increment.

Interim delivery

During an interim delivery, the product increment is tested by the customer. If the product is incomplete, the Development Team return to the product backlog to prepare for another sprint. This cycle repeats until all user stories are completed to the Product Owner’s satisfaction.

Do

• Remember what was discussed during the sprint retrospective and apply it to the next sprint

Don't

• Dwell on past mistakes. Move on and learn from whatever went wrong during the previous sprint

Top Tip

• It’s easy to get caught up in preparing for the next sprint, but don’t forget to celebrate achievements and good results from the previous sprint. This gives you some room to breathe and get pumped up for the next cycle
• Practice makes perfect! If you are new to Scrum, you might not get everything right at the beginning. Learning takes practice and the more you do, the better you will be at using the technique

Final delivery

Completing a project takes several sprints. Once all the user stories are completed to the Product Owner’s satisfaction, the product is ready for final delivery to the customer.

Hopefully this has been a useful guide to the Scrum methodology and whether it would be useful for managing product development in your organization. Some teams like to use Scrum alongside Kanban, a highly visual work management method, also under the agile umbrella.

https://bit.ly/2Vqs4A7