Secrets of Successful IT Development Teams

There are IT companies and there are successful IT companies. When it comes to the latter, development teams simply know what they are doing, and there are reasons for that. We know that every successful project needs to have clearly defined deadlines and budget, that the agreed functionalities must be delivered, and that the standards of the profession must be met. Development teams are the ones keeping track of all of this – and it is necessary that they have a clearly defined project task and a project manager with a clear role, which is to find out as many details as possible from the client in time to avoid any mistakes at the very start. Some of these mistakes are unrealistic expectations, an over-optimistic schedule of project tasks, assumptions about the development path of the product or service, confusing the assessment of the task and the actual goal, too much multitasking, changing strategy within the development cycle and making all tasks a top priority.

The main feature of successful development teams – which can be up to ten times more successful than others – is the correct choice of project development strategy, which is determined by the parameters of delivery time, budget, team size, detailed task description and goals. Delivery time is determined after the development team evaluates the tasks it has to perform, i.e. how long it will take to develop something. The budget is determined by the client and measured in the time and money available for a particular project, while team size depends on the complexity of the project.

High quality teams have a great advantage – they know how to describe tasks in detail based on the goals set by the client to prevent misinterpretation of a seemingly simple task. Also, they know that they can primarily work on only one project at a given time.

Good Assessment and Eliminating Unknowns

Teams with good practice will first identify all the unknowns in the request delivered to them by the client, while a team with insufficient experience will generally start development immediately and simply assume what the project client thought or wanted with certain tasks. A more experienced team knows that they will spend far more time correcting mistakes made from wrong assumptions, which is why they will first identify all the unknowns and take the time to correct and clarify them. This includes holding new meetings with the client and only after all doubts have been removed will they start planning the tasks and estimating their duration. If the case is developing a longer project – say six months or more – it is necessary to plan the tasks as far as it is realistically possible to avoid the mere fulfillment of the planned tasks with no subsequent evaluations of the actual current state of the project.

The chosen development method is also important, be it agile, waterfall or some other, and it is even more important that the current state of the project is regularly reviewed in order to eliminate possible risks and so that the project can be successfully delivered on time. Thus, the initial assessment plan must be updated on a weekly or monthly basis.

A good development team will choose the strategy that is best suited for the particular project rather than sticking to just waterfall or just agile development strategies because they are currently popular; they but will make sure they do the job in the most efficient way. This means that they will choose a proven technology that they have experience in working with and avoid experimenting with new technologies – unless otherwise specified – because it could bring many unknowns and challenges that will then require additional time. In development, it is important to use tools that will improve the process itself instead of adapting the process to the tools we have chosen.

Essential: Knowledge Pool and Daily Stand-Ups

Some of the mistakes made by less experienced development teams are avoiding documenting the course of the project, inventing pre-existing procedures and insufficient communication among team members. The combination of these three mistakes leads to a significant loss of time in the development of products or services. The most important thing is that the team keeps documentation of project development, records all problems and solutions, and saves them in a so-called knowledge pool, that is, a place on a SharePointor repository to which all members have access, so that time is not wasted on the same things in the future.

A well-coordinated team will also use the possibility of a daily stand-up meeting, occurringat the same time every day, where they will talk about what was done yesterday, what needs to be done today, and whether there is a problem that needs to be discussed.

What is extremely important in good teams is code revision which ensures code quality in development and reduces the possibility of repeating the same mistakes. A team that does not have enough development experience will often say that they do not have time to review the code because they must complete the development. However, practice has shown that such an approach frequently leads to an increased number of defects during the user test and that solving those defects takes more time than reviewing the code, which would have helped to identify and eliminate the potential problem earlier, ultimately saving money.

Development Defects

The cost of defects that are not detected during code revision can be very expensive. Why? Any defects detected by users during the user test must be recorded, returned to the development team, which must then confirm whether it really is a defect or just a refinement that was added later, spend time to correct it, and then tested once again. A good development team will have a minimal number of defects in user testing, because they prevented a lot of them at the very beginning, when they were defining tasks and resolving unknowns.

According to Gary E. Mogyorodi, about 83% of all defects exist before even one line of code is written. In his experience, 56% of all defects in product development occur due to insufficiently well-defined requirements. He points out that requirements that are not clear enough are the most common cause of failed projects. He also states that in the phase of defining the request, changing the request is the cheapest part. The rest of the defects, in terms of design and the code itself, are mainly related to the fact that the request itself is poorly defined and not sufficiently tested, so it is expected that there will be design errors because the request was misinterpreted. In addition to design errors, there are also errors in writing the code, which makes up the smallest percentage of all the defects in the project.

Error Detection Thanks to Unit Testing

A good team will perform a unittestafter each task or unit has been developed. A unit test is part of the code written to check previously developed solutions of a unit or task, according to the assumptions used to develop the solution. If the assumptions turn out to be wrong, the unit testis considered unsuccessful, and the program code must be refined. Teams with less experience often do not perform unit testing or any other form of testing before Factory Acceptance Testing (FAT) or User Acceptance Testing (UAT), which is why they waste the most time because design and code errors could have been observed and resolved much earlier.

Furthermore, an inexperienced team will also more often make mistakes in the assessment process, i.e. the process of predicting the most realistic amount of effort – expressed in man-hours or money – required to develop or maintain software due to incomplete or uncertain input. Poorer performing teams will often overestimate their capabilities, whether because they want to impress users with the time it takes them to create a project or because they fall under the pressure of a deadline and agree to something they know in advance they will fail to fulfill. A good development team will not confuse ‘assessment’ and ‘goal’ because they know that ‘goal’ is the date given by the user as the deadline for the delivery of the product or service, while the ‘assessment’ of tasks within a project lies under the full responsibility of the development team.

We all know that by working on different projects we encounter different challenges, as well as that the most important lessons are the ones we learn through relationships with clients and through the joint effort to remove doubts related to the project tasks themselves.

Tentatively speaking, the biggest difference between a good and a bad team is the experience of project development, which is gained through making mistakes, reflecting on them, and taking action to prevent repeating them. It is impossible to stress enough how important it is to remove all ambiguities in the beginning and not to rush into the development of the project to complete it as soon as possible – because we will complete the most work if we define all the requirements well in the start and if we’re sure we all have the same picture of the goal we want to achieve.