Agile Based Contract Rules Objectives

2.1.

Generally, the innovative projects are aimed at improving the selected key performance indicators (KPI) as a result of process control or business automation using novel architecture, algorithms, business process patterns, software, hardware, etc. It requires providing a variety of:

 out of the box products,

 custom services including designing specifications, developing, integrating, testing, training, commissioning and supporting.

Usually the appropriate selection of products is an outcome of services and depends on their quality and performance (the purchase procedure is beyond the scope of this paper).

One of prerequisites for the achievement of the goal, i.e. real improvement in the selected KPI, is the use of such solutions and implementation of such target solution functionalities that the expectations of the parties concerned are met to the greatest possible extent within the agreed time frame and cost limits.

Here the optimization of:

 the scope of work that will enable the customer to achieve the business goal, and

 the implementation team's efforts to maintain maximum work efficiency and quality of the provided deliverables, which, consequently, significantly reduces costs

is of crucial importance.

It is, therefore, proposed that well-proven practices derived from Scrum [6] [7] [8]

[9] [10] methodology related to management of development and implementation work within the project should be used. Scrum is proposed because it concentrates on the management aspects, which makes the adoption process straightforward. The Product Owner role defined by the Scrum methodology is also the best candidate to be tasked with representation of the business objectives on the continuous basis during the whole project lifecycle. A well-defined roles set proposed by Scrum could be also expanded non-invasively by adding roles in charge of taking care about the formal and legal course of the agreement and controlling of the work environment.

On the basis of agile philosophy it is assumed that optimization can be achieved if cooperation is based on the following assumptions:

 Cyclical nature - work is carried out in pre-scheduled time cycles (milestones), which allows the customer to control the scope and progress of work and value for money.

 Mutual trust – the application of methods and tools to ensure great transparency in the process of developing and implementing new findings and deliverables, which allows the customer to fully monitor work.

50 From Requirements to Software: Research and Practice

Methodology Rules 2.2.

It is proposed that the following business model should be used to carry out tasks in the area of cooperation:

 Under an agreement of business cooperation (framework contract) concluded for an indefinite or long period of time, the solution provider will implement and maintain solutions in the area of collaboration stipulated in the agreement.

 Further development of the implemented solutions will be effected as an extension to the basic scope of the agreement.

 To ensure appropriate competitiveness conditions, the rules of Scrum project management will be implemented.

The contract as a formal set of statements provides business environment for any activities related to the development and deployment of project deliverables. The cooperation agreement will define the organizational framework and basic accounting principles of the further work.

In all projects referenced in Section 1 as the experience source the target was reached as a series of contracts. For the innovative research projects it is a typical behavioral pattern as exploration into not well-known areas usually yields discovery of new ones also worth exploring next time. To limit this naturally infinite process there must be defined performance key indicators to assess quantitative and qualitative objectives before making decision in this respect.

It is, therefore, proposed to define the contract as a foundation for carrying out a series of loosely coupled projects, instead of a series of contracts. The main aim of the contract is to define basic rules related to new project scoping, budgeting, scheduling and progress controlling.

The proposed approach is mutually beneficial. One of the benefits for the customer is an obligation of the supplier to provide appropriate resources to address any problems in the area of cooperation. This model is also beneficial for the supplier because it offers prospects for a continuous fixed-term solution delivery process.

It is proposed that the contract has to define procedures compatible with Scrum project management and consequently the following roles are featured as a part of collaboration:

 Managers (one for each party) - are responsible for the formal and legal course of the agreement and controlling of the work environment.

 Business Owner (customer's employee: like Product Owner in Scrum methodology) - is responsible for defining and prioritizing requirements in the initial phase of each milestone (iteration in Scrum methodology) to ensure maximum improvement in the efficiency of business processes.

 Team Leader (provider's employee: like Scrum Master in Scrum methodology) - is responsible for cooperation between the Development Team and the Business Owner and for compliance with the contract rules governing management of the project.

 Development Team (provider's employees) - is responsible for selecting requirements (scope of work) to be fulfilled within a milestone from the Basic Product Backlog (equivalent to Product Backlog in Scrum methodology) and

Agile Management of Research Projects in the Contract Context 51

the milestone length at the beginning of each milestone and for the transfer of the developed deliverables to the Business Owner before the milestone end.

The names defined by Scrum are changed to emphasize the responsibility modification. For example the Team Leader must not only follow the Scrum rules but also take care about contract limitations and obligations. It requires some familiarity with the local legal system. The Business Owner is additionally responsible for validating of the workload settlement in the context of the selected milestone scope.

Work scope selection, designing, preparation of deliverables (software, documentation, graphics etc.) and deployment (installation, configuration, testing, and documentation) will be effected in specific time cycles called milestones. The milestone length should be fixed each time and should not exceed 2 months. It is the upper limit that should be a compromise between the development needs and business bureaucracy inertia.

Each project begins with defining the direct target, initial functional requirements (a set of required functions) and non-functional requirements (a set of required solution features) that make the Basic Product Backlog; that backlog gives grounds for selection to determine the scope of further work in the next milestone.

The Development Team selects requirements at the beginning of each milestone, on the grounds of their priorities agreed with the Business Owner and the scope of work selected to be carried out in that milestone, which (according to the Scrum rules) remains unchanged for that milestone. The milestone scope selection is a negotiation process based on the business objectives represented as requirements priorities and technical limitation analysis. Unfortunately, it usually causes a longer iteration cycle because it is not enough to provide something that works, as it has to work also for business. Good examples are code refactoring in software development or design documentation preparation. For business, this work provides no value at all so if required it must be included as negligible part of the whole milestone scope of the work.

The Development Team hands the products of the completed milestone (including deliverables such as software code, documentation etc.) over to the Business Owner at the milestone end.

Any work that has not been completed during the milestone for any reason returns to the Basic Product Backlog and is subject to priority analysis and technical dependencies for the next milestone. All new requirements defined in course of work are entered into the Basic Product Backlog as well.

The reported team workload and the value of granted licenses and copyright form the basis for settlement. The workload is settled on the grounds of monthly reports submitted to the Business Owner and the Managers. It is calculated at the common basic rate per man-hour. It is important to apply the common basic rate with the goal of mitigating customer's influence on association of the team members and tasks.

On completion of the project, the customer gets a license granting him a right to use software and supplied deliverables.

In order to minimize the risk of underestimation or overestimation of the project budget in case there is a great deal of uncertainty about the research field, a feasibility study, design work or a pilot application may be executed in order to determine:

 qualitative (direct and indirect) business goals,

 technical solutions optimal against selected KPI,

52 From Requirements to Software: Research and Practice

 necessary investment outlay on the purchase of third party products,

 own and third party workload,

 maintenance costs of the proposed solution,

 selected economic efficiency indicators,

 risk analysis as a component of risk management; it consists of identification of possible negative external and internal conditions, events or situations.

Additionally, the risk of budget estimate incorrectness can be minimized thanks to:

 the work cyclical nature, i.e. the possibility of finding an error at an early stage of project execution,

 billing work intensity, which balances risks of both the partners and makes overpayment in case of overestimate impossible,

 maintenance work that ensures the continuity of system operation through the quality of the rendered services instead of a guarantee; it does not exclude guarantee commitments for certain products.

3. Implementation