Implementation Prerequisites

3.1.

Successful implementation of the proposed methodology requires appropriate measures to:

 Implement billing principles.

 Support defined roles and management rules in a consistent way.

 Promote mutual trust.

All are closely related to rules that must be concluded by the contract. There is no doubt that it requires appropriate tool selection generating reports formally acceptable to the customer Account Department to effect the settlement and effectively support management rules at the same time. The main purpose of this section is the definition of requirements that have to be met by the tool.

A variety of out of the box products supporting implementation of the Scrum management rules are available on the market. A set of primary prerequisites for the proposed approach must be defined to select one of them or decide to develop a new one. All of them can be grouped into the following categories:

 Business processes: to organize the work.

 Data model: to represent vital information.

 Functionality: to process the data according to the business process rules.

Even though the detailed description of all the prerequisites is beyond this paper scope, the topics most important to the proposed methodology implementation will be discussed in the following subsections in hopes of making the decision process easier.

The discussion could also be used as a starting point to expand the existing products by the end user or vendor with the aim of implementing the contract rules proposed in Section 2. The requirements defined in this section are vital for the decision as to how the presented methodology should be deployed in the case study presented in Section 4.

Agile Management of Research Projects in the Contract Context 53

Business Processes 3.2.

Any business process is a series of logically related activities or tasks (such as planning, research, development, design, testing, documentation, etc.) performed together to produce a defined set of results. According to the Business Process Model and Notation specification [11] a business process can be formally modeled as:

 Roles: a set of actors engaged in activities

 Activities: a set of actions and events

 Relationships: a set of workflows and roles communications

 Artefacts: a set of data objects, groups and annotations

For the methodology proposed in this paper, the roles together with their responsibilities and expected behavior as defined in Section 2.2 must be transformed to actions and workflows.

Communication of roles is crucial to the performance of actions and final results quality for the kind of business processes discussed in this paper. The main feature of this communication is unpredictability of forms and formats selected for this purpose by the Development Team. For example, brainstorm results may be documented as a thread on a discussion board, picture of notes/diagrams on a white-board or meeting minutes.

Unfortunately, the results remain often undocumented at all and the supporting tools must, therefore, engage the Development Team to select one and provide documentation for the most important collective actions.

On the other hand, the selection of forms and the necessity of preparing documentation must follow the general agile management principles, for example documentation of a Development Team daily meeting can be recognized as time wasting.

Business processes aimed at accomplishing an innovative project may produce a variety of results but intellectual properties are usually the most important ones, i.e.

discoveries, formulas, inventions, knowledge, registered designs, software, know how, etc. In spite of their intangible nature they must be documented to be useful as an outcome of the project governed by contract rules. In this case documentation is a representation of something that has no physical existence otherwise. Documentation or other forms of intellectual property representation are of special importance as the contract must not be used to describe any form of abstraction.

Business processes are usually expected to produce results of the highest possible quality level. Because the Development Team’s outcome is intellectual property (some kind of abstraction) the question how to improve the quality arises. To address this necessity it is proposed to combine the following tracking functionalities into one consistent mechanism:

 Deliverables including code

 Tasks and issues

 Workload

 Entities representing the process state

Deliverables tracking is used to maintain current and historical versions of files such as the source code, web pages and documentation. The tasks and issues tracking mechanism allows the team members to follow the sequence of actions undertaken to fix the problem or obtain the requested result. An association of each reported workload with a task and team member should be a good motivation to improve individual

54 From Requirements to Software: Research and Practice

performance and engagement [13] [14]. It is worth noting that during the task lifecycle it typically changes the current owner many times. Any record describing a workload must, therefore, preserve information about the associated team member's activity. The tracking mechanism should also facilitate diagnostics and finding workaround solutions.

An entity is a collection of properties representing selected data – a class - of the current process state.

Data Model 3.3.

