Tải bản đầy đủ - 0 (trang)
1 Case Study: The BERGFÜRST Crowd Investing Platform

1 Case Study: The BERGFÜRST Crowd Investing Platform

Tải bản đầy đủ - 0trang



adVANTAGE in Practice

investors may want to support a project because they find the idea personally

attractive and want to see it implemented.

In our case study, since trust in the capability of the contractor had been

established through personal contact, since a lot of positive experiences had been

made with agile software projects, and since the geographical proximity at the

Berlin site promised close collaboration, the IT service provider adesso was chosen

as the contractor for the realization of the BERGFÜRST crowd investing platform.

The decision in favor of an agile process model was apparent from the outset. There

was no exact description of a business model, nor a concept of the individual

processes and features needed for the platform. This ruled out a plan-driven method

based on a specification prepared in advance, if one did not want to lose precious

time before the development team could start working. However, a fast start to

development was essential since a short time to market was desired. This was a

classic situation calling for an agile method: unclear requirements, little time before

the start of development, and a client who wants to evaluate real software as quickly

as possible.

After a detailed presentation of the model and after reaching a fundamental

agreement regarding the project objectives, the parties agreed on the adVANTAGE

contract model. What mattered most was the model characteristics that align the

interests of both parties with the same goal: generating business value quickly while

keeping the development effort as low as possible. The desired business value could

only be outlined as a high-level vision at first. A platform should exist where

companies and investors could find each other, and that would handle all processes

required for financing. After the adVANTAGE parameters were established in the

course of a negotiation session and a corresponding contract was concluded based

on the sample contract described in Appendix C.1, the first workshop was carried

out in the IR:scope. The goal was to prepare a feature canvas to obtain an initial

overview of the stakeholders for the planned platform. Figure 16.1 shows an

example from the IR:scope and a section of the first context model.

In addition to the context model, a system of targets influencing the course of the

project was established. An excerpt from this target system is shown in Table 16.1.





Soziale Netze





Payment Provider





Market Maker








d. Emittenten











Bank des















Investors Relation
















Weiteres Umfeld

Fig. 16.1 Interaction Room with context model and feature canvas for the BERGFÜRST project


Case Study: The BERGFÜRST Crowd Investing Platform


Table 16.1 An excerpt from the BERGFÜRST target system









1: Companies








(issuers) want to offer shares as own issues to obtain capital

The book building method is to be used for the issue

The issuer wants to generate predefined minimum proceeds

The number of shares issued is to be established before the issue

The price range for a share is to be established before the issue

The issuer wants to issue a minimum volume of shares

The issue process is to be confirmed by an auditor

Only one issue process is to be carried out at one time

Based on the target system and context model, a list of about 65 features was

then derived, put through the initial estimation process described previously and

prioritized. Various estimating methods such as expert estimation, planning poker,

and relativizing estimates were combined due to the high level of uncertainty. The

sum of the initial estimates for all features (the entire product backlog) was over

500 person-days at the end of this process. Eight sprints with a duration of three

weeks each were planned. The initial team consisted of three developers, a scrum

master assigned to the project half-time and a proxy product owner who, together

with the product owner on the client side, assumed responsibility for the product

backlog maintained in the IR:agile and for acceptance of the completed features.

Only a few weeks elapsed between the fundamental agreement on the contract

model and the start of development. The team was able to begin with the production

of presentable and usable software quickly. As previously noted, the basic conditions were anything but stable. The exact business model was not established until

halfway through the project. While the focus was exclusively on company financing

at the outset, support for financing real estate funds was to be enabled as well in a

later phase. Changes were also made repeatedly to the features at the detailed level.

For example, it was not clear at the outset how to handle the reservation of payments: As long as a crowd-funding project has not found the minimum number of

investors, whether it will be realized at all remains uncertain. Once this threshold is

exceeded, one needs to ensure that all investors actually make their financing

contribution. However, reserving funds through a variety of payment methods is a

process that can require a banking license in certain cases. Such uncertainty needed

to be resolved, and decisions had to be made in the course of the project while

software development proceeded at top speed. Imponderables also existed at the

technical level. The first version of the portal ran in the cloud under Amazon Web

Services to enable the fastest and especially most flexible possible response to

future requirements for the production environment. Later, it turned out in the

course of discussions with the BaFin (the German Federal Financial Supervisory

Authority) that this does not comply with the applicable security regulations in

regard to processing certain financial transactions.



