Scrum FP

Sprint

Sprints are used as in conventional SCRUM, but input for the Sprint is all Epic Sets that are meant for that particular Sprint. 

Specifics of SCRUM FP is that each Sprint has predefined scope that must be delivered. This predefined scope is one or several Epic Sets as defined in Project Plan.

Epic Set is a “piece of delivery” that is used to define initial project estimates for Fixed Price project delivery. This is a very rough scope project broken down into smaller units.

Epic Sets are something that can be estimated and delivered based on historic experience or market analogues or other methods. Think of Epic Set as a micro project within the whole project. If all Epic Sets will be delivered so will be the project. Good size of Epic Set should compare to the size of 1-2 sprints.

Note – Epic Sets will be refined later in the planning process.

Governing Body

People with delegated authority to make decisions about the project must be assigned to control the project as it will be essential to make decisions about project scope and schedule along all the period while the project will be going on (Governing Body – GB).

Setup Sprint

The first sprint of the Project is the Setup Sprint. It is as long as other sprints and the main objective of this activity is to set up the working environment. Everything that needs to be done before the development has to be done in this sprint (planning tasks, epics; making the Project Plan; getting hardware, licences, equipment; setting up pipelines, routines and many more). The Setup Sprint can be 2 sprints long, but not longer.

T/M vs F/P contracts

There are two main project contract types – time and material (TM) and fixed price (FP) contracts. The main difference between the two is that for FP contracts there is a set budget, and it is time boxed (there are time constraints). TM contracts, on the other hand, do not have a set budget (usually indicative) and they can have an end date, but they can be extended without changing the contract radically.

There are many more characteristics that can be derived from the main differences – for example, TM offers high flexibility and requirement changes, a fast start, dynamic decision-making (the client gives you direct instructions) and better client-side control over the project. Along with these characteristics, there is also less control over the budget, the client manages and is involved more with the project, as well as uncertainty about the finish.

On the other hand, FP projects have deadlines, set budgets and the supplier manages the project. They cannot be extended and are not as flexible or easily changed. This guarantees that the scope of the project does not increase indefinitely and will end, no matter the result. Usually, because of the management cost, these contracts are pricier and take longer time to prepare and plan.

The essential difference between the two contracts is – either you buy time (by choosing TM) or product (by choosing FP).

Before the start of the Delivery, GB is introduced with the Project Plan and how Project Plan will implement the whole planned project scope. GB accepts or rejects Project Plan or asks for more detailed explanations. After the Project Plan is fixed, scope of each Sprint is fixed as well.

Delivery control must be done at least at the end of each Sprint at  Sprint Review meetings.

If GB accepts that the Sprint target has been reached, deliveries are passed for Customer acceptance and testing, so the next Sprint is being planned as set in the Project Plan.

If GB rejects Sprint because of major flaws in scope or quality or target has not been reached, then a failed Sprint is repeated. Project Plan is rescheduled and all Epic Sets are pushed forward – the next upcoming Sprint consists of unfinished or failed tasks from the previous sprint, Reserve Sprints getting less by 1 sprint.

If more than one Sprint fails at GB level, the project must be considered a troubled project and its termination or reset must be considered as one of the necessary actions to match expectations.

Metaphor of franchise

SCRUM can be thought of as a franchise with a known name (brand), system of how to operate (rules, activities) and quality control (certification). The only difference is that there is no strict franchisor, which regulates how to use SCRUM and the activities in it. SCRUM is also a free franchise, and anybody can use it, although it might just be on paper. SCRUM is hard to use, and many companies struggle to implement it. It comes with a large knowledge base and there are many prerequisites to successfully apply SCRUM in your projects.

As a franchise, SCRUM is about the brand – it is stylish, innovative, modern and it is what everyone talks about. That is why many companies choose SCRUM and do their best to deliver projects with SCRUM. Because SCRUM lacks a strict franchisor, it’s standards do not get enforced and the company’s SCRUM might not be the factual (as written in scrum.org). Companies that experience successful projects using SCRUM, popularize the framework and make it admired by others. The ones that fail, on the other hand, do the opposite.

Using SCRUM as a franchise is a great opportunity. If you do your research and implement it correctly the productivity and success rate of your projects will increase. But if you get it wrong you will struggle, and the overall efficiency will decrease. Therefore, SCRUM Fixed Price can be used only if it is implemented correctly, as a franchise.

Complex adaptive systems

