Libor Besenyi (CTO)
Yes, Agile works. This article was not intended as a presentation of yet another success story, but rather a pragmatic evaluation of changes that were not implemented for us to "be more agile" - as is the current trend.
The strengths of Agile, in our eyes are:
- The ability to adapt to the volatile environmnet (or, if desired, reducing cost of frequent change management)
- It is a customer-oriented model (IT centric model is replaced by an business centric model)
Therefore, if we are not satisfied with the current state of the software department but the aforementioned points are only secondary, Agile is not the answer to our problem. The modern mantra that Agile will sort everything is a rather simplistic perception of the world of development.
It is best to fail as soon as possible!
The main idea of the first point lies in the economics of failure. In the economic point of view, it is really best to fail as soon as possible, however... In an article for the server Quara, Curtis Poe beautifully described the situation that when we have a project such as a nuclear reactor (clear characteristics of a project), it is foolishness to use the model of early failure, isn't it? So it depends on situation.
Our situation
Let’s take a closer look at the situation that we dealt with. KPI efficiency was measured as the ratio of hours worked to the number of releases. This metric suited the constellation in our company (method of work, project type or system architecture). This statistic proved a suitable tool for measuring process changes, as it immediately identified the problem in the first bigger process changes at the turn of 2013 - 14:
Pic: Efficiency growth
These changes were in formalisation and reduction of agility in the development process. In 2015, after doubling the team we started returning to more agile management.
Agile is not for developers, it is for business
During one of the last successful Agile projects, the business department stated that the IT finally provided a software that the businessmen wanted to sell. Some developers were confused by this statement "but it does almost the same as its preceding version, so what's the difference?". The difference was in managing the expectations of users (by including them in development process) and small ideas that improved the previous solution. No crazy algorithms OR design patterns were implemented, the code was 90% unchanged, yet the result was different.
Gradually, we have come to the myth that Agile is a framework preferred by IT departments. We cannot confirm this view. Any change is preceded by a wave of resistance. But the one that came from developers and testers was astonishing.
Losing certainty, documentation etc., it puts pressure on the ability of reasoning and frequent discussions. This is not a simple issue in the world of IT. However, it has a positive effect. We actually witnessed people grow personally.
And as for the reasons how we managed to introduce Agile?
Agile has been used at a level higher than project management. Our program management is essentially managed by Kanban board, which brought considerable business freedom. About that, however, we will talk next time.
read more
