ILLIA Pavlichenko

In this article we will investigate how an effective Product Backlog refinement can be conducted in Scrum.

Teams are becoming the fundamental organizational entity, individual responsibility is being replaced by that of the team. But responsibility does not come about all by itself.

In this article, I will discuss the dangerous dynamic that can arise when a Product Owner, Scrum Master, or the management of an organization focuses a Development Team on velocity.

The Development Team is both self-organizing and cross-functional and by the end of each Sprint provides an increment that is ‘done’ and releasable. The team defines how to organize work in a Sprint.

Это первая из серии статей, в которых мы вместе будем исследовать вопрос узких специалистов в Скрам-командах, теорию очередей, системную/локальную оптимизации и обучение в командах.

В 1970 году Роберт Гринлиф дал рождение парадоксальному термину “лидер-слуга”. Кажется, что слова “лидер” и “слуга” кажутся противоположностями друг другу. Но в этой парадоксальности заложен глубокий смысл. Вот что пишет о "лидере-слуге" Роберт Гринлиф: Как определяется успех лидера-слуги? Роберт Гринлиф считает, что лишь два вопроса определяют успех лидера-слуги. На чем фокусируется лидер-слуга Генри Блэкеби, один из учеников Робера Гринлифа, невероятно красиво формулирует фокусы лидера-слуги: Улучшать жизни людей, с которыми работаешь, воодушевляя, помогая и благословляя их. Создавать организации, которые не только достигают своих миссий, но и несут пользу всем, кто с ними связан: работникам, инвесторам и клиентам. Термин “Скрам-мастер” выбран неслучайно Как и термин “лидер-слуга”, роль Скрам-мастера нова и во многом непонятна для организаций. Авторы Скрама называет Скрам-мастера “лидером-слугой” и определяют три направления, по которым Скрам-мастер осуществляет свой сервис: Сервис для Команды Разработки. Сервис для Владельца Продукта. Сервис для Организации. Зачем нужно было придумывать новое название роли? Ответ можно найти в книге Agile Project Management With Scrum. Какие качества определяют лидера-слугу Мне очень близка модель SELFLESS из "Servant Leadership in Action": (S)trength/Сила: - Быть целеустремленным, неунывающим. - Быть непоколебимым, защищая ценности (Скрама) и нетерпимым в случае их нарушения. - Быть уверенным в себе, но не заносчивым. (E)nthusiasm/Энтузиазм: - Преданность большей цели и выбранному пути дает бесконечный источник энергии. - Скрам-мастер подключается к бесконечному источнику энергии и черпает в нем силы. (L)ong-Term Orientation/Долгосрочная перспектива: - Организации могут быть вечными. Их жизнь зависит от решений, которые принимаются лидерами. - Успех лидера лучше всего оценивать тем, что происходит после его ухода. (F)lexibility/Гибкость: - Использование разнообразных подходов в зависимости от ситуации. - Умение адаптироваться к любым обстоятельствам, сохраняя при этом преданность ценностям Скрама. (L)ove/Любовь: - Заботиться о людях и иметь четкое понимание того, что хорошо, а что плохо. - Противоположность страху. Организации, переполненные им, не могут быть креативными и инновационными. - Создание безопасного пространства, внутри которого каждый может расти и процветать. (E)motional Intelligence/Эмоциональный интеллект: - Объединяет в себе осознанность (понимание себя) и эмпатию (способность понимать и чувствовать то, что чувствуют другие). - Важна в организациях из-за большого количества стейкхолдеров, с которыми мы коммуницируем. - Мы узнаем о себе больше, когда начинаем понимать свои эмоции и причины их возникновения. (S)ystem Intelligence/Системный интеллект: - Системное мышление фокусируется на взаимодействии частей большей системы и как системы работают в контексте большей организации. - Понимать корневые причины проблем и то, как они связаны с организационным дизайном и культурой. - Предлагать фундаментальные решения вместо симптоматических быстрых решений. (S)piritual Intelligence/Душевный интеллект - Моральный интеллект, который нам помогает отличать хорошее от плохого. - Выстраивать и соединять организации в соответствии с высшими целями и предназначением. - Помогает нам соединиться с нашими глубинными смыслами, ценностями и высшей мотивацией. Основные мысли статьи: Лидер-слуга в первую очередь слуга, и лишь затем лидер. Успех лидер-слуги определяется успехом других. Лидер-слуга создает организации, которые не только достигают своих миссий, но и несут пользу всем, кто ними связан: работникам, инвесторам и клиентам. Термин Скрам-мастер является символом радикальных изменений в подходе к управлению. Качества, определяющие лидера-слугу (Скрам-мастера) SELFLESS: Сила, Энтузиазм, Долгосрочная перспектива, Гибкость, Любовь, Эмоциональный интеллект, Системный интеллект, Душевный интеллект. Что вы думаете о модели SELFLESS? Находит ли она отклик у вас? Как вы можете на постоянной основе улучшать жизни тех, кому вы служите, как Скрам-мастер? Хотите узнать больше о лидере-слуге, модели SELFLESS и роли Скрам-мастера? Расписание сертификационных тренингов Professional Scrum Master (PSM) можно найти здесь.

