About changing a company with hundreds of thousands of employees
About 300,000 people work at Sberbank, which makes it larger than any government ministry. Managing change is hard in any situation, even on a small scale. So how do you introduce changes and monitor them in a huge Leviathan like Sberbank? John Cotter, a professor at Harvard Business School, describes eight steps that let you change anything. If you understand how change works, you can scale it up with no problem.
Engineers are usually introverts. If we make something great, we think that it’s obvious to everyone how terrific it is. We don’t think about how people will find out about it and begin to use it. That’s what killed a lot of good IT solutions.
When you are planning any kind of change, the most important thing is to know who is going to be the conductor of your ideas. Employees should find out about innovations from people they trust. If possible, those conductors should be included in the process of creating the new system — so they can tell the developers which tools they need, give feedback, and help make decisions. People should take part in change, not find out by being hit over the head with it.
About IT companies with a bank in the back office
In all of Herman Gref’s talks, he always says that traditional banking is dead. We want to be an IT company with a bank in the back office, and that requires major structural changes. In the past we had the usual departments, what are called functional teams. People with the same specialty worked in each department— departments of development, analysis, sales, client contracts, bookkeeping and so on. Now we want everyone to move into small teams that each have a full chain of specialists who can put together a finished product for the client. This is one of the main changes that has taken place at Sberbank in the past year.
In the past, computer programs were developed by the traditional model: product managers come to you with all their needs described in maximum detail, signed a work specification order and sent it off to be developed. For the work itself you had to determine who would do what and earmark the necessary resources. In every subdivision– analysis, development, testing – you’d determine percentage of time for each task, for example – Petrov, 10 percent; Ivanov, 20 percent, and so on. After six months you begin testing so you can deliver the program, and then it turns out that it’s all wrong. They say, “But I asked for something completely different”! The developers say that they worked strictly by the work specification order. Everyone starts fighting and examining the work order to figure out who meant what.
Today it’s obvious that all of those 10 and 20 percentages of work aren’t efficient, because people are constantly switching from one task to another and they have no sense of ownership of the result. We put more people on the product team: now the developer, analyst, tester and person who commissioned the program are working together. This is a permanent team that has gotten used to working together. They are tight-knit, motivated, and all totally responsible for the result. Now in this new system, the task is done a bit differently. People still ask about all the requirements, but the end users don’t describe them in detail. They make a list of the most important ones and prioritize them. Then they work together with the developers. About every two weeks they sit down together to review the priorities and list in detail all the requirements that can be done in two weeks. As soon as that task is done, everyone sees it right away. The users make sure that it all looks the way it should on the screen and that it’s easy to work with. As soon as they approve those parts of the product, they are put into operation.
In this way you have a system that is ready and operating when you want it, a system that was done with you and in response to your needs, and not something based on how some programmer understood your work order. This is incremental work – that is, working in small operations. And as a result of each of those operations, the product acquires new capabilities and useful functions.
Right now, 2,000 teams of about ten people are developing bank software. Most of the programmers work in Moscow, although there are also major centers in St. Petersburg, Novosibirsk, and other cities.
As soon as the development of software began, people began to dream up methods to conveniently track the work. In the mid-1990s Jeff Sutherland and Ken Schwaber wrote the “Scrum Guides”. The word “scrum” comes from rugby. It’s the moment when the whole team is completely concentrating on the ball. In Scrum they recommend that a team of five to seven people develop an IT product. The team would include the person who commissions the product and knows the market and client, and who can describe the requirements; developers who create the product; and the so-called scrum master — the person who helps the team stay on track and come to agreements.
The team works in sprints. Each sprint begins with a plan: what’s the goal of the sprint and what requirements must it satisfy? Then every day the team has a short meeting — literally 10-15 minutes — where they discuss how the day went and determine if someone needs assistance. At the end of the sprint they analyze it, show the results, get feedback and decide what could be done better. The constant transparency, review of what we’re doing and how we’re doing, and the constant development make for a much stronger team and a better product. The authors of scrum went on to become some of the creators of the agile system.
About becoming agile
The word “agile” appeared in 2001 when 17 prominent IT professionals took a ski trip to discuss their experience. “We’ve done a ton of IT projects. Let’s think about what helped make them successful”. They wrote what they called the “Agile Manifesto” for software programming, which had four main points. Individuals and interactions are more important than processes and tools. Working software is more important than comprehensive documentation. Customer collaboration beats out contract negotiation. And finally, responding to change is more important than following a plan. Then they added 12 principles, such as “working software is the primary measure of progress” and you should aim for “frequent delivery of working software” — preferably every two weeks. Self-organizing teams encourage great architectures, requirements, and designs. Support, trust, and motivate the people involved – and don’t get in the way. Collaboration between the business stakeholders and developers throughout the project so that decisions are made when the business and technical team are aligned. Customer satisfaction is in first place. Attention to technical detail and design enhances agility – you can’t change quickly if you need to make a lot of stops and U-turns.
Later all kinds of methods and practices were developed on the basis of this manifesto. And now we’re deciding which practices to apply to our procedures and processes at Sberbank.
About Sberbank’s mobile banking
This new method is just being applied, but we’ve already got successful and inspiring work from our agile teams. For example, Sberbank’s mobile banking app. The first version was done the traditional way and had a rating of 2.5 stars in the App Store and a lot of angry reviews. When agile teams appeared that worked in sprints and increments, we were consistently in the 20 best apps in the App Store, and our rating ranges between 4.5 and 5.
About Sberbank’s potential for development
My generation is attracted less by careers and impressive titles and more by the chance to make things that are interesting and motivating. I came to the bank in 2011 when I was in my fourth year of applied information sciences. My first job was an analyst in the first experimental agile team that made the “Client.Sberbank” system of online banking for companies. In the seven years since then I’ve changed my job three times. At Sberbank they have no problem when an employee wants to radically change their work; if an experienced staff member wants to change and develop further, it’s better for their knowledge to stay in the company than to leave it.
What’s important for my generation is autonomy, the opportunity to work independently, without a strict hierarchy monitoring your every move. This was the main thing I discovered when I came to work at Sberbank — I hadn’t expected this level of freedom, trust and opportunity to show what you can do.
When people who don’t work in the field hear me say, “I work at Sberbank” their first thought is that I work in a branch office. They are always disappointed when they find out that I’m a total idiot about how to get credit or how to open an account, and I have absolutely no idea what the difference between Visa and Mastercard is! But people in the industry respond differently. Someone at Boeing said to me once: “Before Sberbank came to us to learn, and now we go to Sberbank to learn”.
I work in a company that wants to be the best. Meanwhile, it soberly takes stock of itself and knows that it’s far from their ideal. And they don’t stop doing everything humanly — or inhumanly! — possible to become the best in the world. That was the principle seven years ago, and over the years it’s just gotten stronger.
About that feeling of inner truth
I’m changing the process of software development. That is, I’m switching people to a new way of working. Of course, finding a solution and moving 20,000 people to this new technology is not like working in a small company of 100 people. In every 1,000 people there will always be people who are hurt, who are unhappy, who tell you, “You didn’t tell us, no one discussed this with me…” And they’ll resist you. But I was given a good piece of advice about that.
Being an agent of change is a thankless job, but it’s fascinating. It’s not the kind of work that will give you social status and love. But there is something called “inner truth”. If you keep it tuned up, you’ll always know if you did well or not. I try to listen to that voice.