Software development methodologies tailored to our customers

Like any small software development company that grows organically, LogiNet initially operated by developing an operational framework to guide project delivery in its early years. In the following years, the company applied this framework to project delivery. This was appropriate for the size, operations, and project types at the time, but as we grew, we increasingly felt the disadvantages of this approach. At the same time, new people joined the organisation, bringing their knowledge and skills to the table, which helped to adapt and tailor the project methodology somewhat, but did not change it significantly.

During this time, we increasingly found that the initial project flow methodology inherited from previous years was fraught with dangers and increasingly difficult to manage for the ever-growing LogiNet. For example, we started to realise that as the complexity and length of projects increased, it was no longer sustainable to specify the requirements in the first period, and then go away for 2-3 months to develop and come back with the result.

This involved quite high risks: it is difficult to describe a scope of this size so well that the software development aligns with what the client envisages. This was reflected in an increasing number of misunderstandings. It turned out that, although the functionality was in line with the specification, the customer had not quite imagined it. Such situations can be resolved by a large number of "CRs" (change requests), but it is difficult for the customer to accept investing in further rounds of changes. A similar difficulty, albeit in a different area, was that as project lead times increased, so did the development phase. This started to extend for several months.

Even then - 7-8 years ago - software development companies were already feverishly discussing how to move to agile software development. This topic came up frequently in our company and with the increasing prevalence of the above problems, we saw agile as a solution to our methodological issues. It was then that the decision was made that it was "now or never": we needed to change, to bring in new knowledge and new methodologies. Although a full agile transition was not a clear goal, we also used external consultants to learn about agility.

The whole process energised the team, with everyone throwing themselves into a transformation in the making with great enthusiasm. However, as we went deeper and deeper into it, we increasingly felt that at certain points the teams, the whole organisation, could not absorb any more change. We achieved some very positive partial results.

For example, it was then that we developed the methodological principle that we still use today of breaking down fixed scopes into smaller, coherent but more digestible chunks. These pieces are called iterations; they are about 2-3 weeks long and they follow one after the other. Essentially, we have created sprints, but not in as strict a framework as agility requires.

In addition, we found many other elements that helped the work a lot: the teams started the days with a short discussion, where they brought to the surface the tasks and problems they expected to face during the day. At the end of the iterations, we tried to have evaluation discussions on how the next iteration could be better. Essentially, we started to hold daily standups and retrospectives.

In addition to this, we found that the teams, and the project managers who lead them, were tailoring the software development process somewhat to their style. Some teams reported that they felt that daily task breakdowns were too resource-intensive in a given iteration, preferring to create 1.5-2 day tasks due to the complexity of the problems to be solved. Thus, they started to struggle with the fact that the daily standup only half-fulfilled its intended purpose, sometimes being a bit "meaningless".

In this and similar situations, we said that if we can keep the basic methodology despite this, but in this situation, the team only does a standup every two days, it might be fine. And that freedom and flexibility gave us another boost to our transformation.

This process led to the teams and the project manager being able to tailor the solution to the task at hand, to the environment. If at the beginning of development, the start-up tasks required a 4-week sprint, this was allowed. If the team held a standup every 2 days, we let it go. Anyone who has seen this transformation can predict what happened next: if we let it be a 2-day standup, what's the harm in having it every 4-5 days? If the initial sprint is 4 weeks, then it could be 6 weeks, followed by another 5 weeks.

Of course, these are extremes, but it could be seen that opening up the framework a bit wider gave room for individual actions. That's when we said that this is where we should stop. We had acquired a lot of valuable methods and knowledge of agility, but LogiNet at that time could not evolve in one step and we could not take away the flexibility of the system to adapt to projects and environments. This is how we created our hybrid solution from the waterfall and agile methodology elements we had previously used and newly learned.

These have started to solve our biggest problems: we get feedback from our customers quickly, monthly, on whether what we are doing is good. Of course, this introduced new problems: for example, we didn't only have to modify or improve features at the end of the project, but even after the first half of the development phase. It was a new experience for the team, but it also started to move our testing processes in a better direction, for example.

The demos for the customer were good feedback points and fitted very nicely with our idea of getting value for our work not only at the end of a long software development process but even during it.

It's been a few years since we laid the foundations for our hybrid methodology. We've gained a lot of experience with it, but we still feel that it's the one that works well for us. Of course, we are constantly refining it here and there. In fact, for some clients, it gets an extra agile backbone and looks more like agility than a hybrid methodology. Sometimes, of course, we still fall back on the old, classic waterfall methodology for smaller tasks or internal pilot projects. If chosen with due care, it can still work.

So overall, we can say that internal implementation projects in LogiNet always start from our hybrid methodology, but after getting to know the project and the circumstances better, we still don't rule out that a task should be done classically or shift significantly towards an agile development methodology. We always try to adapt to the project, the scope, the customer, and in general to the circumstances that surround the software development task at that moment. Our continuous refinement of software development methodologies allows us to stay flexible and responsive to the needs of each project, ensuring the highest quality outcomes.

The evolving landscape of software development methodologies demands constant attention and adaptation. By remaining committed to our hybrid approach, LogiNet can effectively balance structure and flexibility, delivering optimal results for our clients.