Big organizations use Scrum as a driver of agility. But often after launching, management start focusing on the speed of development instead of quality. DoD is often weak and the company's agility is reduced as a result. In this article we will use system diagrams to analyze the reasons why it happens and why DoD defines agility. DoD defines frequency of releases Perhaps I was out of luck but in big organizations like banks, I did not meet a lot of Scrum Teams that could ship end-2-end features to the market every Sprint. There are a lot of reasons for it, e.g. a large number of architectural components, functional fragmentation of the organization, a culture of narrow specialists, a large technical debt, etc. Often the initial DoD is weak and the amount of Undone work required to release a batch of features is significant. According to their current DoD, Teams work from Sprint by Sprint closing PBIs, but just before the release, they stop the development to perform some preparation activities sometimes called stabilization. Another situation is when some other organizational unit does the Undone work, e.g. performance testing department, etc. The stronger the DoD, the less time you need for stabilization, the more often the Product Owner can release increment. If the stabilization and the Undone work is close to zero, the Scrum Team can release the increment every Sprint or even more frequently without any delays to the customers. DoD defines agility The more releases you have, the more potential knowledge about the market and what is valuable you can get. Accordingly, the Product Owner may change the ordering of the Product Backlog Items and adapt the product. Conducting an intensive dialog between the Scrum Team and outside environment could be called an organizational agility. The only way for the Scrum Team to deliver value is to release Understanding that enhancing DoD leads to more frequent releases and improved agility,. The Scrum Team can enhance DoD further. And here, we have a reinforcing loop: DoD defines the quality of feedback during Sprint Review Release is the only way to actually deliver value but not the only way to get feedback. The Scrum Team gets feedback from the stakeholders during the Sprint Review. DoD ultimately defines the quality of that feedback. Imagine on one hand you bring a paper prototype, another case you demonstrate a releasable increment and ask for the feedback. Resume DoD defines the frequency of releases and the organizational agility. DoD defines the feedback quality during the Sprint Review. The Scrum Team should strive for enhancing DoD. The perfection vision for the Scrum Team is to deliver valuable increment to the clients at least once per Sprint without any delays.

Dear friends, I want to share an unusual view of Scrum with you. Perhaps you've never thought about such a point of view before. I hope it will be useful.

If you worked in large organizations you have probably heard about the term "dependencies". I am convinced that dependencies need to be eliminated, not managed. With a help of system diagrams in this article, I will uncover the main reasons why Scrum Teams suffer from dependencies, how they impact organizational agility, and what the fundamental solutions to this issue are. How dependences inhibit Teams progress The more dependencies, the less chances the feature will be done by the end of the Sprint. Thus, the more time it takes for the feature on average to go from Product Backlog queue to the market (cycle time). As a result, agility is reduced because the organization is unable to deliver potential value to the market quickly. This causes organizational stress. A typical management response to organizational stress is "divide and conquer". For instance, if there is a problem with the quality, let's create a separate department “quality control” with set of its own KPIs. Creating new functions, units, component teams and coordination roles, managers strengthen the fragmentation of the organization. More fragmentation leads to even more dependencies. High average cycle time makes the organization less agile. But Scrum Teams should not have any dependencies! Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Guide 2017 Why dependencies exist From my long experience working with large organizations I see a few reasons why the dependences thrive: Imperfect organizational design based on component teams ( "bus team", "analytics team", "Android Team", “integration team”). It causes intensive fragmentation. Incomplete cross-functionality (lack of one or more skills). Unreasonable complicated architectural design ( f.e. "there are 256 systems in our organization"), which inhibits creation of cross-component and cross-functional Scrum Teams. How to get rid of dependences The dependencies issue could be solved in two ways: with quick fixes or fundamental long-term solutions. The quick fix is to visualize and manage the dependencies. E.g. creating additional coordination roles or using specific techniques ("ropes on the boards"). Yes, it somehow helps to survive and continue the movement. You become an artist of the visualization and dependency management. Your work looks similar to this: The fundamental solution is to eliminate the fundamental issues completely by: training people making the complicated architecture simpler, reducing the number of components changing organizational design and forming cross-component cross-functional Scrum Teams (Feature Teams) In this case the board for the scaled Scrum could look much better (no dependencies): Feature Teams do not need the ropes because there are no dependencies or they are trivial. Let’s get back to the system diagramming. On one hand, we have a cycle explaining the rise of dependencies, on the other hand it is a quick fix of the problem, then a fundamental solution cycle and the final cycle of forming a culture of managing dependencies when time passes. The bad news is that a strong culture of “managing dependencies” will hinder the implementation of the fundamental solutions. Key Ideas: The more dependencies the less agile organization becomes. Dependencies thrive because of the unnecessarily complex architecture, lack of skills, and suboptimal organizational design (component teams). Creating additional roles and using dependencies management practices do not eliminate the fundamental issues. Fundamental solutions are simplification of the architecture, Feature Teams and, training people. Do you manage dependences or want to eliminate them? Scrum ON!

I often use innovative games as a useful addition for Sprint Reviews. They help clients better understand and thus improve the product. One of my favourite games is the Speed Boat. The Speed Boat game explores user’s pains and jobs.