IT systems are complex adaptive systems. Any process that has countless steps and they can be different each time is complex. The problem with the waterfall method is that we do not know which workflow is going to be used. We can only imagine, speculate and invent. From the beginning, when we plan the system, we use an idea that is understandable for the product owner, systems analyst (or other competent person). This person describes the vision of the system and how he thinks it’s going to work. This is where an obstacle appears – when the system is being developed there are many decisions that have to be made and product owner or systems analyst cannot always assist developers, that is why developers make decisions themselves. What is going to happen when a user inputs something, what is going to happen if a user chooses something and many more. The decisions and processes multiply exponentially and programming cases multiply exponentially. That is why the most common scenario is developed. This increases the complexity, because each person can have a different understanding about the scenario – illogical paths do not get developed.

Adaptiveness increases when we see a part of the system that is developed. Either it is logical or illogical (according to the decision maker) and when it gets used a lot it can also become more logical or illogical. The system forms adaptively, in each step adding something logical. The developer only creates a small portion of everything – it can be useful or useless (if the decision maker expresses it that way). Developing systems using waterfall is risky, because the adaptability is lost. The one most common path is described as requirements for the system – the logic and adaptability come afterwards. Ths paradigm creates a conflict that has to be resolved.

Agile and SCRUM FP addresses the adaptiveness of systems. The complexity cannot be prevented, because the system is always changing. It is as it is, but the significance, control and patterns can change. And when they do, it has to be developed. The naive vision for the system while writing the requirements is always different from the developed system at the end. The complexity becomes larger during development and it has to be addressed. 

If we know things prematurely, we can save time developing things, only making what is necessary. From all of the system, we only pick the part that is needed the most and develop it. By using adaptiveness we reduce the risk of making things that are not needed. In reality, the workload can be a lot larger than the requirements suggest. This is why we have reserves and we plan as well as we can. The most important thing is to ignore the complexity and not develop branches (cases) that are not beneficial and will not be used in actual work. Usually the most common path covers 99% of the usages (if developed correctly), so it is critical to find it.

Sizing methods

In order to determine the size of a particular IT project some previous experience is essential. Usually the following methods are used:

• Order of Magnitude. When using it, you compare the functionality to be delivered to other known and completed or similar functionality. Expected workload of unknown functionality is compared to something that has been already delivered. New functionality is compared with some existing functionality in terms of size and complexity, so a multiplier has been found (new functionality is X time more/less than the one we know). This multiplier is used to multiply cost of known fun
•  e. Using this method, each epic is not measured based on a standard or universal reference, but comparing it to other epics that have been done or will be done in the project (which are estimated). For example, to size an epic that could be 4 points large, you should consider whether it is two times larger than an epic worth 2 points and two times smaller than an epic worth 8 points.

Secondly, expert judgement is the most accurate and only requires time for the expert. A chosen field expert is asked to measure the workload of each epic based on his previous experience and expertise. Most cases it takes less time, because the decisions are made unanimously. Usually, the expert will ask questions to clarify given information and for this the person with the most knowledge about the product should be involved. For this method to be used it is crucial to choose the right expert for the evaluation or else the estimates may be inaccurate.

Thirdly, disaggregation is used for clarification and, although it takes the most time, it also gives the biggest reward. The idea is based on splitting the epics (tasks) into smaller, more manageable parts (other epics). If all the epics have a workload of 1 – 8, it is very hard to estimate an epic that might be 20, 30 or more points. Also, it is hard to find other similar epics and compare them to it. So, we use disaggregation to divide the largest epics into parts that form logical epics and can be developed as separate parts.

Risks of Erosion of Value

SCRUM is built around individuals. So success of the framework is purely built by the success of the individual team member. So much of importance is to define what value means for a particular team. If a team’s dynamic changes from high-performance to least-energy consumed then value definition might shift from features to lack of stress or abundance of free time etc.

Sometimes it happens if the SCRUM master fails to define the direction, or fails to understand the core value concepts, or where high performance is not praised, instead lazy performance is very much accepted as long as it can be explained. So the velocity of the value creation gradually decreases.

With SCRUM FP such problems would be discovered more quickly than in traditional SCRUM or Kanban frameworks.

Documentation in SCRUM FP projects

Documentation is an important part in projects developed with SCRUM FP like in any other project. It is important to differentiate between documentation containing plans and vision or actual situation. In SCRUM FP we value technical documentation and content that focuses on factual information. Usually reserve sprints are used for creating documentation, because the development has been finished. The purpose of documentation is to ensure product’s sustainability and successful maintenance, not to manage development or control scope. The code is written first and then documented. This ensures that the documentation is more precise and takes less time to write. It is also beneficial to document only the part that is relevant (excluding sample information). For the process itself, the documentation is not mandatory, the product owner is responsible for the requirements. The base documents that should be written are – system installation, management and use of the system, as well as architecture. The client knows the most important features of the system and communicates it with the supplier.

Project flow TBD

It is convenient to look at the project as happening in the time.