How to explain to granny what Agile is in 15 minutes with pictures
“Any business always lasts longer than expected, even considering Hofstadter’s law.”
- Hofstadter's law
The most watched YouTube video on agile. 744,625 views at the time of publication of this article. Easy writing style, pictures and only 15 minutes - the best I've seen. TED is resting.
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 are making the product, what problems it 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 stakeholders. For example, "the user must have a flight search at the ticket booking system."
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 until a large release, on the contrary, they release them immediately and as often as possible. Usually they release 4-6 user stories per week. This is their bandwidth . It is 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 and continuous integration. Therefore, it is necessary to write autotests for every feature, and most of the code has built-in autotests.
The problem is that there are a lot of stakeholders and their requests cannot be satisfied with 4-6 stories per week.
Every time we implement a user story, they have a few more ideas, from which even more queries flow.
Suppose a team takes 10 new stories this week. If input 10 and output 4-6, the team will be overloaded. It will hurry, switch between tasks, lose motivation, as a result, productivity and quality decrease. This is a losing strategy.
Scrum and XP in this case use the “yesterday weather” method. The team says, “We’ve done 4-6 features a week lately, what 4-6 features are we going to do next week?”
The task of the product owner is to correctly select which user stories will be implemented this week.
Kanban recommends limiting it to several tasks - WIP limit. Suppose the team decides that 5 is an acceptable number of user stories, on which they can work simultaneously without overloading, without jumping from one to another.
Both of these approaches work well and both of them create a queue of tasks, which in Scrum is called Backlog, or a prioritized list of tasks.
This queue must also be managed. If interested parties request 10 stories per week, and the team implements 4-6 stories, then this queue will become more and more. And soon your backlog will be scheduled six months ahead. That is, one story will wait for the release of 6 months.
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 the more important task is to decide what not to do and bear responsibility for it. The product owner also determines the sequence of what we are doing now and what later. This is a difficult job and should be done 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 volume.
Some stories are badly needed, and some are just bonus features. It will take a couple of hours to develop some stories, months to develop others.
How does the size of the story and its value relate? No No longer means better. The value and complexity of the task - this is what helps Pat to prioritize.
How does the product owner determine the value and volume of the story? No This is 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 amount of work, but all this is approximate guesses, no exact figures. There will always be blunders in the beginning and that's fine. Communication is much more valuable than ultra-precise numbers.
Every time when developers release something new, we will 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 can be done in a couple of days. We want small and clear stories at the beginning of the funnel and large and indefinite at the end. In time to make such a breakdown, we can take advantage of our latest discoveries regarding the product and user needs. This is all called backlog cleaning.
Pat holds a meeting to clean up the Backlog every Wednesday from 11 to 12. Usually the whole team and sometimes several interested people gather at it. The content of the meetings is different. Focus on evaluation, on a breakdown of stories, on acceptance criteria.
Solid product owners distinguish 2 components of success: passion for work and communication. What tasks the owner of the product solves the place with the team.
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 have time and will there be enough money?"
Knowledge can be considered as the opposite of risk. When uncertainty is big, we focus on acquiring knowledge — interface prototypes, technical experiments,
From the point of view of the customer, the curve looks like this:
In terms of customer value, this curve looks like this. As uncertainties are reduced, we can concentrate on customer values. We know what to do and how. It remains only to do. After the main stories have been implemented, we will make bonus features or launch a new project.
What to implement first? Urgently fix bugs or start developing a stunning feature that will amaze users. Or do a complex platform upgrade that will speed up work in the future. It is necessary to constantly maintain a balance between reactive and proactive work.
Ideally, all three are at the same time, but in reality you have to choose.
Suppose we are here. We are trying to create the perfect product using the perfect 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 product prototype. For the short term, this is not bad. In the long term - we get technical risk. And the speed of development will decrease to zero.
or
We are here, creating a beautiful temple in record time. But the user did not need a temple, he needed a caravan.
The product owner focuses on building the right things. The team focuses on building things right. A scrum master or agile trainer focuses on reducing the feedback cycle.
Separately, it is worth emphasizing the importance of speed, as a short feedback loop speeds up learning. This allows us to quickly find out what things are right and how to build them correctly.
A product can never be fully completed because it constantly needs changes. When a team starts working on a new product, what happens to the old one? Transferring a product from one team to another is very expensive and risky. Usually the team supports the old product by 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 that the product owner wants from the team. And a set of stories for different products. The owner of the product must constantly choose relevant for implementation.
From time to time, interested parties will ask Pat: “When will they release my feature?” Or “How many features will they release by Christmas?”. The product owner must be able to manage user expectations. And manage expectations realistic.
Two trends - optimistic and pessimistic (you can by eye). The distance between 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 fixed content and indefinite issue. Pat uses two trend lines to answer. The answer is in April or May.
The interested party asks Pat: “How much will be done by Christmas?” This is a fixed term question with uncertain content. The trend lines cut off on the vertical scale the likely segment of what they have time to implement.
The interested person asks: “Will we have time to make these features by Christmas?” This is a question with fixed time frames and fixed content. Focusing on trends, Pat responds: “No.” Adding: "By Christmas we will have time to do so much, but it will take us so much time to complete all this work completely."
It is usually better to reduce the content of the project than to increase the time If we reduce the content, we will have the opportunity to postpone the deadlines. We can release something here and the rest later.
The owner of the product does the calculations weekly and uses only empirical data, and does not wish out what is desired. He honestly talks about uncertainty. The team maintains the pace of work, and Pat does not press on them, forcing them to accelerate.
Let us have several product owners and several teams. The model is the same - bandwidth management, communication with stakeholders, making decisions about the rejection of user stories. The speed is equal to the sum of the speeds of all the teams. Prediction can be general or per team. Product owners have an extra challenge — communicating with other product owners. We need to organize the work on Backlogs so as to minimize dependencies and ensure synchronization. In large projects, the Main Product Owner (CPO) is required to synchronize all others.
Big picture
Source - Agile Product Ownership in a nutshell
November 2 - the most IT day of the year
Publication support is Edison , which develops electronic ticket sales systems and a federal catalog of goods and services .
And this is how Edison develops products using a flexible methodology:
- Hofstadter's law
The most watched YouTube video on agile. 744,625 views at the time of publication of this article. Easy writing style, pictures and only 15 minutes - the best I've seen. TED is resting.
Roles
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 are making the product, what problems it 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 stakeholders. For example, "the user must have a flight search at the ticket booking system."
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.
Bandwidth
Since the team uses a flexible development methodology , they do not save all these stories until a large release, on the contrary, they release them immediately and as often as possible. Usually they release 4-6 user stories per week. This is their bandwidth . It is 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 and continuous integration. Therefore, it is necessary to write autotests for every feature, and most of the code has built-in autotests.
The problem is that there are a lot of stakeholders and their requests cannot be satisfied with 4-6 stories per week.
Every time we implement a user story, they have a few more ideas, from which even more queries flow.
What happens if we do everything they ask of us? We will have an overload.
Suppose a team takes 10 new stories this week. If input 10 and output 4-6, the team will be overloaded. It will hurry, switch between tasks, lose motivation, as a result, productivity and quality decrease. This is a losing strategy.
Scrum and XP in this case use the “yesterday weather” method. The team says, “We’ve done 4-6 features a week lately, what 4-6 features are we going to do next week?”
The task of the product owner is to correctly select which user stories will be implemented this week.
Kanban recommends limiting it to several tasks - WIP limit. Suppose the team decides that 5 is an acceptable number of user stories, on which they can work simultaneously without overloading, without jumping from one to another.
Both of these approaches work well and both of them create a queue of tasks, which in Scrum is called Backlog, or a prioritized list of tasks.
This queue must also be managed. If interested parties request 10 stories per week, and the team implements 4-6 stories, then this queue will become more and more. And soon your backlog will be scheduled six months ahead. That is, one story will wait for the release of 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 the more important task is to decide what not to do and bear responsibility for it. The product owner also determines the sequence of what we are doing now and what later. This is a difficult job and should be done 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 volume.
Making decisions
Some stories are badly needed, and some are just bonus features. It will take a couple of hours to develop some stories, months to develop others.
How does the size of the story and its value relate? No No longer means better. The value and complexity of the task - this is what helps Pat to prioritize.
How does the product owner determine the value and volume of the story? No This is 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 amount of work, but all this is approximate guesses, no exact figures. There will always be blunders in the beginning and that's fine. Communication is much more valuable than ultra-precise numbers.
Every time when developers release something new, we will 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 can be done in a couple of days. We want small and clear stories at the beginning of the funnel and large and indefinite at the end. In time to make such a breakdown, we can take advantage of our latest discoveries regarding the product and user needs. This is all called backlog cleaning.
Pat holds a meeting to clean up the Backlog every Wednesday from 11 to 12. Usually the whole team and sometimes several interested people gather at it. The content of the meetings is different. Focus on evaluation, on a breakdown of stories, on acceptance criteria.
The owner of the IT product must constantly communicate with everyone
Solid product owners distinguish 2 components of success: passion for work and communication. What tasks the owner of the product solves the place with the team.
Balance between design complexity and user story value
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 will there be enough money?"
Knowledge can be considered as the opposite of risk. When uncertainty is big, we focus on acquiring knowledge — interface prototypes, technical experiments,
The trade-off between knowledge values and customer values
From the point of view of the customer, the curve looks like this:
In terms of customer value, this curve looks like this. As uncertainties are reduced, we can concentrate on customer values. We know what to do and how. It remains only to do. After the main stories have been implemented, we will make bonus features or launch a new project.
The trade-off between short-term and long-term thinking
What to implement first? Urgently fix bugs or start developing a stunning feature that will amaze users. Or do a complex platform upgrade that will speed up work in the future. It is necessary to constantly maintain a balance between reactive and proactive work.
Do the right thing, do the right thing, or do it quickly?
Ideally, all three are at the same time, but in reality you have to choose.
Suppose we are here. We are trying to create the perfect product using the perfect 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 product prototype. For the short term, this is not bad. In the long term - we get technical risk. And the speed of development will decrease to zero.
or
We are here, creating a beautiful temple in record time. But the user did not need a temple, he needed a caravan.
There is a healthy confrontation between roles in Scrum.
The product owner focuses on building the right things. The team focuses on building things right. A scrum master or agile trainer focuses on reducing the feedback cycle.
Separately, it is worth emphasizing the importance of speed, as a short feedback loop speeds up learning. This allows us to quickly find out what things are right and how to build them correctly.
The trade-off between the development of a new product and the improvement of the old
A product can never be fully completed because it constantly needs changes. When a team starts working on a new product, what happens to the old one? Transferring a product from one team to another is very expensive and risky. Usually the team supports the old product by 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 that the product owner wants from the team. And a set of stories for different products. The owner of the product must constantly choose relevant for implementation.
History Destruction Schedule
From time to time, interested parties will ask Pat: “When will they release my feature?” Or “How many features will they release by Christmas?”. The product owner must be able to manage user expectations. And manage expectations realistic.
Two trends - optimistic and pessimistic (you can by eye). The distance between 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 fixed content and indefinite issue. Pat uses two trend lines to answer. The answer is in April or May.
The interested party asks Pat: “How much will be done by Christmas?” This is a fixed term question with uncertain content. The trend lines cut off on the vertical scale the likely segment of what they have time to implement.
The interested person asks: “Will we have time to make these features by Christmas?” This is a question with fixed time frames and fixed content. Focusing on trends, Pat responds: “No.” Adding: "By Christmas we will have time to do so much, but it will take us so much time to complete all this work completely."
It is usually better to reduce the content of the project than to increase the time If we reduce the content, we will have the opportunity to postpone the deadlines. We can release something here and the rest later.
The owner of the product does the calculations weekly and uses only empirical data, and does not wish out what is desired. He honestly talks about uncertainty. The team maintains the pace of work, and Pat does not press on them, forcing them to accelerate.
Several teams
Let us have several product owners and several teams. The model is the same - bandwidth management, communication with stakeholders, making decisions about the rejection of user stories. The speed is equal to the sum of the speeds of all the teams. Prediction can be general or per team. Product owners have an extra challenge — communicating with other product owners. We need to organize the work on Backlogs so as to minimize dependencies and ensure synchronization. In large projects, the Main Product Owner (CPO) is required to synchronize all others.
Big picture
Source - Agile Product Ownership in a nutshell
English video
video in Russian
Read more
November 2 - the most IT day of the year
Publication support is Edison , which develops electronic ticket sales systems and a federal catalog of goods and services .
And this is how Edison develops products using a flexible methodology:
Source: https://habr.com/ru/post/313410/
All Articles