April 5, 2015 at 09:55Evolutionary Development Management - A Guaranteed Path to Success
Having studied and tested in practice several options for Agile project management, I have come across dozens of times situations when a beautiful theory does not work in practice. People simply are not able to predict their future and more or less adequately assess time and their own strengths, regardless of how many stages the project is fragmented and how beautifully all the control charts and tables are drawn. When the design was wrapped up for the 35th time, it seemed to us that the situation was simply hopeless and only a miracle could save us.
And just recently, I learned that in the world there has long been such a methodology for developing information systems - Evo (from the word "evolution"), which makes project failures fundamentally impossible! Failure here means an uncontrolled increase in terms, budget, composition of the development team, general negative; and 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 made and summing up several disparate articles, which I will now do in my brief review.
For any person, the main challenge in life and the most difficult test is always the management and control of something. By car, family, career, team, and processes - nothing more responsible and risky in life ever happens. And any failure in management entails the most serious disasters, and that is why people believe that control over any process should be constantly strengthened, increasing the number of restrictions to infinity. Once it seemed to me that only the growth of frames exponentially gives the project a chance of success, because the main thing is to correctly and pre-arrange all these frames.
As a rule, with this approach, it is instantly forgotten that not a single person in the world is able to foresee the future and describe in detail even his tomorrow, not to mention the tomorrow of the whole team creating information systems. At the same time, everyone always and in great detail predicts the future of any new project and expects from the manager only over abilities bordering on the ability to manage space-time. When he does not find such in himself, then the Customer and the whole team are very sincerely disappointed. Meanwhile, some companies have already found a new way to manage their projects, in which it is possible not only to systematically avoid failures, but to permanently receive significant product improvements for customers, and increased enthusiasm among the management and team of engineers.
The Evo-method described in the article is so effective because it solves the most key problems - constant delays in large projects, uncontrolled growth of functionality and additions to the initial Terms of Reference, constant departure from the initial prototypes and a general misunderstanding by the team and the customer themselves of the main goals of the system being created.
I think no one will deny that the traditional Waterfall method is very outdated, and now only the most lazy studios do not use the tactics of small iterations in time, breaking up a large task into several small ones. So, at HP and Confirmit, they have a 1-week cycle; Microsoft uses a six-week cycle; but it turns out that in practice this does not always help. Very often there are situations when the initial prototype (the layout of the Main, TK, sprint zero - underline as necessary) is wrapped up and given for processing 10, 20, 30 times. Programmers and testers, layout designers and your servers are gathering dust while idle, and the super-fluid activity at the very first step mixes tens of thousands of hours and dollars into slag without visible success. What to do?
This technique is not like 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 flower bed.
You must admit that you cannot give your flower a document that clearly regulates: what date and at what time it is obligated to bloom, what size in centimeters it should grow and how many leaves to have - because you have no idea how many sunny and rainy days there will be in a year , you can’t foresee the appearance of parasites, a meteorite fall, a shadow from a neighboring flower, etc. That is why writing TK for a flower seems ridiculous to you.
Now try to imagine how parents in the 70s of the last century try to write a plan for life for their own daughter. I imagine such a clear strategy for her further advancement in life: to be an engineer (the most prestigious profession), then to marry a man named Vasya at 21, give birth to a boy at 22, a girl at 25, and join the Party at 30, 40 for the first time to go on a trip abroad - to Bulgaria! That 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 to predict in advance what pixels the system will need. And then we are all very perplexed when, after a couple of years, it turns out that the project did not grow at all as planned before.
The main problem of all product managers is that we, with our plans and TK, intervened in the natural process of evolution, of which we have no idea. The Evo methodology uses the minimum initial requirements, coupled with early and constant feedback on ongoing processes in order to timely adjust the growth and development of the product. No one can ever comprehend and anticipate 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 likewise 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 cycle of evolution is the solution to the first task, “Achieve Goals No. 1 in the simplest way”, followed by analytics “What happened in the end?”. In fact, the main difference between evolution and standard techniques: all programmers, customers, designers, scrammasters, are constantly learning and changing, like the project itself. Each week the product becomes a little different: a little more, a little better, a little more convenient, a little more popular. At the same time, it cannot be said that this technique simply declares “to go with the flow,” on the contrary, Evo is focused on achieving agreed goals and solving clear problems. And just to achieve the optimal effect - all the requirements, quantified in the form of value and quality of the final product, they mutate weekly and learn with everyone. This is how you can give a chance to any information system to improve infinitely, dynamically changing priorities with the lowest development costs - simply because you are not doing anything superfluous.
Evolutionary methodology does not allow people to build sand castles in which to lock themselves away from the real world with their great ideas and spend too much resources on understanding that they won’t work. She offers to start any site with a simple stub, a one-button landing, and then, as the customer and his own staff grow, add more and more pages, products and services, interactive features and marketing chips. You will no longer need to sell an apartment to DIRECTLY make a cool website - make a simple page to earn yourself further budgets for the development of the entire business as a whole.
No matter how experienced each of us is, the unpredictable ways to destroy your project are always much more than you can foresee. From my own experience I will list only the most popular of them:
• Too much pride from the initial idea and unwillingness to change anything,
• Indifference and extreme lack of supervision of the entire development team
,
• Inattention to details, elevated to sacred status, • Lack of self-discipline for each final artist: waiting for a letter , order, kick to start thinking about the project,
• Belief that problems are solved by number (people, days, money), and not by skill,
• Lack of the slightest measurable system for evaluating the results,
• The “Let's make it and forget it soon” approach
• Misunderstanding of the factor that the main resource in any information system is people,
• Cruel punishment for any failures, instead of the reason to carefully analyze the wrong steps and become better,
• Creating all kinds of additional restrictions before building the system itself,
• Attempts to make a very general decision right away for all with an infinite scale for the growth of functions,
• Attempts to control and impose, rather than analyze and learn,
• And so on to infinity ...
At the end of my review, I’ll say right away that the author, like all of you, was not present at the live seminars of the authors of this technique, nor did he run around this technique for several years of practice in order to draw more sound conclusions. Moreover, I’m ready to admit that I may have misunderstood or misinterpreted some of the principles of this methodology - that’s 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 management method.
Below I will list the main Evo trailers 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 adjusted goals and objectives as a result of the first stage,
3. Leaveyour children your project alone is the best you can do,
4. Recognition to yourself about the complete absence of extrasensory and astrological talent, and in this regard, once and for all eradicating the habit of making forecasts and requirements in a mentor tone,
5. Evolution implies the principle of open architecture - any section, block, paragraph, page should be able to fully use Board in 5-10 minutes without redrawing the entire platform,
6. You should not be afraid of changes. Change everything as often as you should,
7. The entire team of the Evo project should be entirely focused on the current round of evolution. No one should stand idle for a week, month, year, pending approval, confirmation, inclusion in the work. Succeeding or failing in the current step - only all together, without the most guilty and left aside with clean hands. No one will spend their energy in the subsequent stages, having joined the project halfway and not comprehending the whole history and principles of its growth from the very beginning.
8. The Evo Methodology is solid learning. There is no place for gurus, mentors, and “stars”,
9. Get rid of all the bad things as early as possible, do not expect a miracle,
10. Do not give up half a step from victory.
And just recently, I learned that in the world there has long been such a methodology for developing information systems - Evo (from the word "evolution"), which makes project failures fundamentally impossible! Failure here means an uncontrolled increase in terms, budget, composition of the development team, general negative; and 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 made and summing up several disparate articles, which I will now do in my brief review.
Do not miss the deadlines - but 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. By car, family, career, team, and processes - nothing more responsible and risky in life ever happens. And any failure in management entails the most serious disasters, and that is why people believe that control over any process should be constantly strengthened, increasing the number of restrictions to infinity. Once it seemed to me that only the growth of frames exponentially gives the project a chance of success, because the main thing is to correctly and pre-arrange all these frames.
As a rule, with this approach, it is instantly forgotten that not a single person in the world is able to foresee the future and describe in detail even his tomorrow, not to mention the tomorrow of the whole team creating information systems. At the same time, everyone always and in great detail predicts the future of any new project and expects from the manager only over abilities bordering on the ability to manage space-time. When he does not find such in himself, then the Customer and the whole team are very sincerely disappointed. Meanwhile, some companies have already found a new way to manage their projects, in which it is possible not only to systematically avoid failures, but to permanently receive significant product improvements for customers, and increased enthusiasm among the management and team of engineers.
The Evo-method described in the article is so effective because it solves the most key problems - constant delays in large projects, uncontrolled growth of functionality and additions to the initial Terms of Reference, constant departure from the initial prototypes and a general misunderstanding by the team and the customer themselves of the main goals of the system being created.
I think no one will deny that the traditional Waterfall method is very outdated, and now only the most lazy studios do not use the tactics of small iterations in time, breaking up a large task into several small ones. So, at HP and Confirmit, they have a 1-week cycle; Microsoft uses a six-week cycle; but it turns out that in practice this does not always help. Very often there are situations when the initial prototype (the layout of the Main, TK, sprint zero - underline as necessary) is wrapped up and given for processing 10, 20, 30 times. Programmers and testers, layout designers and your servers are gathering dust while idle, and the super-fluid activity at the very first step mixes tens of thousands of hours and dollars into slag without visible success. What to do?
Let all the flowers bloom
This technique is not like 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 flower bed.
You must admit that you cannot give your flower a document that clearly regulates: what date and at what time it is obligated to bloom, what size in centimeters it should grow and how many leaves to have - because you have no idea how many sunny and rainy days there will be in a year , you can’t foresee the appearance of parasites, a meteorite fall, a shadow from a neighboring flower, etc. That is why writing TK for a flower seems ridiculous to you.
Now try to imagine how parents in the 70s of the last century try to write a plan for life for their own daughter. I imagine such a clear strategy for her further advancement in life: to be an engineer (the most prestigious profession), then to marry a man named Vasya at 21, give birth to a boy at 22, a girl at 25, and join the Party at 30, 40 for the first time to go on a trip abroad - to Bulgaria! That 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 to predict in advance what pixels the system will need. And then we are all very perplexed when, after a couple of years, it turns out that the project did not grow at all as planned before.
The main problem of all product managers is that we, with our plans and TK, intervened in the natural process of evolution, of which we have no idea. The Evo methodology uses the minimum initial requirements, coupled with early and constant feedback on ongoing processes in order to timely adjust the growth and development of the product. No one can ever comprehend and anticipate 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 likewise 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 cycle of evolution is the solution to the first task, “Achieve Goals No. 1 in the simplest way”, followed by analytics “What happened in the end?”. In fact, the main difference between evolution and standard techniques: all programmers, customers, designers, scrammasters, are constantly learning and changing, like the project itself. Each week the product becomes a little different: a little more, a little better, a little more convenient, a little more popular. At the same time, it cannot be said that this technique simply declares “to go with the flow,” on the contrary, Evo is focused on achieving agreed goals and solving clear problems. And just to achieve the optimal effect - all the requirements, quantified in the form of value and quality of the final product, they mutate weekly and learn with everyone. This is how you can give a chance to any information system to improve infinitely, dynamically changing priorities with the lowest development costs - simply because you are not doing anything superfluous.
Evolutionary methodology does not allow people to build sand castles in which to lock themselves away from the real world with their great ideas and spend too much resources on understanding that they won’t work. She offers to start any site with a simple stub, a one-button landing, and then, as the customer and his own staff grow, add more and more pages, products and services, interactive features and marketing chips. You will no longer need to sell an apartment to DIRECTLY make a cool website - make a simple page to earn yourself further budgets for the development of the entire business as a whole.
A million ways to kill your project
No matter how experienced each of us is, the unpredictable ways to destroy your project are always much more than you can foresee. From my own experience I will list only the most popular of them:
• Too much pride from the initial idea and unwillingness to change anything,
• Indifference and extreme lack of supervision of the entire development team
,
• Inattention to details, elevated to sacred status, • Lack of self-discipline for each final artist: waiting for a letter , order, kick to start thinking about the project,
• Belief that problems are solved by number (people, days, money), and not by skill,
• Lack of the slightest measurable system for evaluating the results,
• The “Let's make it and forget it soon” approach
• Misunderstanding of the factor that the main resource in any information system is people,
• Cruel punishment for any failures, instead of the reason to carefully analyze the wrong steps and become better,
• Creating all kinds of additional restrictions before building the system itself,
• Attempts to make a very general decision right away for all with an infinite scale for the growth of functions,
• Attempts to control and impose, rather than analyze and learn,
• And so on to infinity ...
At the end of my review, I’ll say right away that the author, like all of you, was not present at the live seminars of the authors of this technique, nor did he run around this technique for several years of practice in order to draw more sound conclusions. Moreover, I’m ready to admit that I may have misunderstood or misinterpreted some of the principles of this methodology - that’s 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 management method.
Below I will list the main Evo trailers 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 adjusted goals and objectives as a result of the first stage,
3. Leave
4. Recognition to yourself about the complete absence of extrasensory and astrological talent, and in this regard, once and for all eradicating the habit of making forecasts and requirements in a mentor tone,
5. Evolution implies the principle of open architecture - any section, block, paragraph, page should be able to fully use Board in 5-10 minutes without redrawing the entire platform,
6. You should not be afraid of changes. Change everything as often as you should,
7. The entire team of the Evo project should be entirely focused on the current round of evolution. No one should stand idle for a week, month, year, pending approval, confirmation, inclusion in the work. Succeeding or failing in the current step - only all together, without the most guilty and left aside with clean hands. No one will spend their energy in the subsequent stages, having joined the project halfway and not comprehending the whole history and principles of its growth from the very beginning.
8. The Evo Methodology is solid learning. There is no place for gurus, mentors, and “stars”,
9. Get rid of all the bad things as early as possible, do not expect a miracle,
10. Do not give up half a step from victory.