SCRUM

Agile software development and SCRUM at TTC Informatik

In 2012 TTC Informatik GmbH changed its method of software development and introduced concepts of agile software development and parts of the scrum concept.

Since the establishment in 1997 our users' and customers' feedback enjoys high priority. The agile software development is also about many feedback loops and iterative approaches on every level: while programming, in teamwork and on management level.

The classic approach for software development includes detailed planning of the new system or function in advance followed by one single long passage of development. This approach does not apply to the heat treatment sector for all the requirements can change any time during the project term and often they aren't even fully known at the beginning. Usually the user also misses capacity and / or time to completely define the requirement.

Instead the agile approach rotates between short terms of planning and developing. After a first concept for the new product or the new programme area has been drafted, thus the objectives to be achieved with the software development are set and assessed, a plan for a first version is drawn up and the programming team starts the development. In the course of the elaboration necessary adjustments are made.

You need advice or support?
Happy to help via phone, e-mail, service desk...

Get in touch

Advantage

Every new software, every new program part ought to achieve business goals or describe workflows usually defined by the management / customer / user. Long-time experience shows us that business goals can often not be defined precisely. Furthermore the user often doesn't see the need for change. The recognised business targets are transferred into (software) requirements that the programming results are supposed to correspond to. Therefore a multiple translation process happens: from user to developer, from business targets to requirements and from requirements to programmed software. These translation processes cause substantial requirements to software development since neither defining requirements for a business goal or a certain workflow nor transferring these into new software is trivial. The objective of assessing the results of the transferring process and the determination of when it is best to do so is a task not to be underestimated.

Agile methodology

The agile software method includes a different system, implementing a new function as early as possible outside the laboratory environment. In operational environment it is examined according to the strived business targets and workflows.

Assessing at the end of the project (included in conventional software development) can cause considerable extra effort if adjustments or conversions need to be made. In the worst case changeovers are entirely impossible.

By detecting defects in an early stadium it is still possible to intervene and take countermeasures. This way the customer / user can positively affect the result during development. The core idea thus is to not completely plan the task before the actual programming but to execute the development iteratively in short feedback loops, in SCRUM language called "sprints". This allows reviewing the current state of program development with the user in regular intervals and if necessary intervening and adjusting. Furthermore the iterative approach enables the project team to react to changes or problems at short notice.

Specific usage

Regular SCRUM meetings. During the Daily Scrum Meeting every team member reports the current state of work, problems and the daily schedule. In addition sprint plannings and sprint retrospectives are carried out. The former method includes planning the possible scope of a development cycle by team members to reliably predict target dates. The latter method allows the team to profitable evaluate recognition from previous sprints.

Scrum artifacts are useful representations of partial results / efforts to establish transparency and the option to review and adjust the work. At TTC scrum artifacts are for instance the product backlog and the sprint backlog that can be understood as a list of programming tasks.

Division of roles. Complying with the rules, keeping control over the product vision (the common thread of development), the development team, the client, the user and the management are organised into roles and entrusted with specific tasks and responsibilities.