What You Need To Bring In

In order to obtain the expected results of the project with our flexible and transparent approach, you must help us a little more intensively than you might know it from traditional software projects. We need from you in particular.


1The person responsible for the product knows the business processes to be implemented in the product and those surrounding the product with sufficient precision to derive the product functions with their business value from them and to plan their implementation in the project. He alone is responsible for the return on investment by designing the product over time, i.e. he determines WHAT and WHEN. In agile projects it is also referred to as the “single drinkable neck” and is a mixture of product manager and project manager.


2Depending on the project size, one or more end users should support the project. In addition to the person responsible for the product, they are the direct contact persons for the detailed design and acceptance of product functions. Only by involving end users can it be ensured that the product is not developed without the support of the people who will later work with it. The scope for design is clearly limited by the scope of the func­tions defined and planned by the person responsible for the product. This prevents the infamous wish concert.


3In order to establish a continuous delivery flow in the project, continuous par­tici­pation of the customer re­pre­sentatives is also necessary. In addition to regular meetings for requirements clarification, project planning and quality assurance, project managers and end users are available at fixed times of the day to answer developers’ ques­tions.


4The first agile project initially unsettles most customers because it lacks the central pillar on which the perception of security in classic projects is based: The requirement specification and the detailed project plan based on it. However, it only takes a few iterations before they realize that the security provided by the degree of completion of work packages is only a sham. It quickly becomes apparent that real security in the project can only be created by delivering real value, i.e. usable product functions.

Trust in the agile approach is most quickly gained when you apply it. However, it takes courage to leave even seemingly safe ground and break new ground. The great success of agile processes may make this step a little easier. We cordially invite you to join us.