/Using lean thinking to understand IT processes

Using lean thinking to understand IT processes

FEATURE – Lean thinking and agile have the power to make software development and IT processes less knotty, but before they can their relationship and prerogatives must be understood.

Words: Marie-Pia Ignace, President, Institut Lean France; Regis Medina & Sandrine Olivencia, Lean It Coaches, Institut Lean France

What would happen to a company if its CIO (or CTO) decided to become a lean manager?

Let’s look at this – as we always should – from the client’s perspective.

For the end user, the benefits of their IT provider going lean would be:

  • highly reliable systems, with 0 defects;
  • delivery of the requested services at the pace required and within the budget agreed upon;
  • the creation of newer and unexpected value, thanks to a deep understanding of both business fundamentals and technology.

We all know, however, that this is very far from our average experience with IT products and processes, which tend to look more like this…

Most of us can relate to this video, right?

A common reaction to a slow piece of software or to an app malfunction is very often verbal abuse towards computers or tablets. Not to mention what happens when we are faced with the prospect of having to wait months for more “complicated” actions, like changing a button on a webpage, to be completed.

If this sounds like you, you may find consolation in knowing you are not alone: industry figures reveal how only 38% of IT projects meet customer expectations.

Where should we start to make things better, then? Quality and people engagement are the lean answers to these problems.

Let’s share a couple of examples.

The CIO of a bank started a lean journey with his support teams with the aim of:

  • increasing user satisfaction ratio;
  • reducing the cost of recurrent activities and, as a consequence, to increase the budget available to project teams;
  • freeing up the time of his most experienced people, who can focus on adding value rather than firefighting and managing incidents.

How did this experiment go?

Everybody in the organization learnt to see incidents and requests for support as “waste” and to run problem solving, using PDCA, to reduce their volume. Some problems were easy to address, such as a cryptic pop-up giving no direction to the users on what they had to do in order to fulfill their need; others required lots of time at the gemba and experimentations before the right action could be found.

Was it a success?

In two years, the number of queries was halved and end-user satisfaction with the bank’s IT infrastructure increased from 2.4 to 3.5, out of 5.

Let’s look at another example.

In a telecom organization, the CIO was considered as the bottleneck in marketing campaigns. He needed to become quicker at setting up systems.

His teams developed three new capabilities:

  • carrying out each step of the process without errors. They had to refine their understanding of the process, rewrite their standards and learn more;
  • connecting the steps of the process and developing collaboration between teams in order to reduce variability in the management of projects. They visualized the flow together, learnt how to pull activities and, step by step, reduced the complexity of their job;
  • overall, addressing any difficulty as a problem and solving it using the scientific method (PDCA).

Setting-up time was reduced by 50% and quality nearly reached perfection.

Lean aims to develop people through problem solving in order to delight customers and strengthen companies. And there is a lot of need for it in IT.

In recent years, agile software development has been particularly talked about. Indeed, an agile team represents an invaluable asset for any IT department, thanks to its approach based on team work, customer needs, small batches and built-in quality. However, the role of agile and its relationship with lean are still somehow unclear.

In the second part of this article, Regis Medina and Sandrine Olivencia share a few thoughts on the lean and agile approaches and look back at the roundtable held at the 2013 Lean IT Summit on the subjects, in which experts of the two methodologies took part.

It is not uncommon to hear a CIO proudly announce that his team is applying lean principles to its software development activities, while in fact they are using the agile methodology. However, confusion is not uncommon when talking about lean IT and agile, as the two do have many things in common.

My experience [Regis’] is quite emblematic: after over 100 iterations as an agile software developer, I realized I needed something new to progress professionally, and I turned to lean thinking. When I started reading books about lean, I first thought that lean practices were very similar to agile. However, as I looked more closely, and thanks to the coaching provided by my senseis, I came to realize how incredibly different the two approaches actually are.

Now that I have practiced lean in IT for six years, I have a much clearer idea of their role:

Agile is for building; lean is for learning.

Agile is a very efficient software production system: it provides tools and practices for organizing a team able to deliver value-adding software in the face of extreme uncertainty. In that particular context, agile performs miracles. Lean, on the other hand, is a structured system for developing the capabilities of people.

If we start seeing things this way, we will be able to reap the benefits of both worlds.


[widgetkit id=13]

Another important difference between agile and lean that must be kept into consideration is that the former leads to silos, while the latter helps IT to realign its activities with the company’s strategy, clients and management.

[widgetkit id=14] 

Lean thinking helps teams to focus on topics that matter to the customer: understanding their needs, producing quality right first time for them, and delivering at the pace of their demand. Lean also looks at the concept of self-organization, embraced by a branch of the agile movement, from a different perspective. On this specific point, Professor Jones had a very clear response…

[widgetkit id=15]


[widgetkit id=16]