Author: JIT


“Best buddy”

What awaits a freshly baked IT Hero when he’s on his first JIT workday? The answer can be found here:

Anticipation coupled with some stage fright often accompany the first working day in a new company. In order to prevent a successful start, new JIT employees are expecting an already prepared laptop, system access and workplace as well as a personal buddy who will not give them their first weeks off the page.

The task of the Buddies is the training of the Heroes in the respective project. In addition to the project-specific work processes and organizational structures, this includes above all the provision of technical and domain-specific knowledge. The aim is to raise the new employee as quickly as possible to a high level of productivity and to enable an independent way of working.

The enrollment is roughly divided into the following phases:

1. High-level overview

The buddy sketches a picture of the domain. The system architecture, the tasks of the different components and their interaction are explained. Here it has proven to present the actual use of the system from the end user’s point of view.

2. Low-level details of a component

In order to avoid an information overload, the emphasis is placed on a component whose functionality is examined in detail by means of the source code. Subsequent tasks are limited to this part of the code.

3. Cooperative work

Together with the buddy, the first tasks are performed as a pair-programming task, i. Two developers work on one computer. While a developer takes the active role and writes the source code, the second developer remains in an observational role. He outlines the solution and identifies potential problems. The roles are changed regularly. This agile way of working not only accelerates and accelerates knowledge transfer and team building, but also increases the quality of the code.

4. Autonomous work

After the first few weeks, tasks are solved on one’s own responsibility. The support wheels are not removed, the buddy is supporting in the background. Fixing bugs is ideal for these tasks. After completing a task, a code review will be performed, presenting the solution, suggesting improvements, and identifying any issues with the buddy.

5. Expansion to other system parts

Continuously further components are introduced and tasks aimed at it are solved by means of pair programming as well as independently. The needed assistance of the Buddies is reduced continuously.

Everything learned is always written in the form of glossaries, instructions and system descriptions. On the one hand this strengthens the new knowledge, on the other hand these resources serve as training material for future heroes whose potential buddy is then successfully trained employee.



“How to unite the strengths of scrum and function points in the fixed price model.”

More important than the right metric is the common estimation of complexity

Scrum is now widely used and well known in IT. Everyone knows the popular agile framework, everyone knows what roles there are and the Daily Stand-up has at least already been heard.

But Scrum is not just a framework for project development. Scrum supports you in implementing the values ​​of agile methods. These values ​​were defined in the Agile Manifesto:

Individuals and interactions are more important than processes and tools
Functioning software is more important than comprehensive documentation
Cooperation with the customer is more important than contract negotiation
Responding to change is more important than following a plan

Scrum focuses on the individuals involved and on achieving a successful outcome in the end. It prevents bureaucratic processes at the expense of employee motivation. Obstacles should be overcome as soon as possible through intensive cooperation – both within the team and externally.

At JIT, we use a Scrum process for fixed-price projects whose requirements have been estimated using Function Points. This means we need to adapt the Scrum framework to fit our needs. In two ways, our method deviates somewhat from the usual case:

1) Fixed price projects with Scrum

Realizing fixed-price projects with the agile Scrum method is a contradiction at first sight. However, as customers often prefer the fixed price, we have found a way to combine both.

The use of Scrum in fixed price projects can facilitate collaboration between customers and suppliers. For this it is necessary that the customer lives through the Scrum process. However, this is the case with any agile project, regardless of the contracts or payment methods. The above agile values ​​must be lived throughout the project.

We are involved in the customer development process with our Scrum projects; Here we at JIT can use our greatest strengths – cooperative cooperation and direct external communication. In addition, it is not necessary to appreciate all the requirements for an application at once, because Scrum estimates the individual user stories one after the other. That’s a lot easier.

2) Function-Point with Scrum

The most common estimation metrics for Scrum are not Function Points, but Story Points, but they are not mandatory for Scrum. Much more important than the metric is the comparative appreciation of complexity. Therefore, when one makes the estimation of the complexity of an elementary process or dataset together, story points can be omitted.

A Scrum Team must appreciate together, set the Sprint Goal together and then achieve it together. That’s what matters.

Conclusion: The function point estimate and the fixed price can be profitably agreed with Scrum, if certain permissible adaptations are made. The key to the success of a Scrum project is that the team collectively lives the agile values. JIT fully lives up to this premise. We already lived the agile values ​​before Scrum was even introduced. Scrum has just brought more order into our agile everyday life.


“What household and software development have in common.”

Building a house is no easy task. You have to reconcile conflicting requirements and at the same time meet completion deadlines and existing cost limits. Decisions that you make in planning will have an effect on comfort and value retention over decades.