adVANTAGE in Practice

In short: BERGFÜRST was a truly agile project with uncertainties from many

perspectives. This made adVANTAGE downright ideal as a contract model, and the

corresponding requirements were met as well, with mutual trust between the

partners being first and foremost. Both sides noted that this trust was justified after

just a few sprints: The contractor dealt reasonably with change requests, while the

client displayed understanding for less than optimal productivity at the outset due to

the uncertainties and rapid changes. In parameterizing the adVANTAGE model,

besides the regular and reduced daily rates DR1 and DR2, a special daily rate DRPO

was agreed for the work of the proxy product owner. The base rate BR was initially

set quite low and not raised later even when the team was expanded, since it turned

out that the overhead in the closely cooperating team of the two contractual partners

was extremely (and favorably) low, and because the sprint duration was shortened

to two weeks in return. An efficiency incentive was not defined.

The adaptations of the business model during the course of the project and the

resulting changes and additional features in the product backlog ultimately led to 13

sprints instead of the eight calculated originally. Instead of slightly over 500

person-days calculated from the initial estimate, a total of approximately 650

person-days of actual effort was recorded. One particularity was the composition of

the team over time. While all software experts were originally from the contractor

adesso, developers from the client’s team were gradually added. This was therefore

a cooperative performance structure in the sense of Fig. 11.1. These employees

initially operated outside the budget and, after corresponding training, were treated

like developers of the supplier except that their work did not appear on the invoice

Fig. 16.2 The BERGFÜRST crowd investing platform


Case Study: The BERGFÜRST Crowd Investing Platform


in the end. Enabling long-term further development and maintenance by the client

was the goal, which has also been fully implemented in the meantime. The resulting

portal (Fig. 16.2) is being further developed and maintained by BERGFÜRST

under its sole responsibility today.


Fine-Tuning adVANTAGE Parameters

In the presentation of the general adVANTAGE model and the preceding

description of the example, the values for the typical parameters of the settlement

model were not discussed in detail. However, the exact parameterization of the

model is anything but unimportant in a practical project context. We are talking

about the following variables in particular:

Sprint scope,

Sprint duration,

Base rate,

Regular daily rate,

Reduced daily rate, and

Efficiency incentive.

The first two parameters, sprint scope and sprint duration, will not be influenced

to a significant extent by commercial aspects of the adVANTAGE model in

practice. Rather, they will be determined according to practical considerations

based on comparable projects. The sprint scope is the maximum number of

person-days that can be used in a sprint for the implementation of features. It is

roughly determined by multiplying the number of developers by the sprint duration

in working days. But since the developers cannot spend 100 percent of their time

programming features, but also have to perform overhead tasks paid by the base

rate, the product has to be multiplied by a productivity factor (such as 85 percent

depending on empirical values) to determine the actual, realistic sprint scope.

Regarding a sensible team size, i.e., the number of developers that can collaborate

efficiently on an agile project, we refer e.g. to Lindvall et al. (2002).

The sprint duration not only affects the sprint scope for a given team size, but

also has a direct impact on the base rate. Insofar, it clearly has commercial effects.

But as long as we assume that sprints in agile development processes should not be

longer or shorter than a few weeks, the commercial effects become rather blurred.

This is why choosing the sprint duration should be guided less by economic and

more by practical empirical values. One should not be afraid to change the sprint

duration either (in the course of the project, not during a sprint)—of course this

means adjusting the base rate if applicable.



adVANTAGE in Practice

We listed the essential components of the base rate in Sect. 15.1. They are also

the cost drivers that form the basis of a corresponding calculation. Ultimately, this is

the estimated effort for the scrum master, regular meetings, and planning tasks

multiplied by a daily rate as the calculation base, as well as the establishment of a

warranty surcharge that can be estimated as a percentage of the sprint budget. Here,

a supplier should calculate soundly but also not be too fearful. By far, the greater

share of the settlement, which therefore has more leverage, will consist of the effort

for realizing the features.

Agreeing on the regular and reduced daily rates is therefore of vital importance.

The simplest case is when the contractor and client have already worked together

successfully in other projects on a T&M basis. A regular daily rate that considers

the expectations and pain thresholds of both parties has already been established in

this case. The reduced daily rate on the other hand is more difficult to determine. It

needs to be set so that the supplier does not really want to work at that daily rate,

but does not suffer an economic disaster either. A price that is close to the cost of

