Ten years ago, a young project manager had a successful experience in implementing something similar to Scrum in one of the insurance companies. There is more than enough enthusiasm. Colleagues from the tech department strongly supported me. The developer's background was helpful too. But at some point, an impenetrable wall appeared: the Agile approach worked inside IT, but it did not work outside. It needed synchronization with other departments and a change in the way the company worked. A full transition did not happen, but a year ago, it was possible to implement Agile transformation on another project in a financial organization with more than 100 people. Is this possible?

Table of contents
1. Issues
1.1 Culture in the countries
1.2 Culture in the cities
1.3 Culture in companies
1.4 Tech teams
1.5 Business teams
1.6 Managers
1.7 People
1.8 Summary of the issue and culture

2. A bit of theory
2.1 What frameworks are there for Agile company transformations?
2.2 SAFe, and is it safe?
2.3 LeSS, and how less?
2.4 DaD or a good dad?
2.5 Brief Summary of Theory

3. Agile for the whole company in practice
3.1 Team Building
3.2 PI planning
3.3 Business teams
3.4 Differences in teams and approaches
3.5 Paradigm shift

4. Unresolved problems and solutions
4.1 The rate of change of people
4.2 Passive managers
4.3 Fast and high quality, but expensive
4.4 Framework for a comfortable life for tech cats
4.5 Formalism must also be accelerated
4.6 Regional
4.7 Cultural codes and presence magic
5. Light at the end of the tunnel

Before sharing my experience with Agile in a large company, I would like to talk about problems and a few words about theory.

Issues

Agile is not a framework or a set of rules. Agile is a culture. To implement Agile necessary to change the picture of the world of more than one person. It sounds scary, but let's sort this concept a bit. With each part, it is easier to work. To begin understanding in different countries and cities, we talk about culture in a team.

Culture in the countries

When we talk about countries, images and stamps appear to each of us. I'm not going into the details of the lectures on the humanities, but as applied to tech, cultural codes working in one part of the world may differ. There are states with post-Soviet ideology. Also is a «melting pot» in the form of emigrant places, such as the USA, Australia, New Zealand. And are many other beautiful, unique areas on Earth. When it takes the principle of the Agile manifesto, it works differently in different parts of the world. Within one country, there may be a different understanding. For example, the English word «privacy» is not used in the Russian-speaking space. But in the Western world, laws, courts, corporate rules work for this term.

Understanding the country's culture gives a great advantage, how to come from point A to Agile. Or why this cannot be done quickly.

Culture in the cities

In order not to be verbose, consider the culture in a big and small city. The rhythm of life, the understanding of time, the attitude towards agreements, all this differs in different places: somewhere it is large-scale, but it can be unimportant. If somebody comes from a vast stone jungle to a cozy and unhurried province, then it feels a different understanding of time, attitude to work, money, values. In a word, it is impossible to neglect the fact that cities are different. I remember when I arrived in Saratov, I was surprised how the number of people does not affect the excellent condition of the tech market. In a small region, there was the competition and foreign customers and work for large regional companies. All in one: West, East, and the public sector. But this does not mean every point on the map with 800 thousand of the population is also developed in tech. Saratov is the exception rather than the rule. Many examples of excellent tech industries can be found in the post-Soviet space, where there is no big state money, and there are no petrodollars.

Culture in companies

"… Foreign companies are right, but domestic ones are not...". Unfortunately, or fortunately, this is not the case either. Companies are different: transnational, industry, and others. Understanding the organization and how it makes money can quickly help to achieve a goal. For example, there is a startup office in a big city that follows Western values and a culture of entrepreneurship. Simultaneously, somewhere in New York, a conservative and clumsy financial organization may exist, which seems to be a regulated echo of the past for a medium-sized firm in post-Soviet countries. In my case, I worked in Russia in a company with British processes (audits, training, and others). Many people had pro-Western thinking. It is crisp: without leaving the country, it was possible to work in a completely different culture. My current project is a technology giant and a recognized tech leader in the world. To my amazement, I saw that the Scrum was only beginning to break through strict rules and culture. The main principle of the corporation for the current project is: «everything is own — from tools to processes».

