Like any small company that grows organically, LogiNet initially operated by developing some kind of operational framework to guide project delivery in its early years and 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. At the same time, new people joined the organisation, bringing their own knowledge and skills to the table, which helped to adapt and tailor the project methodology somewhat, but did not change it in any significant way.

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

This involved quite high risks: it is difficult to describe a scope of this size so well that the software that is developed is the software that the client envisaged. 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 to invest 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 was starting to reach timescales of several months.

Even then - 7-8 years ago - software development companies were already feverishly discussing how to move to agile. 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 problems. It was then that the decision was made that it was "now or never": we obviously 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 have achieved some very positive partial results.

It was then, for example, 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, the project managers who lead them, were tailoring the development process somewhat to their own 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".

And 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, 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 left. If the team held a standup every 2 days, we let it go. And anyone who has seen this transformation can predict what happened next: if we let it be a 2-day stadup, 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 own 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, on a monthly basis, 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 development process, but even during it.

It's been a few years since we laid the foundations for our own hybrid methodology. We've gained a lot of experience with it, but we still feel that it's the one that works really 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 own 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 in the classic way 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.