FixPrice Agile or SCRUM via F… ira
There are many approaches to the management of IT projects and each of them finds its followers, is successfully used in some projects, fails miserably in others, admires a part of clients and causes resentment in another part. We discuss whether it is possible to mix approaches, methods and methodologies in order to achieve the goals set.
Important!
Scrum is, of course, good when there is a clear set of tasks for the sprint, the team spirit is endlessly raised, the client pays for the sprints, because he is already used to doing it, and the company receives income and believes that the project will never end.
')
The waterfall is also great, the client clearly knows that he’s going to fit into a certain budget, all the steps are painted in detail, but until the client wants to change something in the project or begins to understand that the project is not going where we would like .
In conditions when the client wants to clearly know their costs, the team wants to drive and be able to influence the course of the project, and the company wants to consistently receive their income, the manager has to maneuver between all these requirements and choose the appropriate methodology, method, principles, rules.
That is why it is possible to trace the tendency to the mixing of methodologies, rules and principles.
As a rule, they want to fit into the original planned budget, have the opportunity to regularly see the results of the project, influence the course of the project, make changes to the product.
The fixed budget of the entire project, we assume, as an example, a waterfall model, the ability to influence the product and make changes are widely represented in flexible methodologies, iterations and regular demonstrations are also characteristic of flexible methodologies, the documentation covering all stages of the project is brightly presented in PMI.
It turns out such a very dear to customers Frankenstein methodologies and approaches to management.
Of greatest interest are projects where you can make suggestions for improvement, i.e. participate in product development. So, in the process of brainstorming, you can come up with a new useful option or use an interesting technology / programming language. In such work, both creativity and high risks are intertwined, so a fixed budget is not suitable here, it will only be a heavy burden to hang and limit the scope for imagination. Teams like to work on the basis of time and material, choose priorities of tasks in the order in which it will be more convenient to develop. With such a flexible approach, new wishes of customers are very easily accepted and priorities of tasks change.
In my opinion, the waterfall model is interesting. With this approach, at the start of the project, all requirements are specified and documented, a framework is set, the goal of the project is clearly visible, it is easy to compare the requirements with the acts of acceptance. We get a minimum of surprises, a minimum of risks, and at the same time, clearly defined dates and budgets. When using this model of more order, the company is more confident in predicting the receipt of the next tranche.
From the point of view of project work, the ideal model is a waterfall model. Here at the start, you need to try to document the product, provide for all the risks, and then control that everything goes according to plan. But from the point of view of teamwork, I want to be creative, I want to prompt, share experiences, change the course. Team discussions, brainstorm, daily meetings, a changing product - this all allows you to make an agile philosophy.
What to do in a situation when:
- there is no time for deep analytics at the beginning of the project, or no funds are allocated,
- there is a rigidly fixed budget and the stages of delivery specified in the contract,
- during the project, there are new wishes that can in no way be transferred to the second version of the product and other unplanned tasks appear?
You can work on the waterfall , but leave the budget for maneuvers. In this model, the contract will be designed for the main functionality of the product, and additional agreements can change the scope of the project. This will solve the problem of a fixed budget and adding innovations to the product during the development process.
You can work on SCRUM , but with a fixed set of sprints. Such a model is more suitable for startups when you want to see the development of a product, change it, and at the same time stay within budget. Before the start of the sprint, the tasks are selected, evaluated, the client is provided with an estimate. This estimate is approved and goes to work, any changes are transferred to the next sprint, and if the change was for 8 hours, then any other task for the same number of hours is removed from the project. Here, both the team can effectively work on the tasks set, and the client influences the process by putting together tasks in the sprint, and the client controls his budget. In this case, the product is published, even with reduced functionality.
There is an approach in which the client pays a fixed amount every month, while the team processes a different number of tasks from month to month. In other words, the client takes the team for rent . He can fill them with tasks for the whole week, or he may not prepare at all tasks, and the team will receive a monthly agreed amount.
This approach does not necessarily apply to technical support projects, it is also appropriate for product development.
For the client, this approach implies fixed costs and high interest in loading the team. For a company that provides such a service, employment of employees and stable budget replenishment are guaranteed.
In conclusion, I want to say that every company, client, project is unique . Any of the existing approaches may be appropriate for your project, and if not - think up your own approach, and find the partner with whom you can implement it.
I really want to hear your experience, do you manage to work only in the framework of one methodology / methodology?
If you worked according to the classic cascade model , wrote the concept / TK / Working draft / Specifications / other, built Gantt diagrams, painted waterfall schemes, provided for a register of risks, kept the so-called “out of scope” and only after the end of the planned work did they return to your client was delighted with the project, YOU are cool and kowtow to you! You are a scrupulous manager, with sensitive parts of the body on the one hand and iron parts on the other hand, which helped you to see the progress of the project and to defend the concluded agreements, both with the team and with the client. Write in the comments “WATERFALL!”, The country should know the characters in person.
If you have chosen a flexible development model based on Agile principles for your projects, you know Agile Manifesto better than your email password, your teams are highly organized, your Clients are happy from the results they get from iteration to iteration, you feel like a fish in the water, my course direction, YOU ARE YOUNG! You have a flexible mind, lightning reaction, low inertness and high volubility. You are very, very much communicating. Write in the comments “Agile” (let everyone know, you can work flexibly and you do it successfully!).
If you are able to combine methodologies with methodologies, principles with rules and you succeed , tell everyone how you do it?
What does not allow you to work in a strictly one method / approach / methodology? Are the customers so different? Circumstances? Managers? Design solutions? How do companies work? Disadvantages and limitations?
Important!
- The article contains a certain amount of irony.
- The article in no way infringes anyone's interests.
- The article does not oppose the SCRUM waterfall and does not mix “soft with warm”.
- Everyone has their own opinion on the project development process, their experience or lack of it, their happy client or their failed project, carried out according to the methodology, using design techniques, guided by principles or intuition.
- Be kinder!
Scrum is, of course, good when there is a clear set of tasks for the sprint, the team spirit is endlessly raised, the client pays for the sprints, because he is already used to doing it, and the company receives income and believes that the project will never end.
')
The waterfall is also great, the client clearly knows that he’s going to fit into a certain budget, all the steps are painted in detail, but until the client wants to change something in the project or begins to understand that the project is not going where we would like .
In conditions when the client wants to clearly know their costs, the team wants to drive and be able to influence the course of the project, and the company wants to consistently receive their income, the manager has to maneuver between all these requirements and choose the appropriate methodology, method, principles, rules.
That is why it is possible to trace the tendency to the mixing of methodologies, rules and principles.
Let's talk about customers
As a rule, they want to fit into the original planned budget, have the opportunity to regularly see the results of the project, influence the course of the project, make changes to the product.
The fixed budget of the entire project, we assume, as an example, a waterfall model, the ability to influence the product and make changes are widely represented in flexible methodologies, iterations and regular demonstrations are also characteristic of flexible methodologies, the documentation covering all stages of the project is brightly presented in PMI.
It turns out such a very dear to customers Frankenstein methodologies and approaches to management.
For the project team
Of greatest interest are projects where you can make suggestions for improvement, i.e. participate in product development. So, in the process of brainstorming, you can come up with a new useful option or use an interesting technology / programming language. In such work, both creativity and high risks are intertwined, so a fixed budget is not suitable here, it will only be a heavy burden to hang and limit the scope for imagination. Teams like to work on the basis of time and material, choose priorities of tasks in the order in which it will be more convenient to develop. With such a flexible approach, new wishes of customers are very easily accepted and priorities of tasks change.
For the company
In my opinion, the waterfall model is interesting. With this approach, at the start of the project, all requirements are specified and documented, a framework is set, the goal of the project is clearly visible, it is easy to compare the requirements with the acts of acceptance. We get a minimum of surprises, a minimum of risks, and at the same time, clearly defined dates and budgets. When using this model of more order, the company is more confident in predicting the receipt of the next tranche.
For manager
From the point of view of project work, the ideal model is a waterfall model. Here at the start, you need to try to document the product, provide for all the risks, and then control that everything goes according to plan. But from the point of view of teamwork, I want to be creative, I want to prompt, share experiences, change the course. Team discussions, brainstorm, daily meetings, a changing product - this all allows you to make an agile philosophy.
What to do in a situation when:
- there is no time for deep analytics at the beginning of the project, or no funds are allocated,
- there is a rigidly fixed budget and the stages of delivery specified in the contract,
- during the project, there are new wishes that can in no way be transferred to the second version of the product and other unplanned tasks appear?
To mix!
You can work on the waterfall , but leave the budget for maneuvers. In this model, the contract will be designed for the main functionality of the product, and additional agreements can change the scope of the project. This will solve the problem of a fixed budget and adding innovations to the product during the development process.
You can work on SCRUM , but with a fixed set of sprints. Such a model is more suitable for startups when you want to see the development of a product, change it, and at the same time stay within budget. Before the start of the sprint, the tasks are selected, evaluated, the client is provided with an estimate. This estimate is approved and goes to work, any changes are transferred to the next sprint, and if the change was for 8 hours, then any other task for the same number of hours is removed from the project. Here, both the team can effectively work on the tasks set, and the client influences the process by putting together tasks in the sprint, and the client controls his budget. In this case, the product is published, even with reduced functionality.
There is an approach in which the client pays a fixed amount every month, while the team processes a different number of tasks from month to month. In other words, the client takes the team for rent . He can fill them with tasks for the whole week, or he may not prepare at all tasks, and the team will receive a monthly agreed amount.
This approach does not necessarily apply to technical support projects, it is also appropriate for product development.
For the client, this approach implies fixed costs and high interest in loading the team. For a company that provides such a service, employment of employees and stable budget replenishment are guaranteed.
In conclusion, I want to say that every company, client, project is unique . Any of the existing approaches may be appropriate for your project, and if not - think up your own approach, and find the partner with whom you can implement it.
I really want to hear your experience, do you manage to work only in the framework of one methodology / methodology?
If you worked according to the classic cascade model , wrote the concept / TK / Working draft / Specifications / other, built Gantt diagrams, painted waterfall schemes, provided for a register of risks, kept the so-called “out of scope” and only after the end of the planned work did they return to your client was delighted with the project, YOU are cool and kowtow to you! You are a scrupulous manager, with sensitive parts of the body on the one hand and iron parts on the other hand, which helped you to see the progress of the project and to defend the concluded agreements, both with the team and with the client. Write in the comments “WATERFALL!”, The country should know the characters in person.
If you have chosen a flexible development model based on Agile principles for your projects, you know Agile Manifesto better than your email password, your teams are highly organized, your Clients are happy from the results they get from iteration to iteration, you feel like a fish in the water, my course direction, YOU ARE YOUNG! You have a flexible mind, lightning reaction, low inertness and high volubility. You are very, very much communicating. Write in the comments “Agile” (let everyone know, you can work flexibly and you do it successfully!).
If you are able to combine methodologies with methodologies, principles with rules and you succeed , tell everyone how you do it?
What does not allow you to work in a strictly one method / approach / methodology? Are the customers so different? Circumstances? Managers? Design solutions? How do companies work? Disadvantages and limitations?
Source: https://habr.com/ru/post/323178/
All Articles