In general, Agile approaches cannot be in the strict rules of any framework. A pragmatic way to understand a place is to write their resume for each company rather than using stamps and labels. Patterns in our heads help, but often simplify where it is not needed.

IT teams

When we talk about tech specialists, it's often intellectuals. Everything is in its field, but it is challenging to meet those who are engaged in heavy physical labor among the tech departments. Although one cannot do without «strong programmers» when it is necessary to help transfer boxes with gifts and provisions for the New Year corporate party, we are not talking about that.

Speaking of culture in teams, we need to consider each participant. A few examples that I met: two programmers from the same Asian province went to dinner together, but it was fierce competition in work. And most importantly, for no particular reason: exhausting code reviews, reluctance to share knowledge and practice. This behavior does not fit the Agile framework.

Another case: Indian culture and attitude to error. It happens that colleagues who just arrived from India blame everyone, but they never admit their miscalculation. Such behavior is a severe test if the team needs to find out the exact cause of failure. Of course, such a cultural moment can be smoothed out, but not quickly. Even at the bank, when I was interested in incorrect informing, they answered that I did not know the procedure for working with credit cards, and the oversight in the application would be corrected later.

Well, it's close to Soviet culture — to say what he thinks, to be very straight forward or send a person to learn the material and theory before sharing any opinion.

All of the above must be taken into account and used to achieve the result. Additionally, we can say that the teams within the company may differ. Even more, on the same project with a particular set of teams, a perpendicular view of the theory and practice of the framework is possible. Agile says this is normal. Strict rules are not so supportive.

Business teams

It is difficult to describe in one sentence who the business teams are. The sales team is not interested in new approaches or how often the development methodology is applied. Financiers carefully consider budgets and the effectiveness of invested money. The operators do not understand that the architecture is «bad», but if it needs another 20 software engineers to support the solution to launch the product, this raises questions and clarifications. Teams outside of tech are skeptical of sprints, iterations, and other incremental things. More understandable motivators: quarterly awards, accounting, KPI for sales. Often a business operates on due date (deadline). We do not go down to the discussion about the predictability of «time for done» and tech creative nature. Nevertheless, understanding the needs of the business makes it possible to build a work process that will be useful to all interested parties more accurately.

I would also like to mention politics. The more interaction with business and the higher the level of the hierarchy, the more intrigues and «undercover games.» From my experience, I remember the following phrases: «We want to show progress to investors, and it doesn't matter the number of tasks completed during the sprint,» «What have tech been doing all these 2 weeks, really couldn't do a little more than what we asked?», «Let's take up these five tasks at the same time, and we'll increase the sprint a little.»

Managers

There are heads, directors, project and program managers, as well as product owners. And this is not a complete list of different interpretations of those who make the decision. One of the factors for changing the organization's culture is the restructuring of the top management work. And here we are not talking about rewriting the charter and the formal renaming of summarizing as a «retrospective», but about how managers understand their role. An innocuous example is an experienced manager who does not interfere with the deployment of the Agile framework but is not 100% involved. This approach does not work since the leader must be a judge, a catalyst, or even a driver of innovations. By itself, life does not work. It takes effort and maintenance of a process, method, or culture. This statement is true for Agile thinking. Another example: a tyrannical management style in a western firm. When the boss has left, discipline in the company falls, which affects profitability.

People

Engineers implement programs, artists paint paintings, developers build skyscrapers. We are all different. Also, everyone has personal experience, critical thinking, and a unique vision of theory and practice. Besides, we are also variable in time. We forget discussions a week ago or something from the past (Mandela effect). People make mistakes, and we are dependent on the weather and others. Someone does a lot, and quickly, others create little, but it is critical for the team. Being in the same team, we gain something in common and believe in similar ideals. We bring our experience to each project, enriching the colleagues' skills and practices with whom we work. All this is another additional great difficulty for introducing a new approach. Sometimes it's much easier to take a student and retrain for work in the company than to hire a professional and try to «refrain» to corporate standards. Someone continues to study until old age, and some stop at 25 and continue to work «on reflexes.» Others always rely on intuition. People are an extraordinary phenomenon in terms of development and learning. It is not about the computer: the engineer said, and the machine adopted the new framework without interpretation. The person has the first derivative or variation on the theory, personal experience, and how it develops in a particular team.

