Evolutionary development management - a guaranteed path to success
Having studied and tested several variants of Agile project management in practice, I came across situations dozens of times when a beautiful theory does not work in practice. People are simply unable to foresee their future and more or less adequately assess the time and their own strength, regardless of how many stages the project is split into and how beautifully all the control charts and tables are drawn. When we turned the design in the 35th time - it already seemed that the situation is simply hopeless and only a miracle can save us.
And just recently I learned that in the world there has long been such a method of developing information systems - Evo (from the word “evolution”), which makes project failures fundamentally impossible! Failure here means uncontrolled growth of terms, budget, staff of the development team, general negative; and the failure to achieve predetermined and measurable goals.
The authors of this evolutionary project management system Tom and Kai Gilb, unfortunately, reveal all the numerous details and tricks of their methodology only at their paid seminars, however, a general idea of ​​their idea can be fully done and having summarized several scattered articles, which I will now do in my a brief overview.
')
For any person, the main challenge in life and the most difficult test is always the management and control of something. A car, a family, a career, a team, and processes - and nothing can be more responsible and risky in life. And any failure in management entails the most serious catastrophes, and that is why people believe that control over any process must be constantly strengthened, increasing the number of restrictions to infinity. Once it seemed to me that only the growth of the framework in a geometrical progression gives the project a chance of success, because the main thing is to set all these frameworks correctly and in advance.
As a rule, with this approach, it is instantly forgotten that no one in the world is able to foresee the future and describe in detail even his future, not to mention the future of the whole team that creates information systems. At the same time, everyone and always, in the smallest detail, predict the future of any new project and expect from the manager only beyond their abilities bordering on the ability to manage space-time. When he does not find such in himself, then both the Customer and the whole team are very sincerely disappointed. In the meantime, some companies have already found a new way to manage their projects, in which it is possible not only to systematically avoid failures, but at the same time to permanently receive - and significant product improvements for customers, and increased enthusiasm among management and the engineering team.
The Evo-method described in the article is so effective because it solves the most key problems - constant delays of large projects, uncontrolled growth of functionality and additions to the primary Terms of Reference, constant deviation from the original prototypes and general misunderstanding by the team and the customer himself of the main goals of the created system.
I think no one will deny that the traditional method of “Waterfall” is very outdated, and now only the laziest studios do not use the tactics of small iterations over time, splitting up a large task into several small ones. So, in the companies HP and Confirmit practice a cycle in 1 week, Microsoft applies a six-week cycle; but it turns out that in practice this does not always help. Quite often there are situations when the initial prototype (Main layout, TZ, sprint zero - underline) is wrapped and sent for processing 10, 20, 30 times. Programmers and testers, layout designers and your servers are still gathering dust, and super-melting activity in the very first step mixes tens of thousands of hours and dollars into slag without apparent success. What to do?
This technique is not similar to planning in the form in which all conservative managers are used to seeing it. Rather, she learns from nature itself, comparing the creation of an information system with the process of raising a child or growing flowers in her bed.
Agree, you can't give out a flower to your flower, clearly regulating: what number and at what time it is obliged to bloom, what size in centimeters it should grow and how many leaves to have - you have no idea how many sunny and rainy days there will be , you cannot foresee the appearance of parasites, the fall of a meteorite, the shadow of a nearby flower, etc. That is why writing a TK for a flower seems ridiculous to you.
And now try to imagine how parents in the 70s of the last century try to write a life plan for their own daughter. I imagine such a clear strategy for its further advancement in life: learn to be an engineer (the most prestigious profession), then marry a man named Vasya at 21, give birth to a boy at 22, a girl at 25, join the Party at 30 40 the first time to go on a trip abroad - to Bulgaria! It sounds even funnier.
However, creating an information system with a life cycle of 2-3, or even 5 years - each of us does not see anything funny in order to predict in advance to the pixels - what functionality the system will need. And then we are all very perplexed when, in a couple of years, it turns out that the project did not grow up at all what was planned in advance.
The main problem of all product managers is that we, with our plans and TK, intervened in the natural process of evolution, which we have no idea about. The Evo methodology uses the minimum initial requirements, coupled with early and constant feedback on the ongoing processes, in order to timely adjust the growth and development of the product. No one is ever able to comprehend and foresee a million factors in advance, but this is not required in the Evo methodology. Observation, sanity and constant point adjustments - this minimum is enough to guarantee the great success of any product created.
Of course, evolutionary management also exactly divides each project into several evolutionary cycles. However, this decomposition at the beginning of the path does not imply knowledge of either the deadlines or the total number of these cycles. The first evolutionary cycle is the solution of the first problem “To achieve Objective No. 1 in the simplest way” followed by the analytics “What happened in the end?”. In fact, the main difference between evolution and standard methods: all programmers, customers, designers, scrammasters are constantly learning and changing, just like the project itself. Every week the product becomes slightly different: a little more, a little better, a little more convenient, a little more popular. At the same time, it is impossible to say that this methodology simply declares to "go with the flow", on the contrary - Evo is focused on achieving agreed goals and solving clear objectives. And just to achieve the optimal effect - all the requirements expressed quantitatively in the form of the value and quality of the final product - are weekly mutated and trained along with everyone. This is how you can give a chance to any information system to improve endlessly, dynamically changing priorities at the most minimal development costs - simply because you do not do anything extra.
Evolutionary methodology does not allow people to build sand castles in which to lock from the real world with their great ideas and spend too many resources on understanding that it will not work. She suggests starting any site with a simple stub, Landing with one button, and then, as the customer and his staff grows, adding all new and new pages, products and services, interactive features and marketing features. You will no longer need to sell an apartment to immediately make a cool site - make a simple page to earn further budgets for the development of the entire business as a whole.
No matter how experienced each of us is, unpredictable ways to destroy your project are always far more than you can foresee. I will list from my own experience only the most popular ones:
• Too much pride from the original idea and unwillingness to change anything,
• Indifference and extreme non-observance of the entire development team,
• Erected in the sacred status of inattention to trifles,
• Lack of self-discipline with each final executor: waiting for a letter, order, kick to start thinking about the project,
• Belief that problems are solved by number (people, days, money), not by skill,
• Lack of the slightest measurable system for evaluating the results obtained,
• The “Make and forget as soon as possible” approach
• Failure to understand the factor that the main resource in any information system is people
• Cruel punishment for any failure, instead of a reason to carefully analyze the wrong steps and become better,
• Creating all sorts of additional restrictions to build the system itself,
• Attempts to make a very general decision for all at once with an infinite scale for the growth of functions,
• Attempts to control and impose, rather than analyze and learn,
• And so on to infinity ...
To conclude my review, I’ll say right away that the author, like all of you, did not attend the live seminars of the authors of this methodology, and did not test this methodology with several years of practice in order to draw more reasonable conclusions. Moreover, I am ready to admit that I may have somewhat misunderstood or poorly translated some of the postulates of this technique - that is why I will forgive your help in the comments to supplement my article with other useful materials on the topic that will help all readers who come after you to get in the comments a more complete picture of the unsubscribed method of management.
Below I will list the main trailers of Evo as I understood them for myself:
1. As quickly as possible to get the first real results, which will be the basis for the next round of evolution;
2. The next evolutionary step should be exactly the one that ensures the achievement of the adjusted goals and objectives following the first stage,
3. Leaveyour children alone in your project - this is the best thing you can do,
4. Recognition to oneself about the complete absence of extrasensory and astrological talent, and in this connection once and for all eradicating the habit of making predictions and demands with a mentor tone,
5. Evolution implies the principle of open architecture - any section, block, point, page should be able to be completely corrected in 5-10 minutes without redrawing the entire platform.
6. You should not be afraid of change. Change everything so often - as they should,
7. The entire team of the Evo project should be fully focused on the current evolution. No one should stand idle for a week, a month, a year, waiting for approval, confirmation, inclusion in the work. To succeed or fail in the current step - only all together, without the most guilty and left out with clean hands. No one will spend their energy on the subsequent stages, joining the project halfway and not comprehending the whole history and principles of its growth from the very beginning.
8. The Evo Methodology is all about learning. Guru, mentors and "starred" there is no place,
9. Get rid of all the bad as soon as possible, do not expect a miracle
10. Do not give up half a victory.
And just recently I learned that in the world there has long been such a method of developing information systems - Evo (from the word “evolution”), which makes project failures fundamentally impossible! Failure here means uncontrolled growth of terms, budget, staff of the development team, general negative; and the failure to achieve predetermined and measurable goals.
The authors of this evolutionary project management system Tom and Kai Gilb, unfortunately, reveal all the numerous details and tricks of their methodology only at their paid seminars, however, a general idea of ​​their idea can be fully done and having summarized several scattered articles, which I will now do in my a brief overview.
')
Do not fail the deadlines - how can this be?
For any person, the main challenge in life and the most difficult test is always the management and control of something. A car, a family, a career, a team, and processes - and nothing can be more responsible and risky in life. And any failure in management entails the most serious catastrophes, and that is why people believe that control over any process must be constantly strengthened, increasing the number of restrictions to infinity. Once it seemed to me that only the growth of the framework in a geometrical progression gives the project a chance of success, because the main thing is to set all these frameworks correctly and in advance.
As a rule, with this approach, it is instantly forgotten that no one in the world is able to foresee the future and describe in detail even his future, not to mention the future of the whole team that creates information systems. At the same time, everyone and always, in the smallest detail, predict the future of any new project and expect from the manager only beyond their abilities bordering on the ability to manage space-time. When he does not find such in himself, then both the Customer and the whole team are very sincerely disappointed. In the meantime, some companies have already found a new way to manage their projects, in which it is possible not only to systematically avoid failures, but at the same time to permanently receive - and significant product improvements for customers, and increased enthusiasm among management and the engineering team.
The Evo-method described in the article is so effective because it solves the most key problems - constant delays of large projects, uncontrolled growth of functionality and additions to the primary Terms of Reference, constant deviation from the original prototypes and general misunderstanding by the team and the customer himself of the main goals of the created system.
I think no one will deny that the traditional method of “Waterfall” is very outdated, and now only the laziest studios do not use the tactics of small iterations over time, splitting up a large task into several small ones. So, in the companies HP and Confirmit practice a cycle in 1 week, Microsoft applies a six-week cycle; but it turns out that in practice this does not always help. Quite often there are situations when the initial prototype (Main layout, TZ, sprint zero - underline) is wrapped and sent for processing 10, 20, 30 times. Programmers and testers, layout designers and your servers are still gathering dust, and super-melting activity in the very first step mixes tens of thousands of hours and dollars into slag without apparent success. What to do?
Let all the flowers bloom
This technique is not similar to planning in the form in which all conservative managers are used to seeing it. Rather, she learns from nature itself, comparing the creation of an information system with the process of raising a child or growing flowers in her bed.
Agree, you can't give out a flower to your flower, clearly regulating: what number and at what time it is obliged to bloom, what size in centimeters it should grow and how many leaves to have - you have no idea how many sunny and rainy days there will be , you cannot foresee the appearance of parasites, the fall of a meteorite, the shadow of a nearby flower, etc. That is why writing a TK for a flower seems ridiculous to you.
And now try to imagine how parents in the 70s of the last century try to write a life plan for their own daughter. I imagine such a clear strategy for its further advancement in life: learn to be an engineer (the most prestigious profession), then marry a man named Vasya at 21, give birth to a boy at 22, a girl at 25, join the Party at 30 40 the first time to go on a trip abroad - to Bulgaria! It sounds even funnier.
However, creating an information system with a life cycle of 2-3, or even 5 years - each of us does not see anything funny in order to predict in advance to the pixels - what functionality the system will need. And then we are all very perplexed when, in a couple of years, it turns out that the project did not grow up at all what was planned in advance.
The main problem of all product managers is that we, with our plans and TK, intervened in the natural process of evolution, which we have no idea about. The Evo methodology uses the minimum initial requirements, coupled with early and constant feedback on the ongoing processes, in order to timely adjust the growth and development of the product. No one is ever able to comprehend and foresee a million factors in advance, but this is not required in the Evo methodology. Observation, sanity and constant point adjustments - this minimum is enough to guarantee the great success of any product created.
Of course, evolutionary management also exactly divides each project into several evolutionary cycles. However, this decomposition at the beginning of the path does not imply knowledge of either the deadlines or the total number of these cycles. The first evolutionary cycle is the solution of the first problem “To achieve Objective No. 1 in the simplest way” followed by the analytics “What happened in the end?”. In fact, the main difference between evolution and standard methods: all programmers, customers, designers, scrammasters are constantly learning and changing, just like the project itself. Every week the product becomes slightly different: a little more, a little better, a little more convenient, a little more popular. At the same time, it is impossible to say that this methodology simply declares to "go with the flow", on the contrary - Evo is focused on achieving agreed goals and solving clear objectives. And just to achieve the optimal effect - all the requirements expressed quantitatively in the form of the value and quality of the final product - are weekly mutated and trained along with everyone. This is how you can give a chance to any information system to improve endlessly, dynamically changing priorities at the most minimal development costs - simply because you do not do anything extra.
Evolutionary methodology does not allow people to build sand castles in which to lock from the real world with their great ideas and spend too many resources on understanding that it will not work. She suggests starting any site with a simple stub, Landing with one button, and then, as the customer and his staff grows, adding all new and new pages, products and services, interactive features and marketing features. You will no longer need to sell an apartment to immediately make a cool site - make a simple page to earn further budgets for the development of the entire business as a whole.
Million ways to kill your project
No matter how experienced each of us is, unpredictable ways to destroy your project are always far more than you can foresee. I will list from my own experience only the most popular ones:
• Too much pride from the original idea and unwillingness to change anything,
• Indifference and extreme non-observance of the entire development team,
• Erected in the sacred status of inattention to trifles,
• Lack of self-discipline with each final executor: waiting for a letter, order, kick to start thinking about the project,
• Belief that problems are solved by number (people, days, money), not by skill,
• Lack of the slightest measurable system for evaluating the results obtained,
• The “Make and forget as soon as possible” approach
• Failure to understand the factor that the main resource in any information system is people
• Cruel punishment for any failure, instead of a reason to carefully analyze the wrong steps and become better,
• Creating all sorts of additional restrictions to build the system itself,
• Attempts to make a very general decision for all at once with an infinite scale for the growth of functions,
• Attempts to control and impose, rather than analyze and learn,
• And so on to infinity ...
To conclude my review, I’ll say right away that the author, like all of you, did not attend the live seminars of the authors of this methodology, and did not test this methodology with several years of practice in order to draw more reasonable conclusions. Moreover, I am ready to admit that I may have somewhat misunderstood or poorly translated some of the postulates of this technique - that is why I will forgive your help in the comments to supplement my article with other useful materials on the topic that will help all readers who come after you to get in the comments a more complete picture of the unsubscribed method of management.
Below I will list the main trailers of Evo as I understood them for myself:
1. As quickly as possible to get the first real results, which will be the basis for the next round of evolution;
2. The next evolutionary step should be exactly the one that ensures the achievement of the adjusted goals and objectives following the first stage,
3. Leave
4. Recognition to oneself about the complete absence of extrasensory and astrological talent, and in this connection once and for all eradicating the habit of making predictions and demands with a mentor tone,
5. Evolution implies the principle of open architecture - any section, block, point, page should be able to be completely corrected in 5-10 minutes without redrawing the entire platform.
6. You should not be afraid of change. Change everything so often - as they should,
7. The entire team of the Evo project should be fully focused on the current evolution. No one should stand idle for a week, a month, a year, waiting for approval, confirmation, inclusion in the work. To succeed or fail in the current step - only all together, without the most guilty and left out with clean hands. No one will spend their energy on the subsequent stages, joining the project halfway and not comprehending the whole history and principles of its growth from the very beginning.
8. The Evo Methodology is all about learning. Guru, mentors and "starred" there is no place,
9. Get rid of all the bad as soon as possible, do not expect a miracle
10. Do not give up half a victory.
Source: https://habr.com/ru/post/289266/
All Articles