Two project management protocols
Good day.
I came to project management from programming. That is, not so long ago, I also wrote the code and I really liked it. I was not bothered much by the excitement happening somewhere on the top - "at the managers." Everything changed in 2004, when I was appointed team leader.
It was a big and complex project. We worked as a remote offshore group in a constant atmosphere of pressure from the management. Evaluation of tasks went down from above, and in order to somehow cope with the tasks, I had to work until late evening and on weekends.
')
Then I began to think about the reasons for this situation, I began to read posts and books on management. As a programmer who is under the impression of revolutionary architectural solutions - such as MVC and Fowler patterns, I thought that there is a * technical * solution to our management problems - we just need to find and apply it.
For the next few years I was looking for a * super framework for project management. But only recently I realized that it is not and can not be. The problem is that in software development, two conflicting communication protocols between the Process participants are used simultaneously.
Now I will talk about my current vision of the problem, and also describe one of the possible strategies for sharing these two protocols.
People vs Cogs
Nowadays in IT projects there is a war between two ideologies of project management - determinant and empirical. Determinant processes are suitable for well predictable areas such as construction, railway, factory conveyor ... Determinant processes can and should be planned. Techniques and tools for such processes developed along with industrial capitalism and brought the world Gantt, PERT, Critical Path, WaterFall, CMMI certification, several dozen types of applied management.
But there is another class of processes. These are processes that are very difficult to predict and plan - research, space programs and, finally, the movement of a taxi car. The process that describes such areas can be called empirical. Software development is undoubtedly an empirical process.
What is the difference between these two ideologies? The determinant process is based on a full understanding of the underlying processes and the ability to calculate and plan them. People - participants in the process - are treated as cogs working according to a specific program and rules. In the empirical process, we master the problem blindly - today we receive feedback from the system we are building, and use this data to plan our tomorrow's step. There is no general plan. We are going as fast as it turns out and do not know where we will be in the long run. People in the empirical process are the main driving force and the tools of such a process are designed to optimize the individual and team performance of the participants.
If the task of the determinant process is to support the implementation of the Great Plan, then the empirical task is to organize the most effective interaction between people. In the determinant process there is pressure on the contractor to keep it within the planned duration, in the empirical - there are no such limitations. The only thing that is required of the performer in the empirical process is frequent periodic evaluations of the remaining time needed to complete the task.
Which approach is better?
At this stage, let's bind to the specifics of project management. We will consider pure WaterFall (Waterfall) as an example of the determinant process, and Scrum (Scrum) as an example of an empirical process.
In fact, the answer to the question posed - “which approach is better?” Will sound somewhat unexpectedly. These approaches cannot be compared because they are responsible for the different contexts of the development process. It makes no sense to find out which is better - a screwdriver or a hammer, a foot or a hand - these are the tools created for a particular job. If we present the determinant and empirical approaches in the form of a language or communication protocol, then we will see that both languages ​​are necessary for a successful IT project. We just need to learn how to not mix up these protocols and use them in the right context.
In the language of the Waterfall, there is an initial discussion of the project at the level of the customer, analyst, CEO, financial manager. They need to understand how much money and time they need to spend on the project. Very rarely there are projects with a "rubber" budget. In my practice, for example, the first movements in a project occur according to the traditional determinantal scenario. There is a quick preliminary collection of requirements, risk factors are added, and we are entering a kind of virtual-global project implementation plan, entering the magic numbers X money and Y days. Thus, we go through 2 phases of the Waterfall - requirements gathering and analysis, architectural design and planning.
In the next step, we switch to the Scrum language. During the project launch, the financial limit was set - and now, during development, the parties involved (the customer and programmers) are trying to do the most useful work for this money. At the same time, every 2-3 weeks (the duration of the iteration) the composition of the features (pieces of functionality) can change drastically, and the original Big Plan is generally ignored.
Scram is worried about how to most effectively solve complex problems with a large contribution of the human factor and he does not care about the Big Plan. Interestingly, Scrum with its dynamic backlog (dynamic list of pieces of functionality) and the 20/80 rule is also more beneficial to the customer. Get the functionality, carefully tailored to the business and able to immediately bring money - much more important than the formal checklist for last year's Big Plan.
We integrate Waterfall and Scrum.
At the beginning of the article, I promised a recipe for sharing these two protocols. Let's try to sort everything out ...
So, the project is divided into 3 stages:
- Mini-Waterfall to assess the financial limit.
- Scrum for development
- Matching last iteration.
At the first stage, we create a tablet with a list of user histories and evaluate it in the context of the architecture in which we will implement the System. Next, we draw a Gantt and model the project in time with a specific team configuration. So we enter the financial limit.
At the second stage, we create product backlogs and prioritize user histories according to customer preferences. Moreover, he (the customer) is free to change the set of these stories as he pleases. We break this backlog into iterations and execute them. So we move up to the "stop-go". Stop-go-ahead is an event that marks the end of Scrum communication and a return to the Falls. Such factors as the achievement of a financial limit or the decision of a client (for example, if the results achieved are satisfactory and he just wants to stop) can determine the “stop beating”.
The third stage is, in fact, a special iteration, where we coordinate a set of pieces of functionality simultaneously with the customer and with the Big Plan. Here we again switch to the Waterfall language in order to pass the project in the formal framework of the very first assessment — that is, at the level of top management and finance. Let me give an example ... Suppose that in the Big Plan we took obligations to implement features A, B and C. During the development, the client threw out feature C and introduced new features D and E. Next, let feature A we passed on previous iterations, and feature B we did not managed to finish (she had a low priority). Then, during the matching iteration, we must complete B, and also, if grade C is less than the sum of marks D and E, then the customer must pay the difference to our company.
It can be stated that at the first stage we estimate the costs of an unpredictable expedition. At the second stage - we travel. On the third - we sum up the results of the expedition and organize the accounting department according to its results.
I have adopted this approach quite recently. At the moment I was able to check it only on one project. The result was positive. I am very interested to hear your opinions, thoughts and ideas on the topic of the post.
Thank you for your attention and good luck!
I came to project management from programming. That is, not so long ago, I also wrote the code and I really liked it. I was not bothered much by the excitement happening somewhere on the top - "at the managers." Everything changed in 2004, when I was appointed team leader.
It was a big and complex project. We worked as a remote offshore group in a constant atmosphere of pressure from the management. Evaluation of tasks went down from above, and in order to somehow cope with the tasks, I had to work until late evening and on weekends.
')
Then I began to think about the reasons for this situation, I began to read posts and books on management. As a programmer who is under the impression of revolutionary architectural solutions - such as MVC and Fowler patterns, I thought that there is a * technical * solution to our management problems - we just need to find and apply it.
For the next few years I was looking for a * super framework for project management. But only recently I realized that it is not and can not be. The problem is that in software development, two conflicting communication protocols between the Process participants are used simultaneously.
Now I will talk about my current vision of the problem, and also describe one of the possible strategies for sharing these two protocols.
People vs Cogs
Nowadays in IT projects there is a war between two ideologies of project management - determinant and empirical. Determinant processes are suitable for well predictable areas such as construction, railway, factory conveyor ... Determinant processes can and should be planned. Techniques and tools for such processes developed along with industrial capitalism and brought the world Gantt, PERT, Critical Path, WaterFall, CMMI certification, several dozen types of applied management.
But there is another class of processes. These are processes that are very difficult to predict and plan - research, space programs and, finally, the movement of a taxi car. The process that describes such areas can be called empirical. Software development is undoubtedly an empirical process.
What is the difference between these two ideologies? The determinant process is based on a full understanding of the underlying processes and the ability to calculate and plan them. People - participants in the process - are treated as cogs working according to a specific program and rules. In the empirical process, we master the problem blindly - today we receive feedback from the system we are building, and use this data to plan our tomorrow's step. There is no general plan. We are going as fast as it turns out and do not know where we will be in the long run. People in the empirical process are the main driving force and the tools of such a process are designed to optimize the individual and team performance of the participants.
If the task of the determinant process is to support the implementation of the Great Plan, then the empirical task is to organize the most effective interaction between people. In the determinant process there is pressure on the contractor to keep it within the planned duration, in the empirical - there are no such limitations. The only thing that is required of the performer in the empirical process is frequent periodic evaluations of the remaining time needed to complete the task.
Which approach is better?
At this stage, let's bind to the specifics of project management. We will consider pure WaterFall (Waterfall) as an example of the determinant process, and Scrum (Scrum) as an example of an empirical process.
In fact, the answer to the question posed - “which approach is better?” Will sound somewhat unexpectedly. These approaches cannot be compared because they are responsible for the different contexts of the development process. It makes no sense to find out which is better - a screwdriver or a hammer, a foot or a hand - these are the tools created for a particular job. If we present the determinant and empirical approaches in the form of a language or communication protocol, then we will see that both languages ​​are necessary for a successful IT project. We just need to learn how to not mix up these protocols and use them in the right context.
In the language of the Waterfall, there is an initial discussion of the project at the level of the customer, analyst, CEO, financial manager. They need to understand how much money and time they need to spend on the project. Very rarely there are projects with a "rubber" budget. In my practice, for example, the first movements in a project occur according to the traditional determinantal scenario. There is a quick preliminary collection of requirements, risk factors are added, and we are entering a kind of virtual-global project implementation plan, entering the magic numbers X money and Y days. Thus, we go through 2 phases of the Waterfall - requirements gathering and analysis, architectural design and planning.
In the next step, we switch to the Scrum language. During the project launch, the financial limit was set - and now, during development, the parties involved (the customer and programmers) are trying to do the most useful work for this money. At the same time, every 2-3 weeks (the duration of the iteration) the composition of the features (pieces of functionality) can change drastically, and the original Big Plan is generally ignored.
Scram is worried about how to most effectively solve complex problems with a large contribution of the human factor and he does not care about the Big Plan. Interestingly, Scrum with its dynamic backlog (dynamic list of pieces of functionality) and the 20/80 rule is also more beneficial to the customer. Get the functionality, carefully tailored to the business and able to immediately bring money - much more important than the formal checklist for last year's Big Plan.
We integrate Waterfall and Scrum.
At the beginning of the article, I promised a recipe for sharing these two protocols. Let's try to sort everything out ...
So, the project is divided into 3 stages:
- Mini-Waterfall to assess the financial limit.
- Scrum for development
- Matching last iteration.
At the first stage, we create a tablet with a list of user histories and evaluate it in the context of the architecture in which we will implement the System. Next, we draw a Gantt and model the project in time with a specific team configuration. So we enter the financial limit.
At the second stage, we create product backlogs and prioritize user histories according to customer preferences. Moreover, he (the customer) is free to change the set of these stories as he pleases. We break this backlog into iterations and execute them. So we move up to the "stop-go". Stop-go-ahead is an event that marks the end of Scrum communication and a return to the Falls. Such factors as the achievement of a financial limit or the decision of a client (for example, if the results achieved are satisfactory and he just wants to stop) can determine the “stop beating”.
The third stage is, in fact, a special iteration, where we coordinate a set of pieces of functionality simultaneously with the customer and with the Big Plan. Here we again switch to the Waterfall language in order to pass the project in the formal framework of the very first assessment — that is, at the level of top management and finance. Let me give an example ... Suppose that in the Big Plan we took obligations to implement features A, B and C. During the development, the client threw out feature C and introduced new features D and E. Next, let feature A we passed on previous iterations, and feature B we did not managed to finish (she had a low priority). Then, during the matching iteration, we must complete B, and also, if grade C is less than the sum of marks D and E, then the customer must pay the difference to our company.
It can be stated that at the first stage we estimate the costs of an unpredictable expedition. At the second stage - we travel. On the third - we sum up the results of the expedition and organize the accounting department according to its results.
I have adopted this approach quite recently. At the moment I was able to check it only on one project. The result was positive. I am very interested to hear your opinions, thoughts and ideas on the topic of the post.
Thank you for your attention and good luck!
Source: https://habr.com/ru/post/86791/
All Articles