production for the work has repeatedly proven itself as negotiable in practice.

Fine-tuning will be largely limited to a range of a few percentage points above or

below this threshold. The client may be very interested in seeing the contractor

“suffer” if the budget per feature is exceeded. However, the client should consider

that every percentage point below the cost of production not only increases the

inclination to inflate the estimated effort, which leads to more discussion in the

project, but also that the supplier will demand a higher efficiency incentive in return

as well.

The efficiency incentive in the standard model represents a share of the reduced

effort for implementing the respective feature compared to the initial estimate. If the

contractor remains below the agreed budget, it can bill a percentage of the difference anyway. As usual, the higher the risk, the greater the opportunity—as long as

the parties deal fairly with each other. In practice, the rate is between 10 and 50 %,

depending on the values of the remaining parameters since an overall package is



Lindvall M et al (2002) Empirical findings in agile methods. In: Wells D, Williams L (eds) Proc

2nd XP Universe and 1st Agile Universe Conf on Extreme Programming and Agile Methods.

Lecture Notes in Computer Science, vol 2418. Springer, pp 197–207. doi:10.1007/3-54045672-4_19

Ordanini A et al (2011) Crowd-funding: Transforming customers into investors through innovative

service platforms. J Service Management 22(4):443–470. doi:10.1108/09564231111155079



A sample contract for adVANTAGE projects is found in Appendix C.1. It is

intended to outline the basic legal conditions for a project where the two parties to

the contract have decided on a very special cooperation model—a model that

accepts uncertainty as given and distributes the opportunities and risks fairly on this

basis. However, the most important principle cannot be guaranteed, even by contracts that are negotiated in detail and cleverly phrased: trust. This is why we

postulated that mutual trust is an essential, core principle of adVANTAGE in

Sect. 14.2. Trust is so important because both parties assume risks in the course of

an agile project that result from inherent uncertainty. This uncertainty refers to the

fact that estimated effort always remains an estimate, as much as validation is

desired. However, the adVANTAGE contract model is an instrument to align the

economic interests of the contractual partners with the same objective, which is to

adhere as closely as possible to a cost budget agreed in advance.

However, this contractual (legal and/or commercial) aspect is only one side of

the coin. The other is derived from the methodic framework which is provided by

the Interaction Room, and especially its IR:scope and IR:agile variants. In the IR:

scope, the two parties to the contract find an opportunity to discuss and establish the

scope for the intended project. On this basis, the IR:agile then makes it possible to

repeatedly review the intrinsic value of the agile development project across all

phases. It therefore provides the tools for managing the entire life cycle. Managing

uncertainty is supported by the division into manageable sprints as well as

feature-based controlling and settlement. Insofar the concepts of the Interaction

Room and the adVANTAGE contract model go hand in hand.

Whether and when adVANTAGE is the right model for cooperation between

two contractual partners can be discussed on a case-by-case basis. Figure 17.1

illustrates the dimensions relevant for such a discussion.

The dimensions of interface intensity and likelihood of manifold late requirements were already discussed previously in Chap. 10. The following dimensions

are added in the context of the adVANTAGE model:

© Springer International Publishing Switzerland 2016

M. Book et al., Tamed Agility, DOI 10.1007/978-3-319-41478-2_17








i l






i i









i ii




Fig. 17.1 Suitability of adVANTAGE for a concrete project

• Vertical integration: adVANTAGE is based on the assumption of continuous

management of changing requirements, making it especially well suited when

such flexibility is permitted. This makes it unsuitable when, for example, large

work packages are to be developed externally at fixed prices or off-shoring

models are to be applied.

• Reliability of Definition of Done: adVANTAGE is based on the continuous

reprioritization of features and the completion of individual features in the

shortest possible realization cycles. Both make sense, provided it is clear when a

feature is considered done. Why we accept that a formally determinable DoD

does not exist in the adVANTAGE model was discussed in Sect. 14.2. Nevertheless, the parties to the contract should have compatible expectations to

mutually support an assessment of the state of completion with reasonable


• Importance of economic transparency: adVANTAGE is intended to benefit

both parties to the contract, also economically. The observation of economic

efficiency is therefore an essential means to check whether the initial goals can

still be reached or have been reached already. However, the level of detail

required for information about the economic efficiency of an ongoing project

can vary widely. It can range from a general prediction (“everything is looking

fine, we are within the cost budget”) to current forecasts and projections on a