A brief summary of the issue and culture

I tried only to cover a little the components that need to be considered when building Agile in an organization. According to the above, the methodology or framework should consider the difference between countries, cities, companies, teams, and people. Those who introduce new thinking are required to imagine the amount of effort. Human communication is more critical than development tools, databases, and other components. It finds different assessments of «retraining» or personality formation if going a little deeper into psychology. This process can last from several years of daily work with a person. It is achievable when we spend most of our lives in the company. But such a transition certainly cannot take place in 1-2 days or even 1-2 months. Change is needed throughout the organization over a great time.

A bit of theory

I must say right away that I included this section to help those who are considering or exploring the implementation of Agile in companies. If you have familiar with the frameworks below, feel free to skip to the essence of the article: the practice of using Agile transformation in a company of 6,000 people.

What are the frameworks for Agile company transformations?

As I mentioned at the beginning of the article, one of the problems of restructuring thinking from directive to flexible is the widespread implementation of Agile practices. That is not only about using Scrum in a specific tech team but the change of all departments, including the work of the director of the company, to «new tracks». There are several solutions.

SAFe and is it safe?

Thanks to boblenin for the short digression about the framework. When I first came across SAFe, an article with photos and an easy explanation that SAFe was useful. Special thanks to rsn81. In short, SAFe is about introducing Agile approaches not only in the teams but throughout the organization.

LeSS and how less?

In addition to SAFe, there are other approaches. The second example is LeSS, with an ideology of minimalism. The general idea is fewer rules and focuses on using team expertise. Sounds interesting given the differences in cultures, knowledge, and understanding. Thanks to myIDddv for covering this approach .

DaD or good dad?

It is another version of Agile transformation with the difference in a pragmatic approach and redistribution of roles. The framework does not follow a strict philosophy, but at the practical level, it implements practices that have been tested in various companies. It sounds understandable, but organizations are different, and what works in one place may not works in other conditions. To everyone who is interested, I suggest looking here . If there are authors who have had experience or implementations on this methodology, please leave the comments.

Summary of theory

I gave three possible scenarios for changing a company. They could or already have a lot more. The main idea is a brief digression that there are many frameworks, opinions, and practical cases for transformation at the company level. My path is one of the possible. Next, I will talk about the implementation of Agile in a large company using SAFe as an example.

Agile for the whole company in practice

Well, we got to the point. A couple of years ago, I participated in an Agile transformation project for a state-owned insurance company. It was necessary from a clumsy bureaucratic machine to make an easy and understandable structure that would meet all the needs of the organization.

This transition was followed by a large number of problems and numerous complaints from the business towards IT. As a result, a change in tech leadership. New people came with the bright idea that «everything will be fast and fashionable.» It was forbidden to use technical assignments and documents, since this is an «old and inconvenient format» and «not by Agile». It was necessary to create a new structure for the entire company's work: from tech teams to business as well. The state was attended by Agile coaches who implemented, taught, and helped at all stages.

My role as a project manager was to assemble, train, and help two new teams understand the Scrum and integrate all of this into SAFe. The programmers included database and visual interface programmers (front and back) from the structure. An analyst assisted each group of developers in collecting requirements and communicating with the business. There were testers. I need to «grow» scrum masters within teams.

Team Building

I'll tell a little more about the formation of groups. Unfortunately, I did not participate in the process of selecting and interviewing people. I was given ready-made teams with the statement of the problem: to train, tune and release to «free swimming». Groups tried to collect on a geographical basis. Mostly each team was located in their city. One of the teams sat together. The second was in different offices, but close enough.

Before starting work, I spoke with everyone personally to form my personal opinion. I had a detailed summary of the guys, but the pieces of paper and the passage of the interview is not the main thing. At the first conversation, I tried to understand more about a person: extraversion, leadership, how he imagines Agile, and a flexible development methodology, whether he had experienced in the past. Based on this information, I managed to single out the scrum-masters and understand how to go from point A to Agile. For someone, the new framework was the first time. Someone had their experience. Of course, some skeptics criticized everything that happened.