The situation looks quite similar for larger software projects. It is necessary to specify and limit requirements because the budget is tight and the time to commissioning tends to be too short.

A blatant difference is also clear when comparing house building and software development:

While those responsible for building a house are subject to many legal norms, local building regulations and full liability for errors, software projects are blindfold tested for their code quality. When accepting such systems, the receiver often only superficially tests performance, load behavior and functionality according to the technical requirements. He forgets that the internal code quality is an essential factor for the preservation of software value. Only if the source code is well-structured and of high quality right from the start, additional requirements can be easily and safely integrated retrospectively. High internal quality thus extends the life cycle of a software. By contrast, software of poor code quality is short-lived as it quickly reaches the point of being unpredictable. In addition, inferior software is a cost driver, as any technical change leads to immense effort in implementation and testing.

Although no one would have a house built without standards, building codes and profound control of the work, software projects are usually handled without or with very weak specifications of the internal code quality. Liabilities concern, if any, only the functional requirements. Since there are no standards or legal standards for most areas of software development, this approach is completely legal from a legal point of view, but extremely fatal from the customer’s point of view.

Can the client himself measure the internal code quality? He can. Fortunately, there is very good support from the open source community:

Sonar ( is an extremely powerful tool for quality assurance in software projects. Recorded in the continuous integration process, sonar leaks, ie incorrect codes, can be detected early. In addition to static code analysis, it offers the ability to measure the test coverage, to estimate the effort required to remedy quality deficiencies, etc., using plug-ins. Objective quality metrics can be derived from the analysis and must be adhered to. Consequently, these criteria should also be a necessary condition for acceptance by the customer.

The full benefit of Sonar comes in combination with a Continuous Integration Server such as Jenkins ( Build, test and sonar analysis can be automated and create quality reports and sent by e-mail.

Analogous to building a house, this means that you can check with the said setup at every stage of construction, whether the valid standards are met.

Conclusion: Do not rely only on functional tests in the acceptance of software projects! Pay attention to transparency and do not be fooled by colorful icons and animate user interfaces, but go with Sonar under the surface. Check the quality of the delivered work before it is too late. A quality-oriented supplier will always support you.


“JIT in video portrait”

Here you can see the introductory video from JIT for the WKO Prize Crescendo’14, in which Thorsten presents the company profile in a concise Q & A. You will learn, among other things, what the egg of Columbus has to do with our philosophy.



JIT was nominated for the Entrepreneurs Award Crescendo’14 in the category “Rise” in September of this year. On this occasion, a short article about JIT has been published in the magazine ON of the WK Vienna, which you can find here.

He portrays our CEO, Thorsten Guggenberger, and praises the medium-term development especially in terms of convertibility and the willingness to calculate the risk. He also explains his bold move to use the fixed-price calculator to launch a transparent service that has not been touched on in the IT industry.

from troubleshooter to pioneer (S.9)


“The krux with the IT effort estimation.”

In the IT sector, CEOs and CTOs often face a major problem even before the start of a project: the effort estimate is unclear. They often know relatively well which software they want, but they do not get exact price calculations from IT companies.

Why are there no reliable offers?

When it comes to cost and effort estimation, it’s important for IT companies to make complex predictions and to consider the time, labor, and money factors. The same applies of course to the clients, ie CEOs and CTOs, whose decision to accept an offer depends considerably on the level of costs and the transparency of the cost list.

The cost structure for any project usually consists of license costs and mostly personnel costs. The realization risk must not be too high and also pre-financing costs and any personnel increase costs must be kept small. The accuracy on the part of IT companies often leaves something to be desired: Either the price can not be narrowed precisely, or a flat rate is specified, but the concrete services that a software package covers are opaque. Sometimes clients choose a compromise solution that is rarely ideal. In addition, complex feasibility studies often consume a lot of time and money even before the project starts. No wonder, if you are overwhelmed as a manager with these complications.

How do I arrive at a clear expense estimate?

Remedies for these problems create transparent fixed costs, which are fixed from day one. J-IT uses the Function Point method developed by Allen J. Albrecht as an estimation method, which assumes functional requirements and can therefore be used independently of the programming language. With this procedure, we can specify almost exactly how much a project costs and which individual services are included right from the start. In order to offer companies a transparent price calculation, we have set up our fixed price calculator on our webpage. It enables interested parties to get a crystal-clear offer within minutes, which is no longer shaken afterwards. Although this billing model carries risks for us, we have decided to take this step. This makes it easier for companies to understand the IT price nebula and to plan the purchase of individual software solutions effectively. Here you can calculate the costs for your IT project with our fixed price calculator.