20 Years of Agile: A Failed Revolt

Editor's Note: In 2001, the Agile Manifesto was born. Subsequently, agile development became a well-known hot topic on the Internet. Everyone shouted agile, and every business used agile. However, just in time for the 20th anniversary of the Agile Manifesto, there are frequent news and discussions about the death of Agile. What are the thought-provoking things behind it?

Author | Al Tenhundfeld      

Translator | Crescent Moon

Listing | CSDN (ID: CSDNnews)

This year has been 20 years since the release of the Agile Manifesto, and we can conclude the following two indisputable facts from the development of these 20 years:

• Agile, as a label, wins. Everyone wants to wear the agile label.

• Agile, the results of practice are far from the revolutionary ideas of the founders.

How did we get here? Everyone says they've adopted Agile, but almost no one is Agile.

The History of the Agile Manifesto

In February 2001, 17 professional software practitioners gathered at the Lodge Hotel in Snowbird Ski Resort, Wasatch Mountains, Utah, USA. After several days of discussion and debate, they co-authored the "Manifesto for Agile Software Development".

First of all, it needs to be explained that these people are software development practitioners. They are not project managers, CTOs or directors of engineering. They are developers, programmers, scientists and engineers. They both write code and collaborate with stakeholders to solve problems. this point is very important.

Another point, the Agile Manifesto did not come out of thin air. Many of these people have created their own methodologies such as Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal Method, Function Driven Development, Pragmatic Programming, etc.

Everyone in this group had a lot of experience writing software, and they were all looking for an alternative to the heavyweight document-driven software development process of the time. At the heart of the Agile Manifesto are four value statements:

We have been exploring better software development methods in practice,

Help others while doing it yourself. From this we established the following values:

• Individuals and interactions over processes and tools

• Working software over exhaustive documentation

• Customer cooperation is higher than contract negotiation

• Responding to change is more than following a plan

• That is, although the right-hand term has value,

• We give more weight to the value of the left term.

new Hope

These modern software development practices are taken for granted today, but in 2001, these ideas were radical.

Are you going to start building software without collecting all the requirements and estimating every feature? This is crazy!

And the most important point is forgotten: open and active opposition to management. For example, Ken Schwaber has outspokenly expressed his goal that all projects can get rid of project managers, not just those people leaving his projects, he wants our entire industry to eliminate this profession.

Agile and PMI

"We found that in complex creative work, the role of the project manager hinders productivity gains. The project manager's mind represents the project plan and only constrains the creativity and ingenuity of others on the project within the plan, not Use everyone's ingenuity to solve problems better." - Ken Schwaber, signer of the Agile Manifesto and co-founder of Scrum

The ScrumMaster has almost no power and no voting rights. They are the servants of the team, protecting the team and solving problems for the team, but not managing the team. Extreme Programming is similar, initially XP had trackers and coaches, and these teams had similar facilitation and support.

Alistair Cockburn, signatory of the Agile Manifesto and founder of the Crystal Methodology and Hexagonal Architecture, recently made a wonderful and very insightful point:

Scrum strikes a perfect agreement in a field full of contradictions:

• Management has 12 opportunities per year to adjust the direction of the team after each sprint.

• The team has a month to think and work in silence, without interruption or redirection.

• Teams have to declare what they can and can't accomplish this month without management interfering with their plans.

It's the perfect deal for both executives and development teams.

I'm a certified Scrum Master, have worked on agile teams for 15 years, and I've read a ton of popular books in the field. The following is the most concise and clear description of Scrum:

Scrum was created to function in an environment full of contradictions. It's a contract between tough managers and developers who take time to think and explore.

Management Strikes Back

In some ways, agile is an uprising of the working people at the bottom. The movement started with practitioners at the bottom and worked its way up to management. How did Agile succeed?

This is partly due to the growing number and business value of developers and their growing influence. But the biggest reason, in my opinion, is that the traditional waterfall approach just doesn't work. As software becomes more complex, the pace of business increases, and users become more sophisticated, it's impossible to plan everything in advance. Although iterative development is logical, it can still be intimidating to managers who are used to planning everything out.

I remember meetings around 2005 where it could be seen that management didn't buy into Agile, but they didn't have any better ideas either.

"Why don't we try this crazy idea that the engineers have been talking about? We can't meet the deadline anyway. Could it be any worse?"