PI planning

The first meeting of all the teams took place on PI planning. This is a two-day event when about 100 people gathered from different places. A very crowded event by corporate standards, given the fact that the entire business was added to the teams. If desired, it was possible to solve any issue from the details of a specific task, to architecture. Including there were many experts on areas or those who have already solved a similar problem.

Teams gathered in a large hall, each at its table. Thanks to the organizers who provided the equipment: stationery, badges, boards, and many other inconspicuous little things that help in the work. Passing by each table, details quickly opened: name and composition, board with planned tasks, risks. The potential usefulness of the team was obvious and how colleagues can help. This is important for the exchange of information between participants in the event (train). It simplifies the search for an expert or developer who was involved in the same task in the past. Looking ahead, I want to note that the teams did not seek to exchange information or help others.

Moreover, someone hid the experience that he possessed or openly interfered with his silence. The motives for this behavior are pure: not to get an additional task, not to lose the developer in the team, and other fears of the past. Despite the favorable conditions created for the implementation of SAFe, the framework slowed down in some places. Below I will dwell on all the problematic issues and how to solve them.

Business teams

One of the significant advantages of planning was that the business was present throughout the event. Detailing of tasks occurred instantly. Problems that did not bring profit to the company were quickly identified. Many tasks surfaced that were added as a result of political intrigues, but far from achieving firm performance. Such statements improved the work of a particular person, while the department could continue to «fire» or the product could not be profitable. I want to note a fresh attempt to implement KPI and OKR. They took practices that proved to be excellent in the West and tried to adapt to the new reality. For tech and business, it was the right vector of aspiration in one direction. By the time the structure was introduced, the client was hungry to be asked. When the teams became interested in «what is needed for sales», the colleagues gladly shared all the details and problems that prevent them from achieving goals. This helped to focus correctly on the task. In the past, analysts introduced how it would work. There were no comments, no opinions — that's it. But for some reason, there was no moment of feedback from the customers themselves. People are always happy to share their needs and pains. A separate issue is to recognize the problems and transform them into an obvious statement and implementation.

When interacting with business, politics were present. As I mentioned, some tried to «push through» their task bypassing the agreed list. We also tried to overstate profitability indicators to increase priority. Someone did not understand the essence of what was happening and, out of old habit, wanted to «catch the thoughts of management», instead of preparing a financial justification for posing or fixing risks that could interfere with the task.

It used to be like walking in a minefield, but it was the right vector for the unity of tech and business with the ability to hear and speak to all interested parties.

Differences in teams and approaches

PI planners had their understanding of SAFe. The same practices were perceived differently. SAFe is flexible in terms of supporting variations. For example, there was an opportunity for each team to create its development cycle and online boards for tracking tasks. Someone added columns «Code Review» and others, while others did more simpler «Open», «In Progress», «Done».

Another difference: the criteria for completing a task (Definition of Done). The team had the opportunity to develop their level of detail. Someone added an item for delivering products to the production environment, others used the model easier since they created only prototypes.

In the style of scrum-masters, differences were also traced. There was full involvement, sometimes excessive. There were examples when the coordinators did not participate in the team processes at all. Someone patronized the children from external influences so that the participants were «in a vacuum» and had little idea of what was happening outside (the «train»).

Paradigm shift

One of the advantages of the project was that the director of the company attended the opening speech and PI planning opening. According to the experience of conducting past events, it was a case when the director went around the boards. He declined plans of tasks 3-4 hours before the end of the planning. He did not find any usefulness in what was going to be realized. Teams had to re-plan, discuss, identify requirements.
On the other hand, the correct and timely signal saved the company money. In other conditions, everything could have happened sadder. The team would have spent 1-2 months of its work and would have already had to lose more. Such examples catastrophically affect the team's motivation and, as a consequence, the company's profitability.

It is not known whether the director changed his management style due to the new approach. But for the head of the organization, it was a pragmatic move to use new methodologies to achieve profitability and other indicators. An additional plus is a clear way to report to investors.

