How to explain to grandma what is Agile in 15 minutes with pictures

Roles

This is Pat, the owner of the product. She does not know the technical details, but she has a vision of the general picture, she knows why we make the product, what problems he will solve and for whom.

These are interested parties. They will use the product, support it or will somehow be involved in the development.

These are user stories. They expressed the wishes of interested persons. For example, "the airline booking system must have a search for flights."

Stakeholders have a lot of ideas, and Pat helps make user stories out of ideas.

This is the development team. Those who will build a working system.

Throughput

Since the team uses a flexible development methodology, they do not save all these stories to the big release, on the contrary, they release them immediately and as often as possible. Usually they release 4-6 user stories a week. This is their bandwidth. It's very easy to measure - the number of user stories in 7 days.

Some stories are big, they can be counted as two, some are small, they can be counted as half.

In order to maintain this rhythm and not to get bogged down in manual regression testing, the team is working hard on automatic testing of constant integration. Therefore, for every feature you have to write autotests, and most of the code has built-in autotests.

The problem is that there are a lot of interested persons and their requests can not be satisfied by 4-6 stories a week.

Every time we implement a custom story, they have a few more ideas, from which even more requests follow.

What will happen if we do everything they ask of us? We will have an overload.

Let's say the team will take 10 new stories for this week. If the input is 10 and the output is 4-6, then the team will be overloaded. It will hurry, switch between tasks, lose motivation, in the end productivity and quality decrease. This is obviously a losing strategy.

Scrum and XP in this case use the "yesterday's weather" method. The team says: "Lately we have done 4-6 features a week, what are the 4-6 features we will be doing next week?"

The task of the product owner is to select competently which user stories will be implemented this week.

Kanban recommends that you limit yourself to several tasks - WIP limit. Suppose the team decides that 5 is an acceptable number of user stories, over which they can work simultaneously without overloading, without jumping from one to another.

Both of these approaches work well, and they both create a task queue, which in Scrum is called Backlog, or a prioritized task list.

This queue also needs to be managed. If interested persons request 10 stories a week, and the team implements 4-6 stories, then this queue will become more and more. And soon your Backlog will be painted for six months ahead. That is, one story will wait for 6 months.

There is only one way to keep a list of tasks under control - this is the word "no"

This is the most important word for the owner of the product. He must train him every day in front of the mirror.

Saying "yes" is easy. But a more important task is to decide what not to do and to bear responsibility for it. The owner of the product also determines the sequence of what we are doing now, and what happens later. This is a difficult job and should be done together with the development team and at least one interested person.

In order to properly prioritize, the owner of the product must understand the value of each story and its scope.

Making decisions

Some stories are extremely necessary, and some are just bonus features. The development of some stories will take a couple of hours, the development of others - months.

How does the size of the story correlate with its value? No way.

Does not mean better anymore. The value and complexity of the task - that's what helps Pat prioritize.

How does the owner of the product determine the value and volume of the story? No way.

It's a guessing game. And it is better to participate in it all. Pat constantly communicates with stakeholders to know the value of each story, communicates with the development team to know the scope of the work, but all this is an approximate guess, no exact figures. In the beginning there will always be misses and this is normal. Communication is much more valuable than super-accurate figures.

Every time when developers release something new, we learn more information and can better navigate.

One prioritization is not enough. To release stories quickly and often, you need to break into pieces that you can do in a couple of days. We want the funnels at the beginning to have small and clear stories and at the end - big and vague. In time to make such a breakdown, we can take advantage of our latest discoveries regarding the product and the needs of the user. This is all called cleaning the Backlog.

Pat holds a meeting to clean up the Backlog every Wednesday from 11 to 12. Usually it is going to the whole team and sometimes a few interested persons. The content of the meetings varies. Focusing on evaluation, on breakdown of stories, on acceptance criteria.

The owner of the IT product must constantly communicate with all

Mature owners of the product distinguish 2 components of success: a passion for work and communication. What tasks the product owner decides the place with the team.

The balance between the complexity of development and the value of user history

