How to explain to grandma what is Agile in 15 minutes with pictures
Flexible development methodology (Agile software development, agile-methods) is a series of approaches to the development of software, focused on the use of iterative development, the dynamic formation of requirements and ensuring their implementation as a result of constant interaction within self-organizing working groups consisting of specialists of various profiles. There are several methods related to the class of flexible development methodologies, in particular, extreme programming, DSDM, Scrum, FDD.
It is used as an effective practice of organizing the work of small groups (who do homogeneous creative work) in combining with their management a combined (liberal and democratic) method. Most flexible methodologies are aimed at minimizing risks by bringing development to a series of short cycles, called iterations, which usually last two to three weeks. Each iteration in itself looks like a software project in miniature and includes all the tasks necessary to produce a mini-increase in functionality: planning, requirements analysis, design, programming, testing and documentation. Although a single iteration is usually not enough to release a new version of the product, it is understood that a flexible software project is ready for release at the end of each iteration. At the end of each iteration, the team reassesses the development priorities.
Agile methods emphasize direct face-to-face communication. Most agile teams are located in the same office, sometimes called English. bullpen. At a minimum, it also includes "product owners" (the customer or his authorized representative that defines the product requirements, which role can be performed by the project manager, business analyst or client). The office may also include testers, interface designers, technical writers and managers. The main metric of agile methods is the work product. Preferring direct communication, agile-methods reduce the amount of written documentation in comparison with other methods. This led to criticism of these methods as undisciplined.
The most viewed video on YouTube on agile. 744 625 views at the time of publication of this article. Easy style of presentation, pictures and only 15 minutes - the best I've seen. TED rests.
"Any business always lasts longer than expected, even if we take into account Hofstadter's law." - Hofstadter's law
This is Pat, the owner of the product. She does not know the technical details, but she has a vision of the overall picture, she knows why we make the product, what problems he will solve and for whom.
They are interested persons. 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 custom stories out of ideas.
This is the development team. Those who will build a working system.
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 each 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 with 4-6 stories a week.
Every time we implement a custom story, they have a few more ideas, from which more requests follow.
What happens 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 at input 10 and at the output of 4-6, the command 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've been doing 4-6 features a week, which 4-6 features will we 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 it should be done together with the development team and at least one interested person.
In order to properly prioritize, the product owner must understand the value of each story and its scope.
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.
It does not mean better anymore. The value and complexity of the task is 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 approximate guesses, 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 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 several stakeholders. The content of the meetings is different. Focusing on evaluation, on breaking down 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 to 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.
- 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 make it and will we have enough 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 the 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 in the first place? Urgently fix errors or start developing 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 may not get into the "marketing window" and we will have problems with money. Or:
We make a quick prototype product. For a short-term outlook, 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 cycle of feedback.
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.
Schedule of 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 product owner must be able to manage the user's expectations. And manage the expectations realistically.
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 trend lines cut off on the vertical scale a possible segment of what they will be able to realize.
The interested person asks: "Will we be able 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 content 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 wishful thinking. He is honest about uncertainty. The team maintains the pace of work, and Pat does not put pressure on them, forcing them to accelerate.
Let's have a few 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. 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
Via Agile Product Ownership in a nutshell & habrahabr.ru & wiki