Few find a way out, some do not see it even if they find it, and many do not even look for it.
From Alice in Wonderland
The article raises the following questions.
- On the inconsistency of the components of the 'Scrum + Fixed Price' outsourcing formula.
- One possible error (root cause) preceding the wrong choice of the Scrum tool.
- About one situation where there really is a question of combining Scrum and Fixed Price, which requires deep analysis and trade-offs to resolve it.
The article touches upon a very controversial point that does not have an unambiguous point of view and is the subject of endless discussions. Therefore, while reading, please keep in mind that your opinion may not coincide with the one presented, but this does not mean at all that one of us is absolutely right as well as the fact that someone is absolutely wrong.
As mentioned in the article “How to start pseudo-Scrum in outsourcing” , in a large number of outsourcing projects, the teams of which combine (or perhaps wishful thinking) Scrum and Fixed Price, the project life cycle (LC) is not correctly identified. Those. a mistake was made in choosing between an iterative incremental or flexible life cycle. And, as a result, the wrong management tool was chosen - the Scrum framework. And already a consequence of this choice is the emergence of a number of problems, wrong conclusions about Agile, Scrum and attempts (from the word "torture"?) To combine these two mutually exclusive concepts.
Mutually exclusive ?!
Now I argue.
It is assumed that the reader is further familiar with the materials of the above article.
Scrum + Fixed Price – , ?
, , .When concluding a contract for the provision of outsourcing services, the client almost always insists on a Fixed Price (turnkey scheme). His wish is to fix the Product Scope (or the amount of work), see the budget, deadlines. He wants to see what he is "buying." Customers rarely agree to Time & Material.
“ ”
Thus, the key point: the need of the client is to be fixed in the contract, and the service provider is to fulfill the obligations under the contract and to ensure that the parameters will remain unchanged with a predictable error (due to some degree of uncertainty and risks at the stages of sales and contracting) after the start of development. The issue of reducing the degree of uncertainty and risks is the issue of the feasibility and quality of the Discovery (Pre-sale, diagnostics) phase in relation to the Product Scope.
It is quite obvious that if we fix something (we guarantee to the client under the contract), then we must plan and manage it in such a way as to ensure the fulfillment of our obligations. Those. manage the plan (or the fixed characteristics of the project triangle).
Fixed Price simply obliges us to prioritize plan management. Otherwise, why should we fix something, knowing in advance that it will change, and we do not really plan to manage it? To just sign a contract? A critical error in established sales processes: we fix it, knowing in advance that we will change, only in order to sign a contract!
Why are we going to change? Because Scrum is always about uncertainty and its result - change. This is about the priority of change management. And it is possible that they may appear after the first sprint. Why?
A digression about possible reasons for the change
What could be the reason for the change? For example, it may be in a poorly conducted Discovery (Pre-sale, diagnostics) phase in a situation where the Product Scope can be defined to some extent (for an example, see paragraph 3 of the Case Study in the article ), but for what for some reason this has not been done. In this case, this is a problem of phase and internal processes, and not the reason for choosing Scrum for a Fixed Price contract, a flexible life cycle instead of an iterative one in order to compensate for the mistake made.
Although, in fairness, I note that in sales (Pre-sale-activities of business analysts) in outsourcing (one of the most problematic phases from the point of view of the Product Scope!), Not everything is as simple as in a store when a finished product with specific properties is bought (functionality). And the Discovery phase is a difficult-to-sell activity of business analysts and teams. But minimizing uncertainty to one degree or another and assessing risks is one of the main tasks of a well-built sales process. As well as the formation of an understanding in the client about the necessity and importance of these activities (it can be very difficult!). But for this there are a sufficient number of techniques and tools. And it comes down to the issue of the quality of the services provided, and not the sale of a "pig in a poke".
Another reason may be the inability to determine the Product Scope & Vision at the current moment (for an example, see p. 2 from the Case Study in the article ). And this is indeed a very difficult and unfavorable situation for both parties, when a serious contradiction arises and the question of combining Scrum and Fixed Price in the provision of outsourcing services is raised. It requires careful analysis, additional actions to form a comprehensive understanding of the client (often technically and ideologically far from the realities of development processes) about possible difficulties and risks, and the search for compromise solutions.
So why is Scrum chosen? To manage changes that, for example, arise as a result of an incorrectly conducted Discovery (Pre-sale, diagnostics) phase or when the Product Scope cannot be determined at this phase? In the first case, in my opinion, this is wrong. In the second case, it is difficult to implement with Fixed Price.
The third possible option for choosing Scrum as an Agile tool, a flexible life cycle instead of an iterative incremental one in a situation where the Product Scope is worked out and fixed at the Discovery phase (Pre-sale, diagnostics), and in the contract - Fixed Price, is also not rational in my opinion: why choose a tool for managing change (out of focus is clearly a higher priority thing - a plan), when is their likelihood minimized?
Return to the main idea of the article.
But let's say Scrum is chosen. Again, Scrum is a change management tool, when the degree of uncertainty can be reduced only in the process and only when using appropriate approaches. And this decline is the result of this process.
But the Fixed Price contract gives priority to managing the plan!
Thus, the 'formula' 'Scrum + Fixed Price' is transformed into 'change management + plan management simultaneously'. The manager's task is to manage, to varying degrees, both the plan and the changes, but there can be only one priority: either the plan or the changes.
Either plan management or change management is a kind of axiom embedded in the foundations of management and business analysis. It is reflected in the basic (and not only) manuals for managers (PMBOK) and business analysts (BABOK). And the classification of life cycle (and their identification in relation to specific projects) relies on it: there are life cycle designed to manage the plan (for example, Waterfall, iterative incremental (IID)) and flexible, Agile for change management. The choice of the life cycle (and subsequently the tools) is based on what is given priority in management.
Flexible life cycle is a kind of iterative incremental life cycle for projects with certain dominant features / characteristics (a list of check questions is given in the above article), allowing you to identify it as a separate life cycle and "direct all efforts" to change management. These features may include: the impossibility of "here and now" to achieve a certain degree of certainty in the Product Scope (the most important thing!), The search for a business solution (or its quick delivery to the business to generate feedback) that will "shoot", the formation of a list of key functions product (Key Features), short iterations, variability, experiment, gradual build-up of functionality, retrospectives, improvement not only of the product, but also of processes in order to get the best product option. Is it possible in such conditions to obtain adequate estimates of the budget and terms?
The devil is in just one detail, or ... it's all about the Product Scope
Everything has its own morality, you just need to be able to find it!
From Alice in Wonderland
What can you say about certainty (the ability to establish it) in relation to Product Scope & Vision at the sales stage, the Discovery phase, at the start of the outsourcing project?
If the Product Scope cannot be defined, evaluated, fixed due to the reasons for the uniqueness of the product, the idea of a start-up, uncertainty regarding the effectiveness of the business decisions made (the need to find them) and the difficulty of determining the key functions of the product, the presence of hypotheses that require verification, etc. ... (see again point 2 of the Case Study here ), then, of course, the Scrum framework is the most suitable tool.
However, for outsourcing, this situation is significantly complicated by the client's desire to use the Fixed Price scheme when concluding a contract and appears in an unfavorable light for both parties. To some extent, with some assumptions, a compromise can be reached in contracting and managing such a project. It is important to form the correct understanding and correct expectations of the client (investor), assess the risks, consider, if possible, other schemes of financial interaction, and in the process of project implementation, constantly work with client loyalty, etc. I will not delve into the question, since it is beyond the scope of the article.
In outsourcing, most often the question primarily lies in the competent conduct of the Discovery (Pre-sale, diagnostics) phase in relation to the Product Scope and the choice of the right life cycle. And if Agile and Scrum are chosen in a situation where the Product Scope can be fixed (and even more so when this was not done for some reason on time, with the expectation / assumption of its development in the future), and at the same time in the contract - Fixed Price, in my opinion, a mistake is being made that casts doubt on the positive outcome of the project.
Thanks for your attention!