A paradigm shift for groups was hard. Many worked for years «over a waterfall», others used them «Scrum, but...». Still others tried to find a «strong shoulder.» It was curious when the dedicated testing teams continued to work «the old fashioned way» with semi-annual releases, with well-established long-running processes. And here the speed of change came such that it was hard to imagine. 25 teams simultaneously began to enter the code and deliver it to the production. Teams started to push the code every month or even more often. The same was true for the business team. If earlier they had six months to teach, tell and use, then, under the changed conditions, «the ball was on their side». The business has become a «bottleneck» in the company's profitability. Moreover, a month later a new batch of changes gone to the production environment. This was a strength test.

Summing up, I did not see that teams and businesses became simultaneously flexible in everything. But when I laid out Agile and culture, it was evident that this change took years. People should want to «live a new life.» It does not happen overnight. It is possible to play with flexibility at work, but when returning home, go to the store or come across another picture of the world in the post office, hospital, it's hard to let the sprouts of Agile culture grow quickly and without stopping. Plus, inertia can be added to all this. The more new information we know, the less susceptible to new information. Flexibility is about finding perfection, even when everything is going well and error-free.

Unresolved issues and solutions

The rate of change of people

One of the main reasons why some process is slowed down or does not give the expected results is people. When implementing SAFe, they worked a lot with the participants. But there was no individual system of education and training. High stress resulted in clinical cases. Moreover, we are talking about psychological disorders and a general aggravation of nervous health. Not everyone can withstand a 2-day event with many people, where needs to interact a lot. Someone is not ready for the intense pace of work for 1-2 months. There was a noticeable «failure» in the theory and understanding of Agile approaches. General conclusion: SAFe is not for everyone. Proceeding from this, it is necessary to select people for positions where it is critically important to exchange information (extroverts of a scrum master, a business open to communication, and not under pressure pretending to be something unclear). If the task is to implement Agile in a conservative organization, it will most likely not work out quickly. It is more realistic to imagine this as an evolutionary process, where an impressive work has been carried out to educate people for several years. One way to solve the problem is to form a team to meet the needs of Agile initially.

Passive executives

Managers at all levels are a critical element of success. If at the level of the CEO, there is understanding and real steps towards the implementation of Agile, then this may not be the case for managers on low level. Ideally, a team of leaders is an ally at all stages. Naturally, we mean not formal or declarative Agile follower, but practical steps to maintain agility. New frameworks «can not stand» the competition before the old management methods when it comes to maintaining profit, health, and people's lives. The unspoken is floating in the air «You can play your games, but if there is no money or serious problems appear, we will immediately return to project management.» Considerable attention needs to be paid to recruitment and individual training. Simple psychological tests can give a more objective assessment of leaders than performance-wise and statistics.

Fast and high quality, but expensive

Business teams should be formed, taking into account active interaction within the organization. If the manager closes the plan (for sales, postings, reporting, and others), then everything is no longer of interest to him. Without close communication between tech and other departments of the company, success is impossible. A typical situation when a colleague made a sales plan, received a premium for the quarter, and quit. And the operators and the tech department need to work because at stake is profit, reputation, and more. Everyone should understand the golden rule of three: quality, time, money. It is possible to sell «we need to work fast as soon as possible» or «let's hurry up team», but the ratio of factors will remain unchanged. It seems to be a typical example, but there are still confirmations of a complete misunderstanding of the basics. A quick way to explain is the analogy of shopping in a store. If there is a fixed amount, it receives a strictly defined set of products. It is possible to play with quality and quantity, but the proportion remains unchanged. In my practice, many questions will disappear on their own.

Framework for a comfortable life for tech cats

