Two project management protocols
Good day.
I came to project management from programming. That is, no so long ago, I still wrote the code and I really liked it. I was little worried about the unrest occurring somewhere on the top - "managers". Everything changed in 2004, when I was appointed team leader.
It was a large and complex project. We worked as a remote offshore group in a constant atmosphere of pressure from management. Evaluation of tasks descended from above, and in order to somehow cope with the tasks, I had to work until late in the 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, impressed by revolutionary architectural solutions - such as MVC and Fowler patterns, I thought that there was a * technical * solution to our management problems - you just need to find and apply it.
Over the next few years, I was looking for a * super framework * for project management. But only recently I realized that it is not and cannot be. The problem is that in the software development 2 conflicting communication protocols between the process participants are simultaneously used.
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
Today, in IT projects, there is a war between two ideologies of project management - determinant and empirical. Determinant processes are suitable for well-predicted areas - such as construction, railways, factory conveyors ... Determinant processes can and should be planned. Methods and tools for such processes developed together 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 - scientific research, space programs and, finally, the movement of a taxi car. The process that describes such areas can be called empirical. Of course, software development also refers to empirical processes.
What is the difference between these two ideologies? The determinant process is based on a complete understanding of the underlying processes and on the ability to calculate and plan them. People - participants in the process - are considered as cogs working according to a certain program and rules. In the empirical process, we master the problem blindly - today we get feedback from the system we are building, and we 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 toolkit of such a process is designed to optimize the individual and team performance of participants.
If the task of the determinant process is to support the implementation of the Big Plan, then the empirical task is to organize the most effective interaction between people. In the determinant process, there is pressure on the task executor to keep it within the planned duration, in the empirical one there are no such restrictions. The only thing that is required of the performer in the empirical process is frequent periodic estimates of the remaining time required to complete the task.
Which approach is better?
At this stage, let's make a binding to the specifics of project management. We will consider pure WaterFall as an example of a determinant process , and Scrum as an empirical example .
In fact, the answer to the question posed “which approach is better?” Will sound somewhat unexpected. These approaches cannot be compared because they are responsible for the various 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 tools created for a specific job. If we introduce determinant and empirical approaches in the form of a language or communication protocol, we will see that both languages are necessary for a successful IT project. We just need to learn how to not mix these protocols together and use them in the right context.
In the Falls language, an initial discussion of the project is taking place 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 found projects with a "rubber" budget. In my practice, for example, the first movements in a project occur according to the traditional determinant scenario. There is a quick, preliminary collection of requirements, risk factors are added, and we go to a virtual-global plan for the project, go to the magic numbers of X money and Y days. Thus, we go through the 2 phases of the Waterfall - requirements collection and analysis, architectural design and planning.
In the next step, we switch to the Scrum language. During the launch of the project, a financial limit was set - and now, during development, the involved parties (the customer and programmers) are trying to do the most useful work for this money. At the same time, every 2-3 weeks (duration of the iteration) the composition of features (pieces of functional) can radically change, and the original Big Plan is generally ignored.
Scrum is worried about how to solve complex problems most effectively with the great 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 are also more beneficial to the customer. To get functionality that is carefully tailored to the business and is able to immediately bring money is much more important than a 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 streamline everything said ...
So, the project is divided into 3 stages:
- Mini-Waterfall to assess the financial limit.
- Scrum for development
- Coordinating last iteration.
At the first stage, we create a plate with a list of user stories and evaluate it in the context of the architecture in which we will implement the System. Next, we draw a Gantt and simulate the execution of the project in time with a specific configuration of the team. So we reach the financial limit.
At the second stage, we create a product backlog and prioritize user stories in accordance with customer preferences. Moreover, he (the customer) is free to change the set of these stories as he pleases. We break this backlog on iteration and execute them. So we are moving up to the stop-signal. Stop-wave is an event that marks the end of Scrum communication and a return to the Waterfall. Such factors as reaching a financial limit or a client’s decision (for example, if he is quite satisfied with the achieved results and he just wants to stop) can determine the “stop-go-ahead”.
The third stage is, in fact, a special iteration, where we coordinate a set of pieces of functionality at the same time with the customer and with the Big Plan. Here we again switch to the language of the Waterfall in order to deliver the project in the formal framework of the very first assessment - that is, at the level of top management and finance. Let me give you an example ... Suppose we made commitments in the Big Plan to implement features A, B and C. During development, the client threw out feature C and introduced new features - D and E. Next, let feature A be handed over to us at the previous iterations, and we did not use feature B managed to finish (she had a low priority). Then, during the negotiating iteration, we must finish B, and also, if C is less than the sum of D and E, then the customer must pay the difference to our company.
It can be formulated so that at the first stage we estimate the costs of an unpredictable expedition. At the second stage - we travel. On the third - we summarize the expedition and streamline bookkeeping according to its results.
I have adopted this approach recently. At the moment, I managed to check it on only one project. The result was positive. I am very interested to hear your opinion, 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, no so long ago, I still wrote the code and I really liked it. I was little worried about the unrest occurring somewhere on the top - "managers". Everything changed in 2004, when I was appointed team leader.
It was a large and complex project. We worked as a remote offshore group in a constant atmosphere of pressure from management. Evaluation of tasks descended from above, and in order to somehow cope with the tasks, I had to work until late in the 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, impressed by revolutionary architectural solutions - such as MVC and Fowler patterns, I thought that there was a * technical * solution to our management problems - you just need to find and apply it.
Over the next few years, I was looking for a * super framework * for project management. But only recently I realized that it is not and cannot be. The problem is that in the software development 2 conflicting communication protocols between the process participants are simultaneously used.
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
Today, in IT projects, there is a war between two ideologies of project management - determinant and empirical. Determinant processes are suitable for well-predicted areas - such as construction, railways, factory conveyors ... Determinant processes can and should be planned. Methods and tools for such processes developed together 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 - scientific research, space programs and, finally, the movement of a taxi car. The process that describes such areas can be called empirical. Of course, software development also refers to empirical processes.
What is the difference between these two ideologies? The determinant process is based on a complete understanding of the underlying processes and on the ability to calculate and plan them. People - participants in the process - are considered as cogs working according to a certain program and rules. In the empirical process, we master the problem blindly - today we get feedback from the system we are building, and we 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 toolkit of such a process is designed to optimize the individual and team performance of participants.
If the task of the determinant process is to support the implementation of the Big Plan, then the empirical task is to organize the most effective interaction between people. In the determinant process, there is pressure on the task executor to keep it within the planned duration, in the empirical one there are no such restrictions. The only thing that is required of the performer in the empirical process is frequent periodic estimates of the remaining time required to complete the task.
Which approach is better?
At this stage, let's make a binding to the specifics of project management. We will consider pure WaterFall as an example of a determinant process , and Scrum as an empirical example .
In fact, the answer to the question posed “which approach is better?” Will sound somewhat unexpected. These approaches cannot be compared because they are responsible for the various 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 tools created for a specific job. If we introduce determinant and empirical approaches in the form of a language or communication protocol, we will see that both languages are necessary for a successful IT project. We just need to learn how to not mix these protocols together and use them in the right context.
In the Falls language, an initial discussion of the project is taking place 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 found projects with a "rubber" budget. In my practice, for example, the first movements in a project occur according to the traditional determinant scenario. There is a quick, preliminary collection of requirements, risk factors are added, and we go to a virtual-global plan for the project, go to the magic numbers of X money and Y days. Thus, we go through the 2 phases of the Waterfall - requirements collection and analysis, architectural design and planning.
In the next step, we switch to the Scrum language. During the launch of the project, a financial limit was set - and now, during development, the involved parties (the customer and programmers) are trying to do the most useful work for this money. At the same time, every 2-3 weeks (duration of the iteration) the composition of features (pieces of functional) can radically change, and the original Big Plan is generally ignored.
Scrum is worried about how to solve complex problems most effectively with the great 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 are also more beneficial to the customer. To get functionality that is carefully tailored to the business and is able to immediately bring money is much more important than a 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 streamline everything said ...
So, the project is divided into 3 stages:
- Mini-Waterfall to assess the financial limit.
- Scrum for development
- Coordinating last iteration.
At the first stage, we create a plate with a list of user stories and evaluate it in the context of the architecture in which we will implement the System. Next, we draw a Gantt and simulate the execution of the project in time with a specific configuration of the team. So we reach the financial limit.
At the second stage, we create a product backlog and prioritize user stories in accordance with customer preferences. Moreover, he (the customer) is free to change the set of these stories as he pleases. We break this backlog on iteration and execute them. So we are moving up to the stop-signal. Stop-wave is an event that marks the end of Scrum communication and a return to the Waterfall. Such factors as reaching a financial limit or a client’s decision (for example, if he is quite satisfied with the achieved results and he just wants to stop) can determine the “stop-go-ahead”.
The third stage is, in fact, a special iteration, where we coordinate a set of pieces of functionality at the same time with the customer and with the Big Plan. Here we again switch to the language of the Waterfall in order to deliver the project in the formal framework of the very first assessment - that is, at the level of top management and finance. Let me give you an example ... Suppose we made commitments in the Big Plan to implement features A, B and C. During development, the client threw out feature C and introduced new features - D and E. Next, let feature A be handed over to us at the previous iterations, and we did not use feature B managed to finish (she had a low priority). Then, during the negotiating iteration, we must finish B, and also, if C is less than the sum of D and E, then the customer must pay the difference to our company.
It can be formulated so that at the first stage we estimate the costs of an unpredictable expedition. At the second stage - we travel. On the third - we summarize the expedition and streamline bookkeeping according to its results.
I have adopted this approach recently. At the moment, I managed to check it on only one project. The result was positive. I am very interested to hear your opinion, thoughts and ideas on the topic of the post.
Thank you for your attention and good luck!