How to explain to Grandma what Agile is in 15 minutes with pictures
Agile software development agile methods (agile methods) are a series of software development approaches focused on the use of iterative development, dynamically forming requirements and ensuring their implementation as a result of constant interaction within the self-organizing working groups consisting of specialists in various fields. 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 (which do homogeneous creative work) in conjunction with their management by the combined (liberal and democratic) method. Most of the flexible methodologies are aimed at minimizing risks by reducing 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 for issuing a mini-gain in functionality: planning, requirements analysis, design, programming, testing and documentation. Although a separate iteration is usually not sufficient to release a new version of a product, it is assumed that a flexible software project is ready for release at the end of each iteration. At the end of each iteration, the team reevaluates 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 includes “customers” (the product owner is the customer or his authorized representative, who defines the requirements for the product; this 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. By giving preference to direct communication, agile methods reduce the amount of written documentation compared to other methods. This led to the criticism of these methods as undisciplined.
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.
"Any business always lasts longer than expected, even if we take into account the Hofstadter's law." - Hofstadter's law
This is Pat, the owner of the product. She does not know the technical details, but she has the 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 a team of developers. Those who will build a working system.
Since the team uses a flexible development methodology, they do not save all these stories until a big 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 each 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 “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 be responsible 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 an approximate guess, 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 use 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 identify 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.
- 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 value to the customer, this curve looks like this.
As uncertainties diminish, we can focus 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 in the first place? 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 can not get into the "marketing window" and we will have problems with money. Or:
We make a quick prototype of the product. 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 a product owner wants from a 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 question with an indefinite period. 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 contents 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 give out wishful thinking. 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 additional 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.
Video in English
video in Russian
Via Agile Product Ownership in a nutshell & wiki