However, to their surprise, Agile actually worked. Although at the beginning, the team will be a little uncomfortable, but after a period of time, it will gain a firm foothold and gradually discover which models are effective for the team, and slowly everything will improve. After a few sprints, you will feel the real power of agile: prioritization of work, collaboration, inspection and adjustment, and so on.

In about 5 years time, Agile went from a heard but not familiar methodology to a practice that everyone is implementing. In 2005, I changed jobs and I remember my understanding of Agile was superficial at the time when Test Driven Development was the mainstream. As of 2010, almost all modern software teams have adopted Agile.

From the looks of it at the time, Agile succeeded! Big win! Congratulations everyone!

However, "fighting the world is easy, but defending the world is difficult." Unfortunately, Agile failed to realize the dream of its founders.

• Prioritizing the individual and the interaction proved to be a difficult concept to follow through. It is much easier to popularize processes and tools.

• It turns out that producing software that works is far more difficult than unrealistic plans and extensive documentation.

• It turns out that working with clients requires trust and candor that doesn't necessarily exist in a business setting.

• As it turns out, executives want to be in control, and we need to have long-term plans for their business, which is often more important to react to change. 

• It turns out that agile implementations that are not implemented properly can often feel very confusing.

That doesn't mean the four values ​​of Agile are wrong. It just means that in order to get agile right, we need to put in a lot of effort, in addition to having some courage to accept the inherently chaotic nature of software. You have to understand and believe that as long as you keep learning, adapting, improving and releasing the product, you will eventually be able to achieve better results and achieve more realistic and efficient development than waterfall.

"The Agile movement is not against methodology, in fact many of us want to reshape the credibility of methodology. We want to restore balance. We embrace modeling, but not for the sake of storing diagrams in corporate warehouses. We accept documentation , but no tomes that are never maintained and rarely used. We plan, but we also know the limits of planning in a turbulent environment. Those who call XP, Scrum, and other agile methodologists 'hackers' ignorant of agile methodologies and the original definition of 'hacker'." - Jim Highsmith, "History: The Agile Manifesto"

The above mentioned the key point, agile development still requires planning and documentation, as well as rigorous implementation. This is a matter of degree of control. But if the organization is struggling with an agile transformation and is in disarray, and someone provides certifications, processes, and tools, you're bound to see it as a life-saving straw and grab it. Executives know far more about processes and tools than they do about self-organizing teams.

uprising failed

Unfortunately, however, the agile uprising did not succeed.

Tool vendors, process consultants, and experts make many promises that can never be kept. A lot of people have adopted SAFe, Scaled Scrum, and all the other enterprise agile-style methodologies. These frameworks aren't born out of spite, and in the right circumstances, they even have some value. But I wouldn't call them agile. Attempts to expand a methodology that focuses on individuals and interactions will inevitably raise problems and ultimately erode the original value of the methodology.

Developers should ditch agile

When the "agile" philosophy is not applied properly, it tends to create more distractions for developers, resulting in them actually working less time, being under more pressure, and needing to get things done "faster". This is bad for developers and ultimately bad for business, as such "agility" works very poorly, tends to lead to more bugs, and leads to slower project progress. In such a situation, excellent developers will leave, and the efficiency of the enterprise is not as good as not implementing agile.

agile is dead

The word "agile" has been subverted to mean nothing, and the agile community has become an arena for consultants and vendors to hawk services and products. Back then, the Agile Manifesto was so popular that the word agile became a gold magnet, used to get support, charge money, or sell products, almost like a marketing term.

Therefore, I think it's time for the word "agile" to retire from the stage of history.

to reflect

What's really sad, in my opinion, is seeing young developers denigrate Agile, seeing it as a blank check for management and a means to push development teams to work like crazy. I understand them. In their view, agility is a control mechanism imposed on them, not a self-arming force that they readily accept. But I hope some discussion around the history and original vision helps us remember where Agile should go.

Thankfully, the Agile Manifesto, proposed 20 years ago, is still wise and to the point.

Agile is no longer a hot topic these days. Everyone is implementing Agile. However, on this 20th anniversary, I would like to reflect on the following questions:

• What did you do right?

• What went wrong?

• How can we improve next time?

Those of us living through the Agile revolution wanted to reflect on the original 12 Agile principles and consider their value in the current software development environment.

I hope to examine the fundamentals of agile, learn from past failures, and, in the words of Dave Thomas, stay agile even if we choose to give up being "agile".

Reference link:

https://www.simplethread.com/agile-at-20-the-failed-rebellion

