Reflections on Agile
The measure of intelligence is
the ability to change.
Albert einstein
I present the “Reflections on Agile” IT community or can I call this article “Agile, is it still a philosophy or a project methodology?”.
The purpose of this article is to discuss with the IT community the issue of Agile, which I came up with after many years of design practice, the conclusions and summary I came to, based on an analysis of this issue.
The question itself is somewhat lower, because, in order to go to it, it makes sense to present some arguments and conclusions.
')
Similar topics have already been raised on Habré in various branches of the discussion, so the question is vital and has its own history.
In my opinion, most articles do not give a definite answer to my question, so this article may be interesting to many.
Several articles on Habré on the topic:
In order to understand a little where the “wind blows” from, I note that my experience in the ICT field is more than 10 years. At the very beginning of his career he was actively working in telecom, I have been working in software development relatively recently, for no more than four years.
Throughout his career, he participated in various IT and Telecom projects, as a Project Manager, in recent years he has been a business analyst, tried himself and as a programmer. As a result of a brief but extensive immersion in Java, development got not great, but still, the experience of self-development, having mastered technical skills as a junior programmer.
Now I actively work in the field of software development as a Project Manager, optionally acting as a Business Analyst.
Thus, the subject of discussion of this article is the practice of project management for the development of software products, and with reference to domestic development.
Throughout his project experiences in ICT, he derived a key rule for himself: to manage a project using a project methodology is good, without a methodology it is not clear.
In connection with the above, I came to the need to study various project methodologies, ITSM methodologies, different business books on the topic, and simply “smart” and complex books.
Given the popularity of PMI in general and my own telecom industry in particular, I began studying with PMBoK. Although this cunning Talmud was not immediately understood, more than once, while reading the next chapter, I had to think about the fact that it is the compilers of the book who smoke. As a result, the body of knowledge was decomposed into atoms and adopted in full. By the way, not even once implemented in a number of projects with “proletarian zeal”, patience and agility (not PMBoK, of course, but its tools were introduced).
Understanding PMBoK, comes with experience.
@PM
In addition to this “epic” work, other methodologies were investigated and studied, there were also simply authors of books on project management (although such persons as T. Demarko, S. Berkun, S McConnell are not just authors, but something more), do not list all makes sense, and the article is not about that.
To summarize, the author of the article in the subject line, tries to keep up with world trends, does not forget the classics.
Bored on telecom after eight years of work, and deciding to go ahead, he rushed into IT.
It turned out that the IT sector does not want to live in the clear framework of the classic "waterfalls", GOST 34 is not in fashion, unless of course we take into account the State. sector. There are other trends in project management, in global project management.
Agile-manifesto could not pass by. After studying a number of books and talking with several colleagues, I decided that Agile is at least interesting. But it is not entirely clear how to work with it in Russia, philosophy does not reach the methodology, and in our country there is the popular wisdom “what is not forbidden is allowed”.
As a summary: I came to the conclusion, Agile is certainly an interesting thing, but still, it is more suitable for fashion books and small projects, but how to implement it in practice is not clear.
The analysis of articles on Habré, in general, confirmed the brief summary given above.
After several iterations of learning Agile through books, I was “lucky”, I had the opportunity to participate in several domestic Agile projects.
From such Agile it was not fun at all, and the RP with experience in planning and managing projects from the telecom industry simply became sad. When trying to control the spontaneous development of such good fellows, everything breaks down completely, and the guys in unison say: "We are creative, we have Agile, do not interfere with living / working / developing." They don't want to learn and think, they only have Agile in their heads.
But despite my skepticism, Agile marched around the country, he was actively promoted by G. Gref and professed by various Western and domestic gurus of the IT industry.
But, as personal experience showed, Agile uses everything in its own way, with our mentality we simply created “Agile in Russian”.
As a result, the question grew and got stronger, and no one could give me the answer to it.
What is this Agile, a philosophical stack of ideas on the psychology and organization of labor, the craziness of reason, and no desire to work by the rules, or is there something that is more serious from a methodological point of view, something that can be applied to us homeland, on serious projects, what is worth attention?
Before completing this section, there are several points worth noting:
The book by Lawrence Lich, “On Time and Within Budget”
An interesting book about project management according to the “Critical Chain” method, the author can be attributed to the ideologists of heavy management. The book of L. Lich describes a difficult but extremely interesting approach to the application of the theories of E. Deming and E. Goldratt in project planning.
Given the acquired theoretical and practical knowledge, the understanding of the incompleteness of understanding of Agile as a methodology for its adequate implementation in domestic projects has strengthened.
Correct Agile or adaptive PMBoK from Mike Cohn.
Quite by chance, or as they say, "suddenly out of nowhere," I came across another book about Agile. This is a book written by a certain Mike Cohn (Cohn Mike) entitled “Agile. Project Evaluation and Planning. ”
At the beginning, he suggested that this is another business book describing that Agile is cool, fashionable, youth.
So it was decided to read the preface, but when reading the first chapter, it became interesting who this is, this Mike Cohn, and why he writes such correct things.
A brief overview of who Mike Cohn is (Cohn Mike)
Founder of Mountain Goat Software, a consulting and project management firm. He specializes in helping companies apply an agile approach to improve efficiency. Mike has more than 20 years of experience as a leader in organizations of various sizes, from a startup to a Fortune 40 company. He is a co-founder of the Agile Alliance and is on its board of directors.
I do not plan to describe the book in full in this article, since it is better to read it myself (for those who need it), but I will mention the main thing, Mike’s book is a revised PMBoK PMI taking into account the Agile-manifest philosophy.
Immediately I will note that Mike did not write another set of knowledge, boring and incomprehensible, he did not copy PMBoK. Instead, Mike Cohn created an interesting, easy-to-read and relevant book:
The book describes the entire life cycle of the project, focuses on the project planning stage, describes very interesting and sound methods and approaches to planning and evaluating the work, and also describes the approaches and tools of the project execution stages, the monitoring and control stages.
Despite the fact that the book struck me by its functionality, applicability, and methodological maturity, Mike also used the extremely interesting and hard-to-describe method for mitigating the risks of uncertainty, described by Lawrence Lich in his book. With all the above, Mike suggests using simple and understandable language how to implement and expand this method in practice.
To build any process, we need rules, norms and principles, Mike described them for us.
In my opinion, we are faced with several interesting questions since 2001:
Do we need Agile philosophy, methodology, or are principles sufficient for us?
Do we want to develop high-quality software efficiently and clearly, or will we leave this prerogative elected, and continue to “invent a bicycle”?
Mike's book, in my opinion, determines the rules from which many want to leave, but as experience shows, the rules are still needed.
In addition to the above, Mike’s book provides clear methodological guidelines (although some may not like this word) about how to manage Agile software development projects.
In any case, everything will be as it will be, but one thing is clear, the rules and principles are needed in everything, and in Agile they are.
These principles are described and fixed, they can be studied, they can be used.
To finalize your resume, I will mark the following:
Ageli is not in a crisis, Agile is not a problem, Agile is working.
The only question is whether we want to learn the rules and do what they prescribe or we want to continue to work as we want.
Never lose a holy curiosity.
Albert einstein
PS
Dear readers, who still read the article, I am very interested in your opinions and comments, as well as recommendations on similar books, such as the book by Mike Cohn.
the ability to change.
Albert einstein
Foreword
I present the “Reflections on Agile” IT community or can I call this article “Agile, is it still a philosophy or a project methodology?”.
The purpose of this article is to discuss with the IT community the issue of Agile, which I came up with after many years of design practice, the conclusions and summary I came to, based on an analysis of this issue.
The question itself is somewhat lower, because, in order to go to it, it makes sense to present some arguments and conclusions.
')
Similar topics have already been raised on Habré in various branches of the discussion, so the question is vital and has its own history.
In my opinion, most articles do not give a definite answer to my question, so this article may be interesting to many.
Several articles on Habré on the topic:
- Agile: the biggest ideological issue in IT. (April 19, 2019)
- Why Agile is not working and what to do about it. (December 20, 2017)
- Agile crisis. What to do? (June 23, 2019)
Briefly about the subject matter
In order to understand a little where the “wind blows” from, I note that my experience in the ICT field is more than 10 years. At the very beginning of his career he was actively working in telecom, I have been working in software development relatively recently, for no more than four years.
Throughout his career, he participated in various IT and Telecom projects, as a Project Manager, in recent years he has been a business analyst, tried himself and as a programmer. As a result of a brief but extensive immersion in Java, development got not great, but still, the experience of self-development, having mastered technical skills as a junior programmer.
Now I actively work in the field of software development as a Project Manager, optionally acting as a Business Analyst.
Thus, the subject of discussion of this article is the practice of project management for the development of software products, and with reference to domestic development.
Understanding of the issue by the author
Throughout his project experiences in ICT, he derived a key rule for himself: to manage a project using a project methodology is good, without a methodology it is not clear.
In connection with the above, I came to the need to study various project methodologies, ITSM methodologies, different business books on the topic, and simply “smart” and complex books.
Given the popularity of PMI in general and my own telecom industry in particular, I began studying with PMBoK. Although this cunning Talmud was not immediately understood, more than once, while reading the next chapter, I had to think about the fact that it is the compilers of the book who smoke. As a result, the body of knowledge was decomposed into atoms and adopted in full. By the way, not even once implemented in a number of projects with “proletarian zeal”, patience and agility (not PMBoK, of course, but its tools were introduced).
Understanding PMBoK, comes with experience.
@PM
In addition to this “epic” work, other methodologies were investigated and studied, there were also simply authors of books on project management (although such persons as T. Demarko, S. Berkun, S McConnell are not just authors, but something more), do not list all makes sense, and the article is not about that.
To summarize, the author of the article in the subject line, tries to keep up with world trends, does not forget the classics.
Deep dive in project management of Software
Bored on telecom after eight years of work, and deciding to go ahead, he rushed into IT.
It turned out that the IT sector does not want to live in the clear framework of the classic "waterfalls", GOST 34 is not in fashion, unless of course we take into account the State. sector. There are other trends in project management, in global project management.
Agile-manifesto could not pass by. After studying a number of books and talking with several colleagues, I decided that Agile is at least interesting. But it is not entirely clear how to work with it in Russia, philosophy does not reach the methodology, and in our country there is the popular wisdom “what is not forbidden is allowed”.
As a summary: I came to the conclusion, Agile is certainly an interesting thing, but still, it is more suitable for fashion books and small projects, but how to implement it in practice is not clear.
The analysis of articles on Habré, in general, confirmed the brief summary given above.
After several iterations of learning Agile through books, I was “lucky”, I had the opportunity to participate in several domestic Agile projects.
From such Agile it was not fun at all, and the RP with experience in planning and managing projects from the telecom industry simply became sad. When trying to control the spontaneous development of such good fellows, everything breaks down completely, and the guys in unison say: "We are creative, we have Agile, do not interfere with living / working / developing." They don't want to learn and think, they only have Agile in their heads.
But despite my skepticism, Agile marched around the country, he was actively promoted by G. Gref and professed by various Western and domestic gurus of the IT industry.
But, as personal experience showed, Agile uses everything in its own way, with our mentality we simply created “Agile in Russian”.
As a result, the question grew and got stronger, and no one could give me the answer to it.
What is this Agile, a philosophical stack of ideas on the psychology and organization of labor, the craziness of reason, and no desire to work by the rules, or is there something that is more serious from a methodological point of view, something that can be applied to us homeland, on serious projects, what is worth attention?
Before completing this section, there are several points worth noting:
- After the release of the 6th edition of PMBoK in 2018, the issue of Agile became even more interesting (in the 6th edition, the authors included cases using Agile).
- I came across for reading the book by Lawrence Lich, “On time and within budget”.
The book by Lawrence Lich, “On Time and Within Budget”
An interesting book about project management according to the “Critical Chain” method, the author can be attributed to the ideologists of heavy management. The book of L. Lich describes a difficult but extremely interesting approach to the application of the theories of E. Deming and E. Goldratt in project planning.
Given the acquired theoretical and practical knowledge, the understanding of the incompleteness of understanding of Agile as a methodology for its adequate implementation in domestic projects has strengthened.
Endgame
Correct Agile or adaptive PMBoK from Mike Cohn.
Quite by chance, or as they say, "suddenly out of nowhere," I came across another book about Agile. This is a book written by a certain Mike Cohn (Cohn Mike) entitled “Agile. Project Evaluation and Planning. ”
At the beginning, he suggested that this is another business book describing that Agile is cool, fashionable, youth.
So it was decided to read the preface, but when reading the first chapter, it became interesting who this is, this Mike Cohn, and why he writes such correct things.
A brief overview of who Mike Cohn is (Cohn Mike)
Founder of Mountain Goat Software, a consulting and project management firm. He specializes in helping companies apply an agile approach to improve efficiency. Mike has more than 20 years of experience as a leader in organizations of various sizes, from a startup to a Fortune 40 company. He is a co-founder of the Agile Alliance and is on its board of directors.
I do not plan to describe the book in full in this article, since it is better to read it myself (for those who need it), but I will mention the main thing, Mike’s book is a revised PMBoK PMI taking into account the Agile-manifest philosophy.
Immediately I will note that Mike did not write another set of knowledge, boring and incomprehensible, he did not copy PMBoK. Instead, Mike Cohn created an interesting, easy-to-read and relevant book:
- Described the principles and rules that should be in Agile;
- Described the tools for planning and evaluating work;
- Gave insight and competent development management;
- And much more.
The book describes the entire life cycle of the project, focuses on the project planning stage, describes very interesting and sound methods and approaches to planning and evaluating the work, and also describes the approaches and tools of the project execution stages, the monitoring and control stages.
Despite the fact that the book struck me by its functionality, applicability, and methodological maturity, Mike also used the extremely interesting and hard-to-describe method for mitigating the risks of uncertainty, described by Lawrence Lich in his book. With all the above, Mike suggests using simple and understandable language how to implement and expand this method in practice.
To build any process, we need rules, norms and principles, Mike described them for us.
Summary
In my opinion, we are faced with several interesting questions since 2001:
Do we need Agile philosophy, methodology, or are principles sufficient for us?
Do we want to develop high-quality software efficiently and clearly, or will we leave this prerogative elected, and continue to “invent a bicycle”?
Mike's book, in my opinion, determines the rules from which many want to leave, but as experience shows, the rules are still needed.
In addition to the above, Mike’s book provides clear methodological guidelines (although some may not like this word) about how to manage Agile software development projects.
In any case, everything will be as it will be, but one thing is clear, the rules and principles are needed in everything, and in Agile they are.
These principles are described and fixed, they can be studied, they can be used.
To finalize your resume, I will mark the following:
Ageli is not in a crisis, Agile is not a problem, Agile is working.
The only question is whether we want to learn the rules and do what they prescribe or we want to continue to work as we want.
Never lose a holy curiosity.
Albert einstein
PS
Dear readers, who still read the article, I am very interested in your opinions and comments, as well as recommendations on similar books, such as the book by Mike Cohn.
Source: https://habr.com/ru/post/460709/
All Articles