IT teams are not ready for active communication. During SAFe, I met such expectations: «give the task with detail document, then we will realize it.» Maybe I'm wrong, but flexibility requires a constant search for ways to improve the quality, volume of work performed, and openness to different settings. In other words, the task can come in a large document or as a pair of lines in an excel file. It is necessary to be prepared for any method. Another example is the versatility of a team. Many do not perceive the expansion of responsibility in one direction or another. Everyone draws a circle of responsibilities for themselves and their colleagues. And then they demand compliance with their template. It is not correct. Tasks do not come evenly; each workload is also not ideal. More flexible and normal, when the tester is 15% programmer or developer, besides compiling on his machine, he also does an initial functional check on another environment (what is this happening !?) In my practice, it happened when the analyst forgot about duties and helped the tester, since fire before the release. There will be no instant solution. It's convenient for people to live and work «in frames». Perhaps the constant expansion of the comfort zone will affect the desire to help. For the scrum master, it necessary additionally monitor the loading of each in the team. As a result, this will positively affect the psychological climate in the team.

Formalism also needs to be accelerated

It's hard to launch a new approach in the company and stay in the «old skin». For example, there was the active use of the functional in business in a production environment, and suddenly, a «retroactive» order comes to start product development.

From life: the person very much wanted to be a director: were bought a suit and changed signature in the mail, but in reality, the new director didn't have a responsibility and subordinates.

As a team, work approaches have changed, but departments' formal names, staffing, and salaries have remained the same. For people, the title is essential, the level of compensation of efforts, belonging to a hierarchical structure. When implementing Agile, one cannot do without a good answer from formal points.

Regional

For 2 days, guys from different places gather in a large hall. But after all, they leave for their home. On the one hand, person are working on new practices and creating a healthy psychological climate, on the other hand, team member live in a place where possible to be punish for «wrong look or an awkward word „Originally I am from Siberia and am amazed how over the years nothing has changed in my hometown. If your project have a budget, it's wiser to recruit a team or transport everyone to one place. If there is no possibility, then there will be risks. In my practice, there were two examples when talented programmers went into the wildest binges and unconsciousness. The environment in which a person is an outside work affects.

Cultural codes and presence magic

I work on a project where there is an intersection at the level of 3-4 countries: America, Europe, Asia. Also, California itself is multinational. There are cultural codes from all over the planet. It need to work and take this into account. How? Extended introductory conversations on the dealers, off-topic correspondence, training, forums. Best conversations over tea with colleagues and exchange of experience.

I remember the phrases “remote mode» was tempting. Immediately presented palm trees and the beach. After 3 months in the crypto nomad mode, I realized all the pros and cons. For unity, full-time contact is needed. The magic of presence works on hackathons, in offices and cafes. But harder to achieve this remotely. Scientists have found a part of the brain that is activated by the physical presence of other teammates. This explains why the presence of someone nearby accelerates the problem's solution compared to doing it yourself.

Just a little more science: 80% of all information a person receives non-verbally: sitting position, kind and quality of smile, the position of hands, and others. When phoning without face-to-face contact, one does not understand what a colleague has in mind. Perhaps in the future, a hologram and tactile technology will close this gap. In the meantime, it's better to work together in the same office.

Light at the end of the tunnel

Updating frameworks are fast and come up with new ones in parallel. Certification companies and a whole business appear on this subject. Napkin and pencil appeared at the beginning, and they can be integrated into new development approaches. Moreover, the absence of a requirements document does not mean that it does not need to be prepared after implementation. Going deeper into the theory, the division of the world into two parts is noticeable: planned and variable. Nowadays, each of them come up with new marketing names, but 10, 20, and 30 years ago, there were followers of the rules and those who adapted to the changes. New ideas may turn out to be a recycling of past practices. Do not become part of a camp. It is better to use what is suitable for a specific project and company.

We went over the aspects that must be considered when changing thinking at the organization level. Dry answer to the question: «Is Agile possible for the whole company?» «Yes,» but with a lot of but. These «buts» will hide the process of changing a person's thinking, organization structure, choosing a city, office, or even changing a country for the entire company. If this is not taken into account, then much energy can be spent on a change that is beyond the power of states. If to choose the right place and team, then success will be in the pocket. It will not need to punch the wall where it has a broad cross-section. Perhaps this is the answer to why many organizations create the right atmosphere within the company. A person is in an ecosystem: a favorite business, leisure, relaxation, hobbies, acquaintances, friends — everything is connected with work. This is one of the possible ways when a microworld is created, and efforts are not spent on changes in cities, countries, and continents.