Audrys Kažukauskas, Chief Director of Technologies, HomeToGo
The past two decades in the software development industry have seen many changes. Younger colleagues hardly know that for a long time programmers worked much like construction workers, except that they did not carry bricks. They, however, tried to manage projects similarly to those on the construction site. It took quite a few years before everyone realised how unproductive this was and started applying now widely known Agile project management methods. Today, however, even this approach is no longer sufficient as it is necessary to be faster and more efficient.
How about those construction site practices at the computer desk?
Let’s start with a historical flash-back. Previously there was a dominant belief that a programmer was essentially a builder, except that its building material was code. As a result, project management methods applied in construction sites were used in programming. Analysts first obtained all the details about the customer’s requirements. These were then taken over by system architects who prepared the final technical plan of the Subsequently, programmers had to follow the plan and write a code, and testers had to test if everything was operating as required.
Sounds reasonable and correct. In reality, however, the situation was slightly different. It is no secret that customers were not able to provide their requirements accurately. There is nothing wrong with it – it is difficult to plan everything in advance. It is often the case that in the course of programming the need for different or additional functions occurs. When the programming starts you can see whether the plan prepared by the architects works. In many cases it did not quite work. This became apparent several months after the initial order of the customer. Naturally, projects were delayed and customers received the software which often met their needs only partially. In order to improve programming, better planning was promoted – the process was perfect, except that we did not plan everything in advance! Today this sounds like a joke.
And then there was stress. At the start of a project everybody was calm because the deadline was far away. Tension grew in the programming phase and culminated during testing. If the team managed to get to this phase that is. Programmers blamed the architects for poor plans, architects blamed programmers that they were unable to implement their excellent plans or analysts that they prepared the wrong requirements. There are many programmers who remember these work methods with regret.
Virtual bricks replaced with agile processes
Programmers had enough of the construction site practices at work and started looking for new working methods. As a result of their efforts, the new work organisation methods known by their generic name ‘Agile’ (agile – able to move quickly and easily) soon became widespread.
The supporters of this movement eliminated all building site practices from their work and did not seek to plan everything to the detail in advance and then implement the grand plan all at once. They prefered to divide the entire project into small stages (iterations) and plan and implement the closest iteration. Thus in a few weeks’ time the customer is able to test the first version of the software and make the desired corrections. In this way the software is developed steadily week after week in the direction desired by the customer.
This movement gave rise to several work organisation methods based on the new philosophy, such as Extreme Programming, Scrum, and Kanban. Today no successful technology company can do without some of these methods or a combination thereof.
Today one method is not enough
The largest holiday home search platform in the world HomeToGo, proudly developed by us, is no exception. You will not find construction site practices here – we operate under our own, hybrid Agile model. It is based on Extreme Programming and focuses on increasing the work efficiency of the programmer. We manage projects on the basis of Scrum and Kanban methods, and we measure our objectives and progress based on Google’s OKR. In increasing our efficiency we heavily rely on the Lean principles – we often review our processes and tools and discard those which are superfluous or of little benefit.
Although artificial intelligence will not replace programmers in the near future, today we can and try to automate many of our practices. This helps avoid human errors, saves time and allows us to evaluate the results of our work faster. For example, we have a lot of automated system tests which are automatically launched after each modification of the programme code. We automate everything that is practically possible and worthwhile, starting from the preparation of reports, launching new servers, all through to one touch software installation.
It is true that automation alone will not solve everything – it will immediately assess and show what does not work, but it will not teach you. It is therefore very important that more experienced colleagues who can see that a member of the team has opted for an inefficient solution would point this out and advise. This allows for quicker improvement and better solutions. At HomeToGo we encourage not only such personal mentorship, but also internal practical training.
But there are limitations here too
After the company masters the said Agile methods and practices, product managers can clearly see the work progress and quickly change priorities, while programmers can without any stress successfully implement the customers’ ideas. Sounds perfect, but there are limitations even in applying such methods. Again, due to human factor.
All methods mentioned above in this article are based on the premise that the product manager always knows what must be created, that all set priorities are correct and all solutions are beneficial. Unfortunately, during more than 15 years in the technology sector I have not come across such a product manager.
We are working in the reality where product managers or customers often do not know whether the given tasks will actually produce the desired result. They know the objective really well, but cannot always plan effective steps to achieve it. More frequently they set their priorities based on the benefits that can be measured only after completing the work. If mistakes are made in measuring the benefits, no efficient work will be done even by top-class programmers. The perfect work accomplished by programmers will simply not quite result in desired benefits.
So again, just like in the building site practices we reach new limits which hide huge potential for improvement of work efficiency. Only this time, it is not programmers, but product managers who need help. At HomeToGo we have for some time applied the Lean Startup method, which helps product managers create services required by the market, rather than the services which they think are required.