Contract settlement and, finally, billing requires accuracy. To put trust on the accuracy, the settlement mechanism must be easily verifiable on a continuous basis, and unambiguously associated with the related workload.

In spite of the management rules governing the project, the team work is organized on the task basis. Tasks are defined to describe work needed to fulfill requirements planned for the selected milestone. This relationship between Task and Resources is dynamic and can be changed several times during the task lifecycle. Each reported workload must be associated with a relevant task. To promote auditability and team members engagement, the reported workload must be also accumulated for each member individually and associated with the task. Both associations are permanent for the whole task lifecycle. A follow-up class diagram is shown in Figure 1.

Figure 1 Task relationship diagram.

To successfully finish any milestone, all associated requirements must be accomplished. Before being selected for a milestone all requirements make up the Basic Product Backlog. The Business Owner should be able to add, update, prioritize, split, merge and categorize them.

The contract billing rules use Project class entities to represent:

 Budget limit

 Scope

 Timeframe

 Quality

The Project is, therefore, a collection of Milestones (Figure 2). This way functionality counting the reported workload for the project can be easily implemented.

Agile Management of Research Projects in the Contract Context 55

The requirements planned for any milestone and related tasks can be used to manage and monitor the project scope. To facilitate this process and allow all participants to monitor the work progress, the entity of the Task class has to expose status information.

Each task is a collection of actions reported as workload items and should be defined in terms of the baseline start and end times planned to realize it and actual timing information collected from the underlying Workload records.

Figure 2 Project relationship diagram

To support diagnostics and maintain quality, the model shown in Figure 2 has an additional relationship between the Task and Milestone classes to provide supplementary tracking information that allows the current owner to recollect situation at the point in time it was created. Registering all modifications of entities shown in Figure 1 and Figure 2 should be required for the same purpose.

According to Section 2.2 the Contract class is a collection of Projects (Figure 3).

Its role is to provide a set of rules governing the engaged parties cooperation. Therefore, together with the surrounding entities, it should provide information allowing mangers to:

 Synchronize and schedule work realized as separate projects

 Optimally use resources

Sometimes splitting even closely related work is necessary in case a different Business Owner must be assigned. Engaging the same team into many projects must be limited by the working hours – team capacity. Theoretically the optimal load of the team as a whole is near 100% potential capacity limited by the working hours. To fulfill this requirement the Estimation class is added to the model (Figure 3). At the planning stage its role is to establish the Development Team of a project and assign estimated workload to the team members. It is worth noting that resources usage must be monitored for each individual separately irrespective of its teams association.

56 From Requirements to Software: Research and Practice

Functionality 3.4.

Generally speaking, implementation of the methodology proposed in this paper requires functionalities that may be grouped as follows:

 Contract management centric

 Project management centric

 Product management centric

People hate to track time, but it has to be done to provide the project settlement mechanism. Time tracking should be fast and easy, however, since progress reports and contract billing are based on accurate time records, it must prevent team members from reporting workload overlapping in time and associated to more than one task. To facilitate workload reporting, the user interface may offer functions like stop-watch, workload entities snapping, common activity reporting, etc.

The workload tracking result may also provide a very good feedback that can be used for further improvements of the project scope planning, budgeting and personal improvements. A good source of feedback making a common experience foundation for planning is a well-suited periodical report generation mechanism. A different solution is required for the analysis of the individual engagement. It could be obtained by using a personalized dashboard that integrates workload reporting and monitoring of reported workload.

Figure 3 Contract relationships diagram The project management has to be supported at least by:

 Requirements/tasks management

 Work organization and planning

 Team member communication and documentation

 Deliverables management

Agile Management of Research Projects in the Contract Context 57

The main challenge faced up by innovation deployment projects is commercialization of the results. Even if a result is launched as a prototype, a release procedure and lifecycle management support must be considered. It requires documents versioning, i.e. assigning either unique version names or unique version numbers to unique states of document sets (e.g. computer software).

4. Case Study