Kill the Dragon: The Thorny Path to Agile

A couple of years ago, we also enthusiastically set about switching to flexible development methodologies, and in a simple way: implement Agile. We hired external consultants, identified a piece of a large product for running in the process, and with enthusiasm we began to quickly and efficiently do it. They did, did, and then realized that some kind of nonsense is obtained, but not Agile, as in that joke about the secretary and 1000 characters. And everything seems to be great, they work as before, people are experienced, and the product works, but everything is somehow “not according to Agile”.



Team motivation has dropped. Customers are confused by the fact that the alleged "magic" dates do not come true, and generally declare that Agile has no place in a decent society. As a result, a small group of “Agile Transformers” sat down and brainstormed, why doesn’t it work out for us? Began to write out any restrictions that hinder us. There were a lot of them, and we called them dragons.



In any large company there is a mass of interdependencies between processes, products and teams. And the introduction of something new - in our case, the Agile methodology - requires the breaking of interfering connections and the revision of many processes. And without a clear understanding of what is bothering you and how to deal with it, all good and progressive undertakings are likely to be doomed to failure.

')

Already at that meeting at which we discussed what prevents us from reaching the cherished Agile, we came up with calling obstacles and hindrances “dragons” that need to be defeated. And they immediately registered the stages of victory over each of the lizards. It all started two years ago, and most of our dragons are already defeated, although a couple are still fluttering.







First of all, we need to clarify that in addition to Agile, in our large product, a waterfall development process was also used in parallel, which prevented us from introducing: first, there was an analytics stage, then development and testing stages. The problem is that when analysts are released, they switch to another task. And when developers or testers have difficulties, and they turn to analysts, then their heads are already occupied with completely different tasks, it is even difficult for them to remember what they did in the first stage. And the same could be said about any other unit, which at some point appeals to colleagues who performed the previous steps.



For each of the "dragons" we started a separate section in Jira, where a user story related to this dragon was entered. As soon as they all closed, the dragon was considered defeated.



One of the most harmful dragons in our case turned out to be fixed-sum contracts that we entered into with contractors. The invariability of the total amount of the contract implied that at some point the delivery of any changes in production could simply be frozen. That is, all prices were set once a long time ago, and since you are going to introduce some kind of Agile, no one guarantees a good end result, because the scope of work may increase, and the amount of the contract will not. We nailed this dragon first of all: we changed the principle of working with contractors, and we started buying not the final product or service, but the resources of the development teams, that is, we switched to iterative development with everyone.



The second dragon we took on is the lack of a GitFlow development process . Agile implies constant iterative changes, and instead of a normal GitFlow, we had a huge, slow three-five-month release, and then immediately in production. There was no end-to-end testing , no unit testing , there was not even unified test data. Everything was run manually, so the testing phase dragged on for an impermissibly long time. Immediately three dragons!



The difficult stage of breaking the usual "waterfall" began. We conducted GitFlow training, implemented branching rules optimal for the current release scheme, and then transferred to a new process developers and support services. As a result, today we have several different teams running several development branches, creating features, and we only infuse the functionality that is needed at the moment into the main branch. Here we also beat a couple of dragons along the way: we introduced the autotesting procedure, prepared test data for regression autotests, and began to apply unit testing. So instead of the huge three-month releases, we can now at least send the functionality to the master branch created in production at least every day, running the code through auto-testing. However, it cannot be said that the problem with auto-testing is solved completely, because there is such a criterion as coverage. But we strive for excellence.



I had to fight a dragon called " technical duty ". Perhaps the victory over him was the hardest for us. Before that, we didn’t understand what the debt was and how to work with it. In the past, people thought they could mess up, and then support would someday fix it. Now, no, I'm sorry, you have to take responsibility for your code. It was necessary to determine the rules for working with technical debt, to develop a checklist for reviewing the code, to debug the processes for working with the backlog of technical debt, and reviewing the code in teams.



Among the livestock of dragons, there was the inability to share knowledge and skills with colleagues. Someone did something - and ran on. Little attention was paid to the creation of detailed documentation, but at least just the transfer of sacred knowledge "word of mouth". To combat this dragon, we introduced the processes of exchange of experience between specialists within the divisions, established a weekly code review process in the Agile-team, launched regular comprehensive training and development activities for specialists.



But the dragons " transparency " and " CI / CD ", we still can not win. Although the situation is much better than two years ago, the victory is near.



What is meant by transparency? For example, the owner of the product receives a task from the customer and brings the team. Back from the team, he brings the customer time, understanding, implementation. Such a link in the absence of a project manager. And until now, customers have a poor understanding of how to manage, say, terms.



At the same time, the team did not always understand the business value of the product, what customers want to achieve. Performers and customers almost did not communicate. At the same time, the customers depend on the deadlines for KPIs, the success of achieving some goals, and the performers did not understand the value and role of the code supplied by them in the project. Especially if there are several teams, and they work in parallel. We are trying to defeat this dragon with the help of various synchronization events, often arrange meetings between the performers and customers. This helps motivate teams, but the dragon is still breathing. And all together it is called “Ensuring transparency from both the top and the bottom.”



As for CI / CD, we set up notifications of any problems during testing, entered release categories and developed checklists for each of them, implemented the ability to deploy any code branch in any environment, fully automated rolling out in production.

What about Agile?

Everything is fine with him, he is working, and now we are scaling to the entire company, taking SAFe as the basis. We already have cross-product teams, which greatly increases the complexity, and also because of this, new dragons appear, which have to be stifled together. We have even settled an internal corporate name for meetings where various difficulties and ways to overcome them are discussed - “to kill dragons”. The term caught on those teams that do not work on Agile. Everything that interferes with work began to be called dragons, implying that they must be fought. There was a curious case when one of the employees recorded in his working report: he killed dragons. That is, he was present at the discussion of the current situation and further steps. His boss read, “well, well done,” but when the report went through lawyers-financiers and methodologists, they came to the chief and asked if everything was alright if we moisten dragons during working hours.



I had to talk about the difficult everyday life of fighters with winged reptiles.