At an early stage, the balance is threatened by uncertainty and several risks at once.

Risks

• Business risk: "Are we doing the right thing?"
• Social risk: "Can we do what we need?"
• Technical risk: "Will the project work on this platform?"
• Risks with the cost and timing of implementation: "Will we have time and money?"

Knowledge can be seen as the opposite of risk. When the uncertainty is large, we focus on acquiring knowledge - interface prototypes, technical experiments.

Compromise between values ​​of knowledge and values ​​for the client

From the point of view of the customer, the curve looks like this:

In terms of value for the customer, this curve looks like this.

As uncertainties decrease, we can concentrate on values ​​for the customer. We know what and how to do. It remains only to do. After we have implemented the main stories, we will do bonus features or launch a new project.

Compromise between short-term and long-term thinking

What to implement first? Urgently fix errors or start to develop a stunning feature that will amaze users. Or make a sophisticated platform upgrade that will speed up the work in the future. It is necessary to constantly maintain a balance between reactive and proactive work.

Do the right things, do things right or do fast?

Ideally - all three at the same time, but in reality you have to choose.

Suppose we are here. We are trying to create an ideal product with the help of an ideal architecture. If we spend a lot of time, we can not get into the "marketing window" and we will have problems with money. Or:

We make a quick prototype product. For a short-term perspective, this is not bad. In the long run, we get technical risk. And the development speed will drop to zero. Or:

We are here, we create a wonderful temple in record time. But the user did not need a temple, he needed a living van.

Between roles in Scrum there is a healthy confrontation

The owner of the product focuses on building the right things. The team focuses on building things correctly. Scrum-master or agile-trainer focuses on reducing the feedback cycle.

Separately, it is worth emphasizing the importance of speed, so as a short feedback loop speeds up training. This allows us to quickly find out which things are right and how to build them correctly.

Compromise between developing a new product and improving the old

The product can never be completely completed, because it constantly needs changes. When the team begins work on a new product, what happens to the old one? The transfer of the product from one team to another is very expensive and risky. Usually the team supports the old product, developing a new one. Therefore, rather the concept of "Backlog" refers not to the product but to the team. Backlog is a list of things a product owner wants from a team. And a set of stories for different products. The owner of the product must constantly choose the actual for implementation.

A schedule for destroying stories

From time to time, interested persons will ask Pat: "When will they release my feature?" Or "How many features will be released by Christmas?". The owner of the product must be able to manage the user's expectations. And to manage expectations is realistic.

Two trends - optimistic and pessimistic (you can by eye). The distance between the trends shows how unstable the speed of the team. Over time, these trends will stabilize and the cone of uncertainty will decrease.

Suppose an interested person asks when this feature will be done?

This is a matter with fixed content and an indefinite period. To answer, Pat uses two trend lines. The answer is in April or May.

The interested person asks Pat: "How much will be done by Christmas?" This is a fixed-term issue with uncertain content. The lines of the trend cut off on the vertical scale a likely segment of what will be realized.

The interested person asks: "Do we have time to do these features for Christmas?" This is a question with fixed timeframes and fixed content. Focusing on trends, Pat replies: "No". Adding: "By Christmas we will have time to do so much, but for so long we will need to complete all this work completely."

It is usually better to reduce the contents of a project than to increase the time. If we reduce the content, we will have the opportunity to postpone the time. We can release something here, and the rest later.

The owner of the product makes the calculations weekly and uses only empirical data, and does not give out the wishful thinking. He is honest about uncertainty. The team maintains the pace of work, and Pat does not press on them, forcing to accelerate.

Several commands

Let's have several product owners and several teams. The model is the same - bandwidth management, communication with stakeholders, decision-making about the rejection of user stories. Speed ​​is the sum of the speeds of all teams. Forecasting can be general or for each team. The owners of products have an additional task - to communicate with other owners of the product. It is necessary to organize work on Backlogs so as to minimize dependencies and provide synchronization. In large projects, the Chief Product Owner (CPO) is required to synchronize all the others.

Video in English

Video in Russian