What is a real product and how to organize a product group? Using Yandex Taxi as an example, we analyze the concept of value areas and the importance of end-to-end prioritization.

In my experience, if you have correctly defined the product (or product family), the Product Owner inevitably becomes someone at the Board−1 or Board−2 level (in the worst case). But now that you have a real Product Owner on board, a new problem arises: this person is incredibly busy. How can you relieve their workload? Through delegation. And delegation can be done either to the teams or by creating a Product Owner Team.

Scrum Masters and management, when faced with failures in their initiatives related to multifunctional learning, conclude that people do not want to learn. But people are glad to learn when organizational design supports multifunctional development.

In this article I share the case of mitosis – splitting a large team of 19 people into two independent feature teams working from a single Product Backlog. After the division, I helped the teams create a common identity and agree on norms of conduct. This case is just an episode of Agile transformation in a business unit of several hundred people.

In the quest for short-term gains and rapid productivity, organizations are sacrificing their long-term agility and adaptability, just like the Titanic did. But fear not! We can learn from history and prevent ourselves from meeting the same fate. So, let's explore how companies can avoid becoming the next Titanic and instead chart a course for long-term success.

In a context of an enterprise a cross-functional team is not enough. A concept of a Product Group that extends cross-functional team is helpful. A Product Group is a semi-autonomous unit with P&L responsibility that consists of cross-functional teams, shared functions, systems and roles. Multiple Product Groups in an enterprize optimize for learning and adaptability. They are augmented with shared services that create economies of scale and optimize for efficiency. That's the prototype of an Agile Organization.

The work of solving a complex problem (for example, a feature) with interdependent tasks rarely distributes evenly among the people in a cross-functional team. The solution is a team of multi-skilled specialists. A team of multi-talented people experience fewer bottlenecks as they can help overloaded team members, and therefore reduce the time to solve a complex problem end-to-end. The team develops multi-skilled members by working in three preferred modes: pairing, mob-programming, and swarming continuously. Some other techniques are: StarMap, visualizing the flow of work, and Slack Time.

Working from a single product backlog creates an inevitable knowledge gap in single-skilled team members. Over time, team members develop secondary or even tertiary skills and become multi-skilled specialists. On an organizational level introduce cross-functional managers that focus on the whole team development. Also you need to create a system of human operations that supports multi-skilled specialists.

Fourth blog, in a blog series about the upcoming book: Creating Agile Organizations - A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility. 

What I usually hear is “Scrum is great, but it doesn’t work in my organization, because...” and then follows a list of excuses why change is impossible or hard.

In this article, we shall investigate why the learning and development of multi-functional specialists in Scrum is the core of organizational Agility and value optimization. Many Development Teams are not collaborating as real teams, but as a collection of narrow specialists focused on "their" tasks (QA, Backend, iOS, Android).

Product Backlog Refinement (PBR) is an ongoing process in Scrum. But in a scaled Scrum, complexity vastly increases, and Refinement becomes mandatory. In this article, I will explain how you can use Refinement to your advantage and enhance organizational agility.

This is quite a long read which you can download as the whitepaper "Systems Thinking in Organizational Coaching".

When Scrum Teams discuss too many problems during the Retrospective they may lose focus.

How to start an Agile transformation? What are the initial steps? In this article I explain how transformations could be planned using Scrum Patterns and systems thinking.

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 году Роберт Гринлиф дал рождение парадоксальному термину “лидер-слуга”. Кажется, что слова “лидер” и “слуга” кажутся противоположностями друг другу. Но в этой парадоксальности заложен глубокий смысл. Вот что пишет о "лидере-слуге" Роберт Гринлиф:

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.

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.

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.

Many Scrum Teams use User Stories as a technique for creating their Product Backlog Items (PBIs). But when the teams bring big stories to the Sprint, this causes lots of problems.

How to Teach a Scrum Team to Split Stories  

System optimization: Upgrading Team Competencies When developing complex innovative products, the Development Team will have different a workload for each one of their members.

Open Space is one of the methods that allows organizations to make inspirational meetings and events. I was lucky enough to use Open Space in various contexts, with Scrum Teams. The concept has always worked.

When multiple Scrum Teams are working on one product, shared DoD becomes necessary. DoD helps to ensure that each increment is transparent by the end of every Sprint and creates a shared understanding of what “Done” means.

In this article, I suggest that you take a look at the role of a Scrum Master with a help of causal loop diagrams. They help to see a bigger picture of what is happening over time. Quite often, we observe the cause-and-effect relationships on a short-time horizon period, and do not notice when the links are spaced in time.

In Scrum, the Product Owner is an entrepreneur and the mini-CEO of a product, who is able to make fast decisions. The success of the Scrum Team and company as a whole depends on whether the Product Owner is real.

Most of the Agile transformations I have witnessed have started like this: First, a company raises a strategic initiative on so-called Agile implementation. A large budget is allocated and a tender is arranged to purchase Agile coaching services from companies on the market. Then employees are trained, and the pilot teams start working. However, they immediately stall, because there is lots of tension between them and an old cultural landscape.

The Sprint Goal is an important part of Scrum. It's like a burning torch that unites the Development Team and helps it move forward during the Sprint.

I work with a lot of companies that are learning to use Scrum as a tool for agility driver. Recently, I spotted a trend: if a Scrum Team cannot articulate their Sprint Goal, the problem quite often lies with the Product Backlog.

Many of those practicing Scrum mistakenly call the Sprint Review a Demo. Is it just a matter of terminology? From my point of view, the Sprint Review is the most underestimated Scrum Event, and for many companies, its potential is yet to be revealed. It is true that the Demonstration or Demo is an essential part of the Sprint Review, but it isn't the only one.

When talking about Scrum, people often imagine the picture above: framework and its roles, artifacts, and events. Scrum rules are fairly simple, and they are thoroughly described in the Scrum Guide.

Do you want to pass a small test? It is very simple - please reproduce in the exact sequence literally four values of ​​Agile Manifesto.

The ability to create high-quality and attractive flip charts is one of the basic skills of any facilitator.

He could have wept tin tears, but that would not have been right. He looked at her and she looked at him, but neither spoke a word.

“A Scrum Master’s practical toolbox” offers o

I decided to conduct a Temperature Reading Sprint Retrospective after watching the video from one of the workshops of a famous American family therapist Virgi

People love stories. We love telling and listening to interesting stories. The need for this is embedded deeply by the nature. The first stories were told by our ancestors and can be seen in the preserved rock paintings.

We shall talk about the most important, from my point of view, team’s trait - Helping Each Other. After discussion I will give you a powerful game that can help you to foster and promote real “one for all, all for one” team spirit.