Editor's Note: In 2001, the Agile Manifesto was born. Subsequently, agile development became a well-known hot topic on the Internet. Everyone shouted agile, and every business used agile. However, just in time for the 20th anniversary of the Agile Manifesto, there are frequent news and discussions about the death of Agile. What are the thought-provoking things behind it?

Author | Al Tenhundfeld      

Translator | Crescent Moon

Listing | CSDN (ID: CSDNnews)

This year has been 20 years since the release of the Agile Manifesto, and we can conclude the following two indisputable facts from the development of these 20 years:

• Agile, as a label, wins. Everyone wants to wear the agile label.

• Agile, the results of practice are far from the revolutionary ideas of the founders.

How did we get here? Everyone says they've adopted Agile, but almost no one is Agile.

The History of the Agile Manifesto

In February 2001, 17 professional software practitioners gathered at the Lodge Hotel in Snowbird Ski Resort, Wasatch Mountains, Utah, USA. After several days of discussion and debate, they co-authored the "Manifesto for Agile Software Development".

First of all, it needs to be explained that these people are software development practitioners. They are not project managers, CTOs or directors of engineering. They are developers, programmers, scientists and engineers. They both write code and collaborate with stakeholders to solve problems. this point is very important.

Another point, the Agile Manifesto did not come out of thin air. Many of these people have created their own methodologies such as Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal Method, Function Driven Development, Pragmatic Programming, etc.

Everyone in this group had a lot of experience writing software, and they were all looking for an alternative to the heavyweight document-driven software development process of the time. At the heart of the Agile Manifesto are four value statements:

We have been exploring better software development methods in practice,

Help others while doing it yourself. From this we established the following values:

• Individuals and interactions over processes and tools

• Working software over exhaustive documentation

• Customer cooperation is higher than contract negotiation

• Responding to change is more than following a plan

• That is, although the right-hand term has value,

• We give more weight to the value of the left term.

new Hope

These modern software development practices are taken for granted today, but in 2001, these ideas were radical.

Are you going to start building software without collecting all the requirements and estimating every feature? This is crazy!

And the most important point is forgotten: open and active opposition to management. For example, Ken Schwaber has outspokenly expressed his goal that all projects can get rid of project managers, not just those people leaving his projects, he wants our entire industry to eliminate this profession.

Agile and PMI

"We found that in complex creative work, the role of the project manager hinders productivity gains. The project manager's mind represents the project plan and only constrains the creativity and ingenuity of others on the project within the plan, not Use everyone's ingenuity to solve problems better." - Ken Schwaber, signer of the Agile Manifesto and co-founder of Scrum

The ScrumMaster has almost no power and no voting rights. They are the servants of the team, protecting the team and solving problems for the team, but not managing the team. Extreme Programming is similar, initially XP had trackers and coaches, and these teams had similar facilitation and support.

Alistair Cockburn, signatory of the Agile Manifesto and founder of the Crystal Methodology and Hexagonal Architecture, recently made a wonderful and very insightful point:

Scrum strikes a perfect agreement in a field full of contradictions:

• Management has 12 opportunities per year to adjust the direction of the team after each sprint.

• The team has a month to think and work in silence, without interruption or redirection.

• Teams have to declare what they can and can't accomplish this month without management interfering with their plans.

It's the perfect deal for both executives and development teams.

I'm a certified Scrum Master, have worked on agile teams for 15 years, and I've read a ton of popular books in the field. The following is the most concise and clear description of Scrum:

Scrum was created to function in an environment full of contradictions. It's a contract between tough managers and developers who take time to think and explore.

Management Strikes Back

In some ways, agile is an uprising of the working people at the bottom. The movement started with practitioners at the bottom and worked its way up to management. How did Agile succeed?

This is partly due to the growing number and business value of developers and their growing influence. But the biggest reason, in my opinion, is that the traditional waterfall approach just doesn't work. As software becomes more complex, the pace of business increases, and users become more sophisticated, it's impossible to plan everything in advance. Although iterative development is logical, it can still be intimidating to managers who are used to planning everything out.

I remember meetings around 2005 where it could be seen that management didn't buy into Agile, but they didn't have any better ideas either.

"Why don't we try this crazy idea that the engineers have been talking about? We can't meet the deadline anyway. Could it be any worse?"

