Why Agile doesn't work and what to do about it.
In one of our posts, we have already talked about some flexible methodologies. In this material, we propose to look at the reasons for the failures of agile-projects and find out what executives and developers think about flexible methodologies.
/ Flickr / Hamza Butt / CC
Flexible methodologies are not new, not original, and have been tried by many companies. And some of them (such as, for example , the American rail solutions BI company for Railinc) recognize that agile is the best thing that could happen to them. True, not everyone shares their enthusiasm. Chris York (Chris York), a tester and developer with fifteen years of experience, argues that he has never seen in his life that flexible methodologies work as they should.
')
According to a study by VersionOne, 98% of companies consider their agile projects successful. However, only 7% of respondents said that the introduction of agile helped the company to better adapt to the market, and only 11% of respondents said that they had achieved a high level of competence within the organization thanks to agile. The remaining 82% say they have not yet reached the desired level of "flexibility." Perhaps these companies are doing something wrong, try to figure out what it is.
In agile projects, communication is an important part of the process, as well as daily meetings. The whole team must understand what happened yesterday and what is planned for tomorrow. If people communicate in person, they work better: the sixth principle of agile speaks about it.
Many companies have realized the importance of personal communication: IBM relocated remote employees to an office to get the most from teamwork. In addition to IBM, remote employees are ā turned into officeā companies by Reddit, Aetna, Bank of America and Best Buy. Diane Gherson, senior vice president of personnel policy, IBM, says the reason for the change is that this approach can develop a ācontinuous process of generating innovation.ā
Juan Emilio Inzaurraga (Juan Emilio Inzaurraga), project manager at Hexacta, also emphasizes the importance of communication in agile teams. The company practices daily meetings / calls with the customer, and, according to Juan, it helps him to determine the teamās progress, possible bottlenecks and product flaws. On the other hand, meetings help developers to concentrate on the current task, and for beginners and inexperienced team members - to better understand the task and identify ways to accomplish it.
However, this approach has opponents. First of all, the desire to communicate with everyone personally and transplant developers to the office causes discontent of those who previously worked "on the remote." Now, these employees have to change their daily routine and work rhythm in order to comply with agile principles.
Of course, if the situation is presented by the management in this way, the new approaches will not cause enthusiasm among the employees. Moreover, the team will be demotivated - someone just can not quickly rebuild the mode of operation, and someone will openly declare that earlier it was better. Steve Berczuk, lead engineer and scrum-master at Fitbit, emphasizes that in some companies the introduction of agile conflicts with previously adopted policies for hiring remote workers.
Passion for personal meetings also has its negative consequences. For example, Quora experienced developer and resident Oliver Dolan (Oliver Dolan) calculated that daily meetings take 2640 minutes or 44 hours for 1 sprint. This is not so little. Hacker News users also have a lot of arguments against these meetings: meetings kill motivation, distract, annoy developers, which is also mentioned by John Purcell, the creator of the educational project CaveOfProgramming .
All these concerns are not a reason to ācancel agileā. The question is how well the company will be able to adapt a flexible methodology for themselves. For example, another Quora resident, Patricia Okowicka, a developer with twelve years of experience, says that in her scrum team, the meetings take only 15% of the time, the remaining 85% is pure work. With this approach, there is no reason to worry that all the work turns into meetings.
And despite the confidence of one of the creators of Agile Manifesto, Robert Martin (Robert Martin), that in order to achieve a result, developers need to be literally āin the same roomā, examples of how distributed teams successfully implemented agile also exist. For example, Jamie Bolster, CEO of MentorMate, successfully managed a team of developers who worked remotely using agile. And Sandeep Joshi, a Microsoft developer, offers concrete actions for competent management of a remote team.
Anthony Mersino, founder of the Vitality Chicago training company and author of the book Agile Project Management: A Nuts and Bolts Guide to Sucess , argues that there should be no managers in agile at all. And Steve Denning (Steve Denning), the author of six books on business and a blog at Forbes, says that āmanagementā and agile are two different worlds. It is assumed that team members can organize their own workflow and motivate themselves.
Unfortunately, many real participants in the workflow find this approach, to put it mildly, divorced from reality. Patrick Harrington, one of the founders and chief analyst of Paysa's data, stresses that experienced developers do not need constant supervision, they are already quite mature and are motivated by KPI. The problem is that managers are usually accustomed to seeing them as āsupervisors over developersā, while in reality (especially in agile teams), their role should be completely different.
In communities like Hacker News [ 1 , 2 ], developers note that the āideal PMā should be on the side of the team, help each participant to understand the goals and objectives of the project, if possible eliminate interfering factors such as lack of resources and (most important) protect interests and the time of developers, as well as to protect the team from too frequent meetings and other entropies. This approach will allow programmers to work smoothly and quickly to respond to customer requirements - and this is exactly what agile teams are striving for.
Agile is a set of principles, not an end in itself ā that is why it is important to separate approaches to work and its results. The fact that the team follows the principles of agile affects the speed of the tasks, but not always the acceleration can be predicted and measured āat the startā.
One of the participants of this thread on Hacker News draws an analogy with football. In a football team, all players clearly understand the goal, have the skills to achieve it. Each of them knows how to communicate with teammates so that they perform their tasks, and everyone is ready to take the initiative in the current situation on the field. Nobody breathes to the players in the back with the words: āWe need to score a goal after 15 minutes and 48 seconds after the start of the match and not a minute later, even if it is impossibleā. Such a team works smoothly and usually achieves the goal, and this is exactly what the agile methodology is trying to convey.
Following the principles of agile has a positive effect on work efficiency, but (by itself) is not an indicator of effectiveness: performing formal āagile ritualsā will not bring the team closer to achieving KPI. Moreover, and with the introduction of agile, it makes sense to revise the indicators that measure the quality of work: if your team must immediately respond to new introductory, quickly adapt to changing situations, can KPIs and approaches to assessing them remain unchanged? This question, in particular, is raised by Jim Highsmith in the book Agile Project Management.
Sometimes such a āflexibleā revision of KPI āon the goā requires a lot of courage. By the way, it is courage to say that something in the project does not follow a predetermined scenario, as one of the most important qualities of an agile leader, Gary Pollice, a practicing professor of computer science and one of the authors of the book ā Software Programming. Based on the Rational Unified Process (RUP) ā.
When the term āagileā became popular, many companies decided to implement the methodology, only to be āin the subject lineā. One of the residents of Hacker News shares his experience in this regard. When he worked as a coaching manager for the agile methodology, each time he watched companies introduce external things: meetings, iterations, etc., but the workflow remains the same as before the introduction of agile.
It turns out that the company follows the principles of agile externally, but inside it still uses conditional waterfall. Unfortunately, if the principles of the new approach are incomprehensible to the participants, a ārollbackā will be inevitable - people who enter the agile environment without a clear understanding of its objectives and advantages will have a hard time adapting to it and constantly returning to vertical management.
On the other hand, there is no need for āliteral copyingā of all the nuances of a particular approach - especially if you do not understand what exactly they give to your project. In the end, all methodologies have their pros and cons. Therefore, instead of internecine wars like: Lean vs Agile or Kanban vs Scrum, it will be more useful to look at the common features of various methodologies, combine the most beneficial for a particular team and project and implement them.
One of the successful examples is the RentaTeam development team. They changed the principles of communication in a team and adjusted the agile methodology to their team and project. So agile found meaning for employees, and developer productivity increased by 30%.
According to Greg Jorgensen, a ātypical programmerā with forty years of experience, an enthusiastic team of professionals who do not depend on decisions from above, understands goals and requirements and knows how to achieve them is what will make a project successful. Methodologies and tools are great, but the main thing is people.
PS Our materials on software development methodologies:
PPS Materials on the topic from the blog "IT Guild":
/ Flickr / Hamza Butt / CC
Flexible methodologies are not new, not original, and have been tried by many companies. And some of them (such as, for example , the American rail solutions BI company for Railinc) recognize that agile is the best thing that could happen to them. True, not everyone shares their enthusiasm. Chris York (Chris York), a tester and developer with fifteen years of experience, argues that he has never seen in his life that flexible methodologies work as they should.
')
What do you mean, do not work?
According to a study by VersionOne, 98% of companies consider their agile projects successful. However, only 7% of respondents said that the introduction of agile helped the company to better adapt to the market, and only 11% of respondents said that they had achieved a high level of competence within the organization thanks to agile. The remaining 82% say they have not yet reached the desired level of "flexibility." Perhaps these companies are doing something wrong, try to figure out what it is.
1. Communication is not an end in itself
In agile projects, communication is an important part of the process, as well as daily meetings. The whole team must understand what happened yesterday and what is planned for tomorrow. If people communicate in person, they work better: the sixth principle of agile speaks about it.
Many companies have realized the importance of personal communication: IBM relocated remote employees to an office to get the most from teamwork. In addition to IBM, remote employees are ā turned into officeā companies by Reddit, Aetna, Bank of America and Best Buy. Diane Gherson, senior vice president of personnel policy, IBM, says the reason for the change is that this approach can develop a ācontinuous process of generating innovation.ā
Juan Emilio Inzaurraga (Juan Emilio Inzaurraga), project manager at Hexacta, also emphasizes the importance of communication in agile teams. The company practices daily meetings / calls with the customer, and, according to Juan, it helps him to determine the teamās progress, possible bottlenecks and product flaws. On the other hand, meetings help developers to concentrate on the current task, and for beginners and inexperienced team members - to better understand the task and identify ways to accomplish it.
However, this approach has opponents. First of all, the desire to communicate with everyone personally and transplant developers to the office causes discontent of those who previously worked "on the remote." Now, these employees have to change their daily routine and work rhythm in order to comply with agile principles.
Of course, if the situation is presented by the management in this way, the new approaches will not cause enthusiasm among the employees. Moreover, the team will be demotivated - someone just can not quickly rebuild the mode of operation, and someone will openly declare that earlier it was better. Steve Berczuk, lead engineer and scrum-master at Fitbit, emphasizes that in some companies the introduction of agile conflicts with previously adopted policies for hiring remote workers.
Passion for personal meetings also has its negative consequences. For example, Quora experienced developer and resident Oliver Dolan (Oliver Dolan) calculated that daily meetings take 2640 minutes or 44 hours for 1 sprint. This is not so little. Hacker News users also have a lot of arguments against these meetings: meetings kill motivation, distract, annoy developers, which is also mentioned by John Purcell, the creator of the educational project CaveOfProgramming .
All these concerns are not a reason to ācancel agileā. The question is how well the company will be able to adapt a flexible methodology for themselves. For example, another Quora resident, Patricia Okowicka, a developer with twelve years of experience, says that in her scrum team, the meetings take only 15% of the time, the remaining 85% is pure work. With this approach, there is no reason to worry that all the work turns into meetings.
And despite the confidence of one of the creators of Agile Manifesto, Robert Martin (Robert Martin), that in order to achieve a result, developers need to be literally āin the same roomā, examples of how distributed teams successfully implemented agile also exist. For example, Jamie Bolster, CEO of MentorMate, successfully managed a team of developers who worked remotely using agile. And Sandeep Joshi, a Microsoft developer, offers concrete actions for competent management of a remote team.
2. Manager vs Warden
Anthony Mersino, founder of the Vitality Chicago training company and author of the book Agile Project Management: A Nuts and Bolts Guide to Sucess , argues that there should be no managers in agile at all. And Steve Denning (Steve Denning), the author of six books on business and a blog at Forbes, says that āmanagementā and agile are two different worlds. It is assumed that team members can organize their own workflow and motivate themselves.
Unfortunately, many real participants in the workflow find this approach, to put it mildly, divorced from reality. Patrick Harrington, one of the founders and chief analyst of Paysa's data, stresses that experienced developers do not need constant supervision, they are already quite mature and are motivated by KPI. The problem is that managers are usually accustomed to seeing them as āsupervisors over developersā, while in reality (especially in agile teams), their role should be completely different.
In communities like Hacker News [ 1 , 2 ], developers note that the āideal PMā should be on the side of the team, help each participant to understand the goals and objectives of the project, if possible eliminate interfering factors such as lack of resources and (most important) protect interests and the time of developers, as well as to protect the team from too frequent meetings and other entropies. This approach will allow programmers to work smoothly and quickly to respond to customer requirements - and this is exactly what agile teams are striving for.
3. Agile-principles! = KPI
Agile is a set of principles, not an end in itself ā that is why it is important to separate approaches to work and its results. The fact that the team follows the principles of agile affects the speed of the tasks, but not always the acceleration can be predicted and measured āat the startā.
One of the participants of this thread on Hacker News draws an analogy with football. In a football team, all players clearly understand the goal, have the skills to achieve it. Each of them knows how to communicate with teammates so that they perform their tasks, and everyone is ready to take the initiative in the current situation on the field. Nobody breathes to the players in the back with the words: āWe need to score a goal after 15 minutes and 48 seconds after the start of the match and not a minute later, even if it is impossibleā. Such a team works smoothly and usually achieves the goal, and this is exactly what the agile methodology is trying to convey.
Following the principles of agile has a positive effect on work efficiency, but (by itself) is not an indicator of effectiveness: performing formal āagile ritualsā will not bring the team closer to achieving KPI. Moreover, and with the introduction of agile, it makes sense to revise the indicators that measure the quality of work: if your team must immediately respond to new introductory, quickly adapt to changing situations, can KPIs and approaches to assessing them remain unchanged? This question, in particular, is raised by Jim Highsmith in the book Agile Project Management.
Sometimes such a āflexibleā revision of KPI āon the goā requires a lot of courage. By the way, it is courage to say that something in the project does not follow a predetermined scenario, as one of the most important qualities of an agile leader, Gary Pollice, a practicing professor of computer science and one of the authors of the book ā Software Programming. Based on the Rational Unified Process (RUP) ā.
4. "Informal" agile
When the term āagileā became popular, many companies decided to implement the methodology, only to be āin the subject lineā. One of the residents of Hacker News shares his experience in this regard. When he worked as a coaching manager for the agile methodology, each time he watched companies introduce external things: meetings, iterations, etc., but the workflow remains the same as before the introduction of agile.
It turns out that the company follows the principles of agile externally, but inside it still uses conditional waterfall. Unfortunately, if the principles of the new approach are incomprehensible to the participants, a ārollbackā will be inevitable - people who enter the agile environment without a clear understanding of its objectives and advantages will have a hard time adapting to it and constantly returning to vertical management.
On the other hand, there is no need for āliteral copyingā of all the nuances of a particular approach - especially if you do not understand what exactly they give to your project. In the end, all methodologies have their pros and cons. Therefore, instead of internecine wars like: Lean vs Agile or Kanban vs Scrum, it will be more useful to look at the common features of various methodologies, combine the most beneficial for a particular team and project and implement them.
One of the successful examples is the RentaTeam development team. They changed the principles of communication in a team and adjusted the agile methodology to their team and project. So agile found meaning for employees, and developer productivity increased by 30%.
According to Greg Jorgensen, a ātypical programmerā with forty years of experience, an enthusiastic team of professionals who do not depend on decisions from above, understands goals and requirements and knows how to achieve them is what will make a project successful. Methodologies and tools are great, but the main thing is people.
PS Our materials on software development methodologies:
- āAgile Developmentā: Agile Methodologies Summary
- Briefly about software development methodologies: Waterfall, Lean and Feature Driven Development
PPS Materials on the topic from the blog "IT Guild":
Source: https://habr.com/ru/post/345142/
All Articles