How we took and canceled Lean on the project (And how it ended)

Can Lean Manufacturing be used in IT? Before employment in such a company, I didn’t really think about it, although I studied it at the university, read books and went to olympiads. Lean in those days for me was associated exclusively with the methodology of industry, with the tact of production, with machines, cutters, the squeal of a circular saw, the smell of fuel oil and huge concrete shops.

This is how I discovered Lean manufacturing, tailored for service and IT, since then I have delved exclusively into this direction. I sometimes worked on 5 projects at the same time, and in some it was implemented, and in others it was not. In some project, the level of Lean practices was already mature, in some, everything was just beginning to germinate in people and processes, so I could compare both the quality of service and the level of team involvement. My opinion became more and more affirmative – where the practices were implemented, the work was always done better, faster, better, and communication with the team was more efficient. Is it really? I want to find out on the example of the work of our support team.

Our support team is a remote team of engineers rummaged through several projects. Our engineers quickly grow out of their grades and leave for other areas, often joining the team fresh blood pouring inTherefore, the topic of effective communications, accumulation and transfer of knowledge, maintenance of corporate culture is vital for us.

It is not so important for the customer who exactly does what. The customer sees and evaluates the service as a whole, so everything depends on the well-coordinated work of the team and its fighting spirit: especially when all the databases suddenly went down, users around the world lost access, and the customer is waiting for a solution to the problem right now. But the Lean philosophy ensures continuity and quality, which means that for now Lean production should be.

…Or not to be?

Have we tried to work without Lean practices? Oh yes, it was.

There was one small old project, which, as it seemed to us, we know inside and out, everything was quiet, peaceful, calm, even boring. Lean manufacturing tools have been implemented and used regularly. So at one point, the team suggested doing without team calls altogether to maintain the quality of service (“why waste time on them??”), without special problem-solving sessions (“no problem”), just work as we work.

Okay, accepted decided to remove. After all, why torture people with a methodology in which they are not interested? A month later, the SLA dropped from 100% to 95%, because we missed one problem, the team did not raise this issue in time (there are no more meetings on problems where this is discussed), and the service suffered.

It would seem that a 5% drop is not too critical, we even fit into the framework of acceptable metrics and our agreements with the customer. But, firstly, this is a drop in just a month, it’s scary to imagine what would happen in six months, and secondly, even such a slight deterioration hit our professional pride as an excellent service provider. After all, we are used to being the best, we are used to the fact that the customer always speaks well of us, we are used to working at 100% and being in the green zone. As it turned out, our quiet life and reputation were protected by our best practices in the form of Lean manufacturing tools. We didn’t try to cancel it.

Lean starter pack

Here I want to talk about two main tools, both powerful and at the same time quite easy to use, which we use utterly always, and about the ways of this use.

1. Circle of quality

The simplest of them is team quality circles, or, as we call them, CommCell.

CommCell has a specific structure and purpose: the team suggests the pains that are currently bothering them on the project, looks at the status of current problems and tasks, monitors our performance, exchanges news, success stories to increase motivation and stories of instructive mistakes and life hacks on the project, as well as makes suggestions to improve the service.

This is how we can understand and catch the trend of our KPIs, that, for example, this week there were too many identical incidents from different users on the same problem, which means there is some root cause affecting the application. Plus, this is how we eliminate the risk that someone alone knows about the problem and sits silently, and then the service suddenly drops, and we fix the broken functionality in a sweat; we keep our knowledge up to date and know all the latest news and even gossip!

Farewell, situations when all of a sudden everyone lost access to servers! Because they migrated, but they forgot to tell us about it. Now we know that the team lead has a beautiful cute cat chewing on the headphones, and the trainee did not get the branded mug (and now we still know how to get it).

The main principle of CommCell is to involve everyone, so it can also be used to determine the mood of the team: when people are silent, stop generating ideas, participate in the discussion, withdraw into themselves – this is immediately visible. And vice versa – it’s clear when the team feels good: people do tasks on time, come with their pains and ideas, share news and life hacks with the team, support each other.

Icebreaking practices are important to get people involved in the rally, especially if you are all working remotely. Our company has amazing examples of how creative, fun, and most importantly productive CommCell can be conducted, everything is used: and surveys in Google forms (How are you feeling today?), and boards on the resource Miro (take a card and describe your pain), and google maps (I’m on a business trip today herelook!).

2. Problem solving sessions, or Clicking questions like nuts

Another powerful tool is Problem Solving, which naturally complements and frames CommCell. It is important to understand that on CommCell we do not discuss problems (we call them concerns), we only register them, then on the call we ask who is interested in solving this problem and hang a task on someone – to create a separate meeting for this problem, Problem Solving session.

The Problem Solving Session just exists to discuss and solve problems. This separation allows us not to stretch calls, not to waste the team’s time and immediately identify those who can and will specifically solve the problem raised. I think the value of this division will be understood by everyone who has ever been stuck on many hours of daily, where engineers suddenly start discussing a piece of functionality that should work, but for some reason does not work and which is outside your area of ​​​​responsibility/competence, and you don’t know why you are needed here when you have your own backlog of tasks that need to be addressed.

The Problem Solving Session has a simple and clear structure that allows us to make the most efficient use of time:

  • 5 minutes discussing the definition of the problem (Do not laugh! This is a key point, the success of the entire event depends on how well we formulate the problem.),

  • 10 minutes we determine our desired state (according to the SMART method),

  • 20 minutes to find out the causes of our problem according to the “5 whys” rule.

After determining the root causes, we organize a brainstorm, offer solutions, then sort them by efficiency (costs, terms) and take the best options to work, build an action plan and then look at the CommCell to see how the tasks are successfully solved and whether we have reached the desired state. If not achieved, then we repeat the process, we do work on the mistakes. Simple, tasteful, effective. One day, our new colleague came out of the Problem Solving Session with burning eyes and exclaimed: “Wow! Is it really possible to solve everything so quickly? It’s always nice to hear that. Especially if you are facilitating such a session (hehe).

Some final words

Of course, implementing Lean from scratch, changing the mindset of employees is a very difficult task, teams get used to it for months, this is a painful process. But the result exceeds all expectations. If on the project, before the introduction of the Lean manufacturing philosophy, users could wait for a response for weeks, tickets (and engineers) turned red like tomatoes in the garden, high-priority incidents constantly arrived, there was chaos and chaos everywhere, but the introduction of CommCell and Problem Solving Session alone helped to reduce the number of incidents (the team’s stack fell 3-4 times), and the customer noted how much the team had grown.

In addition to the tools mentioned, there are many others that we have implemented – for example, Demand Analysis, 5S, Standardization. They helped to make the quality of service stable, and after their implementation, we no longer returned to the red zone. 100% SLA has become the norm, and the number of high-priority incidents has fallen from 10-15 to 1-2 per year. Through a philosophy of continuous improvement, proposals were made that reduced routine, reduced the chance of human error, and helped the company save hundreds of thousands of dollars. And we can no longer imagine how it could work differently.

Similar Posts

Leave a Reply