However, to their surprise, Agile actually worked. Although at the beginning, the team will be a little uncomfortable, but after a period of time, it will gain a firm foothold and gradually discover which models are effective for the team, and slowly everything will improve. After a few sprints, you will feel the real power of agile: prioritization of work, collaboration, inspection and adjustment, and so on.

In about 5 years time, Agile went from a heard but not familiar methodology to a practice that everyone is implementing. In 2005, I changed jobs and I remember my understanding of Agile was superficial at the time when Test Driven Development was the mainstream. As of 2010, almost all modern software teams have adopted Agile.

From the looks of it at the time, Agile succeeded! Big win! Congratulations everyone!

However, "fighting the world is easy, but defending the world is difficult." Unfortunately, Agile failed to realize the dream of its founders.

• Prioritizing the individual and the interaction proved to be a difficult concept to follow through. It is much easier to popularize processes and tools.

• It turns out that producing software that works is far more difficult than unrealistic plans and extensive documentation.

• It turns out that working with clients requires trust and candor that doesn't necessarily exist in a business setting.

• As it turns out, executives want to be in control, and we need to have long-term plans for their business, which is often more important to react to change. 

• It turns out that agile implementations that are not implemented properly can often feel very confusing.

That doesn't mean the four values ​​of Agile are wrong. It just means that in order to get agile right, we need to put in a lot of effort, in addition to having some courage to accept the inherently chaotic nature of software. You have to understand and believe that as long as you keep learning, adapting, improving and releasing the product, you will eventually be able to achieve better results and achieve more realistic and efficient development than waterfall.

"The Agile movement is not against methodology, in fact many of us want to reshape the credibility of methodology. We want to restore balance. We embrace modeling, but not for the sake of storing diagrams in corporate warehouses. We accept documentation , but no tomes that are never maintained and rarely used. We plan, but we also know the limits of planning in a turbulent environment. Those who call XP, Scrum, and other agile methodologists 'hackers' ignorant of agile methodologies and the original definition of 'hacker'." - Jim Highsmith, "History: The Agile Manifesto"

The above mentioned the key point, agile development still requires planning and documentation, as well as rigorous implementation. This is a matter of degree of control. But if the organization is struggling with an agile transformation and is in disarray, and someone provides certifications, processes, and tools, you're bound to see it as a life-saving straw and grab it. Executives know far more about processes and tools than they do about self-organizing teams.

uprising failed

Unfortunately, however, the agile uprising did not succeed.

Tool vendors, process consultants, and experts make many promises that can never be kept. A lot of people have adopted SAFe, Scaled Scrum, and all the other enterprise agile-style methodologies. These frameworks aren't born out of spite, and in the right circumstances, they even have some value. But I wouldn't call them agile. Attempts to expand a methodology that focuses on individuals and interactions will inevitably raise problems and ultimately erode the original value of the methodology.

Developers should ditch agile

When the "agile" philosophy is not applied properly, it tends to create more distractions for developers, resulting in them actually working less time, being under more pressure, and needing to get things done "faster". This is bad for developers and ultimately bad for business, as such "agility" works very poorly, tends to lead to more bugs, and leads to slower project progress. In such a situation, excellent developers will leave, and the efficiency of the enterprise is not as good as not implementing agile.

agile is dead

The word "agile" has been subverted to mean nothing, and the agile community has become an arena for consultants and vendors to hawk services and products. Back then, the Agile Manifesto was so popular that the word agile became a gold magnet, used to get support, charge money, or sell products, almost like a marketing term.

Therefore, I think it's time for the word "agile" to retire from the stage of history.

to reflect

What's really sad, in my opinion, is seeing young developers denigrate Agile, seeing it as a blank check for management and a means to push development teams to work like crazy. I understand them. In their view, agility is a control mechanism imposed on them, not a self-arming force that they readily accept. But I hope some discussion around the history and original vision helps us remember where Agile should go.

Thankfully, the Agile Manifesto, proposed 20 years ago, is still wise and to the point.

Agile is no longer a hot topic these days. Everyone is implementing Agile. However, on this 20th anniversary, I would like to reflect on the following questions:

• What did you do right?

• What went wrong?

• How can we improve next time?

Those of us living through the Agile revolution wanted to reflect on the original 12 Agile principles and consider their value in the current software development environment.

I hope to examine the fundamentals of agile, learn from past failures, and, in the words of Dave Thomas, stay agile even if we choose to give up being "agile".

Reference link:

https://www.simplethread.com/agile-at-20-the-failed-rebellion