feature basis. Cost and budget transparency should be granted to those who

exchange and re-prioritize requirements in projects according to the adVANTAGE model, since this is the only way they can evaluate the economic effects

of their own actions.

• Importance of risk sharing: A key characteristic of the adVANTAGE model

is the special approach to the management of software development risks.




The contract model supports a fair distribution and sharing of these risks. The

more important the issue of risk sharing is for the parties to the contract, the

more suitable the adVANTAGE model.

In Chap. 14, we introduced the brief adVANTAGE formula “price + contract + procedures.” Compared to the contract models for agile software projects

discussed in Chap. 13, adVANTAGE in combination with the Interaction Room

offers a comprehensive framework—consisting of commercially (price) and legally

(contract) effective elements as well as concrete methodology support for project

activities (procedures). How this can look like in concrete terms will be illustrated

by the example in the following part.

Part IV

A Sample Project

Case Study: The Cura Health Insurance

Benefit System


To put the methods we presented in the previous chapters into a larger context, and

give an idea of an appropriate modeling volume and level of abstraction as the

project progresses from its initial setup to operations, we present a visual documentation of the models that evolved in the Interaction Room over the course of an

actual project. After a brief introduction to the project, the examples from the

project scoping phase using the IR:scope are provided with commentary explaining

both the project domain and the IR coaches’ choices, as well as references to

preceding chapters for a more detailed description of the respective modeling

techniques. We then explain the process of monitoring the project with the help of

the IR:agile and present lessons that could be learned from the application of the IR:

scope and IR:agile in this project.

The example we are using to demonstrate the IR:scope, IR:agile, and their

interplay is the development of a private health insurance benefit system (HIB).

Such a system supports all processes related to serving policyholders as briefly

outlined below.

Prior to the treatment by a doctor which may lead to insurance benefits (i.e., the

reimbursement of costs to the policyholder), prequalification may occur (e.g.,

prequalification to determine whether and what proportion of certain dental treatments that could also be due to cosmetic reasons would be reimbursed). Therapy

plans may be the subject of prequalification as well. These are used in case of

certain diagnoses to commission dedicated Personal Injury Managers for monitoring, controlling, and intervention. The actual granting of insurance benefits then

follows the treatment based on invoices and receipts that are submitted. All sorts of

investigations are conducted prior to the actual granting of benefits. These pertain

among other things to violations of disclosure requirements before the contract was

concluded, insurance exclusions, and the appropriateness of the services provided

based on type, scope, and fees. All communication related to benefits must be

recorded in order to avoid future misunderstandings and so that disputes can be

examined in the overall context.

© Springer International Publishing Switzerland 2016

M. Book et al., Tamed Agility, DOI 10.1007/978-3-319-41478-2_18




Case Study: The Cura Health Insurance Benefit System

On the one hand, all of this needs to be done quickly and in a user-friendly

manner in modern benefit systems such as the HIB system described here, so that

customer dissatisfaction is avoided. On the other hand, there should be no payment

of benefits that are not required according to the contract. All of this should happen

reliably and, in view of the challenging economic situation faced by health insurers,

with as much automation as possible. Intervention by administrators shall only take

place when their technical expertise is required.

The HIB system was developed in close coordination of the private health

insurer Cura AG1 and the contractor adesso. The health insurer assumed the role of

the requirements originator and participated in development with its own personnel.

Most of the development work was to be handled by adesso. The software system

being developed was to be integrated into Cura’s application landscape and would

be operated by Cura. It was clear to the stakeholders that the new development of a

benefit system is subject to the risk of simply replicating the existing production

system, without taking advantage of the opportunity for functional optimization and

innovations. They wanted to avoid this risk. The stakeholders were aware that there

would be late requirements and agreed to omit the preparation of the most complete

possible specification. Instead, they intended to compile the functionality and

describe it as concisely as possible. Only functionality with a high potential for

misunderstandings was to be described in more detail. Even though the initial

descriptions would largely be brief, the effort was to be estimated at the feature

level. The two companies used the IR:scope to establish the scope of the system

being developed. They agreed to establish a requirements exchange in order to

continuously swap late requirements for early ones, to regularly use the risk map

and to apply adVANTAGE in order to share risks between Cura and adesso.


The company and stakeholder names have been changed to protect the client’s anonymity.

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

1 Case Study: The BERGFÜRST Crowd Investing Platform

Tải bản đầy đủ ngay(0 tr)