How to tell what Agile is at the factory? Top 5 Most Popular Agile Practices
If you break away from Habr, look into a real Russian company over 30 years old and with more than a thousand employees and say the word Agile, then the reaction will be at least wary. People there have already heard stories similar to “How to tell a grandmother” or “ How to tell a grandfather ” and watched all the performances of Gref, received a dozen offers to introduce flexibility in a week, some of the employees even worked a year with Scrum, but one question remains:
“What do we have to do with this, we have only a website programming out?”
As a result, for approximately 100% of Agile companies, it looks like quackery.
But here’s a paradox: in the world, 77% of companies * that use Agile in projects are not engaged in software development at all.
')
* From a large annual survey of companies from VersionOne
Under the cat, the practice of how Agile becomes clear in large companies and project teams without development. We make a project management system , but when we communicate with a relatively large client directly, most of the time we are discussing a flexible methodology and approaches to automating project management. I want to share this experience.
Agile is not a software development method. Wikipedia definitions are bad for understanding if you are not a developer.
These are principles of the organization of project activities and it is applicable in any area. In practice, the most sensitive difference for people is the departure from the hierarchy and the disappearance of one generation center of precisely described tasks. This is teamwork with roles, responsibility for the overall result and a flat structure of interactions.
The team in the game “What? Where? When? ”Exists according to the principles of Agile. Interaction has a key role. The captain plays the role of the customer of the product (the right answer), 2-3 erudite go through arrays of information, someone watches the time, there is a person who analyzes, asks questions and encourages communication, anyone can speak and lead to the result or all fail, games are debriefing (retrospective).
The Agile counterweight is a pipelined ( cascading ) method with a rigid hierarchy and precise tasks set as close as possible to SMART. According to these principles in “What? Where? When? ”The captain would have to distribute exact tasks - to whom in which direction to think and try to collect it in response. Each participant would have to comply with propriety and speak out when the turn comes. In case of failure, it would be necessary for someone to lower the motivation or dismiss and make this decision the captain.
The main reason for the emergence and development of Agile is that more and more projects do not have a 100% understanding of what should be at the end. It is simply impossible to schedule exact tasks. And they decided that free interaction is more important than instructions, and readiness for changes is more important than plans.
Flexible methodologies are the answer to uncertainty; it is not fully known what needs to be done and what should be the result. It would seem, but what is incomprehensible in the development, for example, of a site or in building a house or in preparing a hamburger at McDonalds? These projects are on stream, where is the uncertainty?
But Even if you are a web studio and this is the thousandth site for you, this is the first time for a client. And his wishes will remain uncertain until the very end. Many studios make 3-4 options for the main page and lay a week for unexpected improvements. Everyone I know, the work is divided into iterations, after each there is a demonstration and discussion. Communication with the customer is more important than the signed contract.
In the construction of the house there is a plan-project, calculation of materials and labor costs. But for some reason, the time is always delayed. It happens that the foundation floats, or the screed dries up, something starts to crack, or the timber is damp or the brick is too porous or the cement was brought to the wrong brand, or the client changed his mind and decided that now it would be a bath. A foreman is a human orchestra, decides everything that comes up, constantly retreating from the plan for the result. A normal house is much more important than a description.
Well, there is no uncertainty in making a hamburger at McDonalds. The process worked for 70 years and reproduced in 125 countries. Yes, this is a pipeline, where it is better not to get involved with flexibility. Agile is not applicable to well-established processes over the years. True, opening a new restaurant for a very precise franchise is always a unique project. Where to place will be an iterative approach, reduction of iterations, distribution of roles, open interaction, visualization of the project on the Agile-board, retrospective, daily planning meetings.
Total Agile key values ​​( manifest ):
In the familiar team there are two roles: Chief and Slave, one clever other fool. In Agile, three are fundamentally important: product customer, Methodologist, Team member.
In simplified form:
The customer tells what product is needed, what it is for, arranges discussions around requests from the market, makes decisions on priorities.
Methodist - makes sure that the customer does not become a boss. Well, also for the implementation of other practices, for example, that all tasks are with an assessment or that task assessments do not exceed 80% of the time available, if there is such an agreement.
Team - evaluates, distributes and implements tasks. Always demonstrates the product version, not individual pieces made.
If to simplify completely, then in Agile a person is required who makes sure that the team receives the maximum amount of information about the desired product in all details from different sides and actively participates in the discussion of how to implement.
I did not receive the task as a directive from above, but a description and understanding of what should be done for the user when the product is developed.
From the side, a flexible team differs from a familiar one precisely by the presence or absence of a so-called narrative collaboration.
If there is a discussion of the question “How to implement a product?” At all levels, then the team is flexible. If you are looking for someone to blame for not completing the list of specific tasks, then everything is as usual.
All these stories about responsible teams and stories of the appearance of the method are perceived as complete garbage, if there is no answer to the questions:
“And how to manage the resources more precisely?”, “How did you understand earlier that the project did not have enough resources for the end?”, “We always set and distributed tasks by performers and could predict the result, but what now?”. To tell about Agile, you can only open this question.
It should be noted that in general the whole Agile was designed specifically to solve the issue of resources “How to effectively manage resources in a project with unpredictability” The methodology would not have been born if the main task were the comfort and freedom of people in a team.
There are several important principles and methods that are explicitly aimed at predicting resources:
1. Visibility of the necessary resources. Agile boards are inextricably linked with the methodology. This is when tasks are distributed in columns, and columns define the stage of the tasks in them. This is the most visual tool for visualizing the status of a project. Ideally, any third-party person should be clear at what stage the project is and how much is left to the end. If all of a sudden it becomes obvious that there are not enough resources or the need to change priorities, this will happen by itself.
Questions of predictability of results and management of priorities are solved precisely through clarity.
2. Priorities and backlog . When planning, it is taken into account that not all tasks will be able to be closed in a selected period of time. There is always a list of what must be done and what should be done well (this is backlog). Priorities are given by the team in the discussion with the internal customer of the product. If it so happens that time remains, tasks of the second degree of importance are solved, if they do not even have time to close the tasks with the “Critical” mark, the team is additionally tensed.
3. Short iterations (sprints). This approach, like no other, allows companies to try something from Agile. The manual agrees on the intermediate result in a couple of weeks without getting involved and putting down the tasks for everyone. To agree to this mode of operation for half a year would be impossible.
Sprint (iteration) is the length of time in a few weeks. We most often have 2 weeks. The most important thing in a sprint is to determine which intermediate result should be obtained. This result is good to call an iteration, for example, “Release boards with rights” or “Launch a site for a test”. If the work goes on time intervals, but each segment does not lead to any specific result, then this is not an iterative approach.
4. Evaluation of tasks in the size of T-shirts. People are not too fond of giving accurate estimates of the tasks, but it is normal to estimate roughly on a scale large, medium, small for most. Below are the world's most popular ways to evaluate tasks without high accuracy. With interest on frequency of use.
We use the third one, but estimates are only 1h, 2h, 4h, 8h.
The meaning of the approach is to get away from trying to catch someone on inaccurate estimates of their work. They are approximate from the very beginning. Focus on the fact that every sprint would strive to gain the maximum number of balls, which are roughly related to time.
5. Burndown chart
A very simple thing is a two-line graph; the first is how much time has burned and it is always direct, the second is how many tasks in terms of resources are closed and fluctuations are possible here. In fact, this is a graphic answer to the question of whether the team is on schedule or is lagging behind.
Here, only general approaches are described without details; it may be worthwhile to write a separate material with details of resource management. But if we summarize here in two lines, we get:
Inside of the largest, oldest and well-known seo-studio in Russia - they lay a reserve in the resources two times, the first when discussing with the client, the second with internal planning.
Once again, Agile is at a basic application level. There are no super-complicated techniques that need to be studied for a long time. Below is an example of the 5 most popular practices (according to the data from the same survey from VersionOne)
All of them are applicable in projects from any field and are simple enough for instant use. All are united by a common idea of ​​an iterative approach.
1. Iterative planning - sprints (90% of teams use)
Working in small runs with an intermediate result is good practice. Sprint is a few weeks. Too short or too long stretches are bad. The same interval for all occasions is also not suitable. A sprint should have the most accurate goal, based on this, the duration is determined.
The most common mistake is that teams get used to simply schedule tasks every two weeks, the process of setting intermediate goals and summing up at the end are lost. Work falls into the usual flow of tasks with the update once a sprint. The problem must be solved by a methodologist.
2. Daily gauges (88% of teams use)
The task is for the team to confirm the uniform direction of movement of all participants every day.
According to the classic description, everyone in the team reveals three questions:
What has been done at this point from the sprint?
What is planned for today?
What problems arose or what hinders?
In our practice, this quickly annoys teams and becomes a chore or formal reporting. What helps:
Change time planery - 6 months. in the morning, 6 months in the evening.
Each time I change the lead gauge, there should not be a person to whom they report. A great option if the lead is played by lot.
Customer of the product, share customer stories at the beginning of the planning meeting.
Discuss general topics and only then move on to questions.
Do not allow any other party team members to join the planning staff.
3. Retrospectives (83% of teams use)
Meeting at the end of the iteration. Discussion of what happened and what did not. The most important goal is to draw conclusions on how to change.
The customer of the product, on how best to show users' expectations, the methodologist, on how to encourage dialogue and follow the agreements of the chosen approaches, the team, on how to take into account new opening factors in evaluations.
As a rule, retrospectives are fun - the iteration is over, you can breathe out and discuss the results. Good practice is something to drink or eat during the breaks of this process.
4. Iterative screenings (81% of teams use)
This is a demonstration from the team once in several iterations of the project results, as a rule, in the form of a speech. The main point is that there should be a “session” and it's okay if it becomes similar to reporting to the management.
The main difficulty is that someone other than the team will get together and understand the meaning of what is happening. In our practice, it takes root only with a very steep leadership.
5. Short iterations (71% of commands use)
The point is that you need to constantly try to shorten the cycle of getting small intermediate results. If this is not done, the cycles will naturally grow or be constant, regardless of intermediate goals. The shorter the cycle, the less errors in iterative planning.
This is the task of the methodologist, it is worth remembering about it at least once every six months.
The diagram of how many companies change Agile for themselves looks like this:
The flexibility of the approach extends to the approach itself. This is the first thing a team needs to know if they have to become more flexible. You can not be 100% Agile, following all instructions. No one strictly observes the rules in its pure form, in practice, each company has its own modifications.
The most popular methods from Agile are easy to implement, give results and do not turn the company upside down. It is for this reason that 98% of those using Agile talk about the success of the approaches.
If you start, for example, with the morning meetings, nothing bad will happen in the team, but a simple daily dialogue of people within the project makes the process more flexible.
The combination of flexibility and rigidity is always individual and depends on many factors: manager, project complexity, team size, budget, and so on. But if at least one approach is meaningfully introduced, then this company works according to the Agile methodology and it will not be superfluous to proudly report this within the team.
The article provides a few facts about the spread of Agile in the world, taken from the survey from the company VersionOne.
The problem is that this data has little to do with our reality.
We in YouGile conduct a large survey on agile methodology in Russia.
Take part - pass the survey "Agile in Russia 2017"
10 questions, 3 minutes
The results will be published on Habrahabr.
“What do we have to do with this, we have only a website programming out?”As a result, for approximately 100% of Agile companies, it looks like quackery.
But here’s a paradox: in the world, 77% of companies * that use Agile in projects are not engaged in software development at all.
')
Under the cat, the practice of how Agile becomes clear in large companies and project teams without development. We make a project management system , but when we communicate with a relatively large client directly, most of the time we are discussing a flexible methodology and approaches to automating project management. I want to share this experience.
Instead of defining. What to say about Agile, when different people from different departments gathered
Agile is not a software development method. Wikipedia definitions are bad for understanding if you are not a developer.
These are principles of the organization of project activities and it is applicable in any area. In practice, the most sensitive difference for people is the departure from the hierarchy and the disappearance of one generation center of precisely described tasks. This is teamwork with roles, responsibility for the overall result and a flat structure of interactions.
The team in the game “What? Where? When? ”Exists according to the principles of Agile. Interaction has a key role. The captain plays the role of the customer of the product (the right answer), 2-3 erudite go through arrays of information, someone watches the time, there is a person who analyzes, asks questions and encourages communication, anyone can speak and lead to the result or all fail, games are debriefing (retrospective).
The Agile counterweight is a pipelined ( cascading ) method with a rigid hierarchy and precise tasks set as close as possible to SMART. According to these principles in “What? Where? When? ”The captain would have to distribute exact tasks - to whom in which direction to think and try to collect it in response. Each participant would have to comply with propriety and speak out when the turn comes. In case of failure, it would be necessary for someone to lower the motivation or dismiss and make this decision the captain.
The main reason for the emergence and development of Agile is that more and more projects do not have a 100% understanding of what should be at the end. It is simply impossible to schedule exact tasks. And they decided that free interaction is more important than instructions, and readiness for changes is more important than plans.
Flexible methodologies are the answer to uncertainty; it is not fully known what needs to be done and what should be the result. It would seem, but what is incomprehensible in the development, for example, of a site or in building a house or in preparing a hamburger at McDonalds? These projects are on stream, where is the uncertainty?
But Even if you are a web studio and this is the thousandth site for you, this is the first time for a client. And his wishes will remain uncertain until the very end. Many studios make 3-4 options for the main page and lay a week for unexpected improvements. Everyone I know, the work is divided into iterations, after each there is a demonstration and discussion. Communication with the customer is more important than the signed contract.
In the construction of the house there is a plan-project, calculation of materials and labor costs. But for some reason, the time is always delayed. It happens that the foundation floats, or the screed dries up, something starts to crack, or the timber is damp or the brick is too porous or the cement was brought to the wrong brand, or the client changed his mind and decided that now it would be a bath. A foreman is a human orchestra, decides everything that comes up, constantly retreating from the plan for the result. A normal house is much more important than a description.
Well, there is no uncertainty in making a hamburger at McDonalds. The process worked for 70 years and reproduced in 125 countries. Yes, this is a pipeline, where it is better not to get involved with flexibility. Agile is not applicable to well-established processes over the years. True, opening a new restaurant for a very precise franchise is always a unique project. Where to place will be an iterative approach, reduction of iterations, distribution of roles, open interaction, visualization of the project on the Agile-board, retrospective, daily planning meetings.
Total Agile key values ​​( manifest ):
- free teamwork
- project performance (great product)
- partner communication with the client
- willingness to change
What are role teams?
In the familiar team there are two roles: Chief and Slave, one clever other fool. In Agile, three are fundamentally important: product customer, Methodologist, Team member.
In simplified form:
The customer tells what product is needed, what it is for, arranges discussions around requests from the market, makes decisions on priorities.
Methodist - makes sure that the customer does not become a boss. Well, also for the implementation of other practices, for example, that all tasks are with an assessment or that task assessments do not exceed 80% of the time available, if there is such an agreement.
Team - evaluates, distributes and implements tasks. Always demonstrates the product version, not individual pieces made.
If to simplify completely, then in Agile a person is required who makes sure that the team receives the maximum amount of information about the desired product in all details from different sides and actively participates in the discussion of how to implement.
I did not receive the task as a directive from above, but a description and understanding of what should be done for the user when the product is developed.
From the side, a flexible team differs from a familiar one precisely by the presence or absence of a so-called narrative collaboration.
If there is a discussion of the question “How to implement a product?” At all levels, then the team is flexible. If you are looking for someone to blame for not completing the list of specific tasks, then everything is as usual.
The main question: "How to manage resources when everything is so flexible?"
All these stories about responsible teams and stories of the appearance of the method are perceived as complete garbage, if there is no answer to the questions:
“And how to manage the resources more precisely?”, “How did you understand earlier that the project did not have enough resources for the end?”, “We always set and distributed tasks by performers and could predict the result, but what now?”. To tell about Agile, you can only open this question.
It should be noted that in general the whole Agile was designed specifically to solve the issue of resources “How to effectively manage resources in a project with unpredictability” The methodology would not have been born if the main task were the comfort and freedom of people in a team.
There are several important principles and methods that are explicitly aimed at predicting resources:
1. Visibility of the necessary resources. Agile boards are inextricably linked with the methodology. This is when tasks are distributed in columns, and columns define the stage of the tasks in them. This is the most visual tool for visualizing the status of a project. Ideally, any third-party person should be clear at what stage the project is and how much is left to the end. If all of a sudden it becomes obvious that there are not enough resources or the need to change priorities, this will happen by itself.
Questions of predictability of results and management of priorities are solved precisely through clarity.
2. Priorities and backlog . When planning, it is taken into account that not all tasks will be able to be closed in a selected period of time. There is always a list of what must be done and what should be done well (this is backlog). Priorities are given by the team in the discussion with the internal customer of the product. If it so happens that time remains, tasks of the second degree of importance are solved, if they do not even have time to close the tasks with the “Critical” mark, the team is additionally tensed.
3. Short iterations (sprints). This approach, like no other, allows companies to try something from Agile. The manual agrees on the intermediate result in a couple of weeks without getting involved and putting down the tasks for everyone. To agree to this mode of operation for half a year would be impossible.
Sprint (iteration) is the length of time in a few weeks. We most often have 2 weeks. The most important thing in a sprint is to determine which intermediate result should be obtained. This result is good to call an iteration, for example, “Release boards with rights” or “Launch a site for a test”. If the work goes on time intervals, but each segment does not lead to any specific result, then this is not an iterative approach.
4. Evaluation of tasks in the size of T-shirts. People are not too fond of giving accurate estimates of the tasks, but it is normal to estimate roughly on a scale large, medium, small for most. Below are the world's most popular ways to evaluate tasks without high accuracy. With interest on frequency of use.
We use the third one, but estimates are only 1h, 2h, 4h, 8h.
The meaning of the approach is to get away from trying to catch someone on inaccurate estimates of their work. They are approximate from the very beginning. Focus on the fact that every sprint would strive to gain the maximum number of balls, which are roughly related to time.
5. Burndown chart
A very simple thing is a two-line graph; the first is how much time has burned and it is always direct, the second is how many tasks in terms of resources are closed and fluctuations are possible here. In fact, this is a graphic answer to the question of whether the team is on schedule or is lagging behind.
Here, only general approaches are described without details; it may be worthwhile to write a separate material with details of resource management. But if we summarize here in two lines, we get:
- the most common mistake is an attempt to get into the estimates very accurately, the team stops working on the result
- the most successful approach is to build a reserve in time, plan for 80% of resources
Inside of the largest, oldest and well-known seo-studio in Russia - they lay a reserve in the resources two times, the first when discussing with the client, the second with internal planning.
Top 5 most popular Agile practices clear to everyone
Once again, Agile is at a basic application level. There are no super-complicated techniques that need to be studied for a long time. Below is an example of the 5 most popular practices (according to the data from the same survey from VersionOne)
All of them are applicable in projects from any field and are simple enough for instant use. All are united by a common idea of ​​an iterative approach.
1. Iterative planning - sprints (90% of teams use)
Working in small runs with an intermediate result is good practice. Sprint is a few weeks. Too short or too long stretches are bad. The same interval for all occasions is also not suitable. A sprint should have the most accurate goal, based on this, the duration is determined.
The most common mistake is that teams get used to simply schedule tasks every two weeks, the process of setting intermediate goals and summing up at the end are lost. Work falls into the usual flow of tasks with the update once a sprint. The problem must be solved by a methodologist.
2. Daily gauges (88% of teams use)
The task is for the team to confirm the uniform direction of movement of all participants every day.
According to the classic description, everyone in the team reveals three questions:
What has been done at this point from the sprint?
What is planned for today?
What problems arose or what hinders?
In our practice, this quickly annoys teams and becomes a chore or formal reporting. What helps:
Change time planery - 6 months. in the morning, 6 months in the evening.
Each time I change the lead gauge, there should not be a person to whom they report. A great option if the lead is played by lot.
Customer of the product, share customer stories at the beginning of the planning meeting.
Discuss general topics and only then move on to questions.
Do not allow any other party team members to join the planning staff.
3. Retrospectives (83% of teams use)
Meeting at the end of the iteration. Discussion of what happened and what did not. The most important goal is to draw conclusions on how to change.
The customer of the product, on how best to show users' expectations, the methodologist, on how to encourage dialogue and follow the agreements of the chosen approaches, the team, on how to take into account new opening factors in evaluations.
As a rule, retrospectives are fun - the iteration is over, you can breathe out and discuss the results. Good practice is something to drink or eat during the breaks of this process.
4. Iterative screenings (81% of teams use)
This is a demonstration from the team once in several iterations of the project results, as a rule, in the form of a speech. The main point is that there should be a “session” and it's okay if it becomes similar to reporting to the management.
The main difficulty is that someone other than the team will get together and understand the meaning of what is happening. In our practice, it takes root only with a very steep leadership.
5. Short iterations (71% of commands use)
The point is that you need to constantly try to shorten the cycle of getting small intermediate results. If this is not done, the cycles will naturally grow or be constant, regardless of intermediate goals. The shorter the cycle, the less errors in iterative planning.
This is the task of the methodologist, it is worth remembering about it at least once every six months.
How to understand whether the project is conducted on Agile-methodology or not?
The diagram of how many companies change Agile for themselves looks like this:
The flexibility of the approach extends to the approach itself. This is the first thing a team needs to know if they have to become more flexible. You can not be 100% Agile, following all instructions. No one strictly observes the rules in its pure form, in practice, each company has its own modifications.
The most popular methods from Agile are easy to implement, give results and do not turn the company upside down. It is for this reason that 98% of those using Agile talk about the success of the approaches.
If you start, for example, with the morning meetings, nothing bad will happen in the team, but a simple daily dialogue of people within the project makes the process more flexible.
The combination of flexibility and rigidity is always individual and depends on many factors: manager, project complexity, team size, budget, and so on. But if at least one approach is meaningfully introduced, then this company works according to the Agile methodology and it will not be superfluous to proudly report this within the team.
PS Survey: Agile in Russia 2017
The article provides a few facts about the spread of Agile in the world, taken from the survey from the company VersionOne.
The problem is that this data has little to do with our reality.
We in YouGile conduct a large survey on agile methodology in Russia.
Take part - pass the survey "Agile in Russia 2017"
10 questions, 3 minutes
The results will be published on Habrahabr.
Source: https://habr.com/ru/post/329754/
All Articles