FEATURE – Lean thinking is increasingly applied end to end, reaching virtually every area and function of the enterprise, and yet in many companies IT is still left out of the lean transformation. Isn't this dangerous in a world that is going more and more digital?

Words: Flávio Picchi, Vice President and Christopher Thompson, Project Manager, Lean Institute Brasil

IT is one of the biggest drivers of change in the way companies deliver value to their customers and increase their productivity. But it can also be a major source of waste.

From a value-adding perspective, everyone recognizes that IT is changing people's lives, facilitating interactions between companies and customers, and contributing to streamlining internal processes for our businesses.

But there is also a "dark side" to IT. A study by the Standish Group shows that only 39% of IT projects are delivered on time, that 43% of them experience problems like exceeding costs and failing to meet deadlines (respectively 59% and 74%), and that 18% of them are never even delivered. Of the functionalities delivered, 65% are not used, 15% are partially used, and only 20% are used on the regular.

The consequences of this rather dire current state are evident in most organizations: on one hand, there are clients complaining about the long waits to get their hands on the latest IT solutions; on the other, there are IT departments burdened and under mounting pressure.

There is more. IT often requires big investments and expenses. According to the Gartner Group, in 2014 companies spent on average 2.5% of their revenue on IT, with organizations in certain sectors, such as healthcare or finance, spending more than 5%.

Considering the value it creates, but also the waste if often generates and the resources it requires, the IT department cannot be excluded from a company's lean efforts. There are several approaches out there that help to apply lean principles to IT – collectively, they are known as "lean IT."

HOW LEAN IT EVOLVED

Traditional software development is based on three main elements:

• Strict specifications early in the process;
• A development model known as waterfall (a sequential design process that sees progress flow steadily through the conception, initiation, analysis, design, construction, testing, production/implementation and maintenance phases);
• The delivery of large batches.

Over time, the waterfall model has become the subject of criticism because of the great amount of waste it generates. In 1999, XP (Extreme Programming) came into the picture. It proposed a number of radical changes in the software development process, focused on team organization to produce high-quality software and on productivity in short cycles.

A couple of years later, in 2001, a group of software experts published the Agile Manifesto, a series of principles that are very close to the lean concepts. In an attempt to apply the newly created agile principles, a series of practices were created, some of which radically changed the way the traditional development process is managed.

One of the most common practices is scrum, in which we recognize several lean ideas, such as frequent interactions with the customer, deliveries in small batches, visual management, teamwork and reflection at each delivery cycle.

Another practice that also changes the traditional development process is Kanban, which seeks continuous flow through visual management.

There are many tools that support the creation of flow and quality at the source, like Test Driven Development. Other methodologies integrate and automate the development-test-integration-delivery cycle and pursue the integration of development and operations (DevOps).

The strength of lean applied to IT is demonstrated by the number of pioneering theorists who are working to deepen our understanding of this domain. Mary Poppendieck, for example, seeks a broader view of lean IT, pointing out that the key elements in this process are: to do the right thing (understand the real value through customer perspective), to do it fast (reduce lead time), to do it in right way (ensure quality and speed), and to learn through feedback. More from Mary Poppendieck in this interview for Planet Lean.

Eric Ries expands on the concept of customer feedback in his popular book The Lean Startup, in which he talks about quick learning cycles, testing hypotheses with the end customer, adjusting the direction (pivot) or persisting (persevere) depending on what we learn from customer feedback.

Mary believes that software development is actually a subsystem of product development, and point out that lean product and process development concepts are fully applicable to writing code. Those working in the LPPD domain have also developed a keen interest in agile, which confirms how much these areas can learn from each other.

Many of these concepts have received more attention from the developers (suppliers) and less from the customers (the real demand, both internally and externally). As if the system was being more pushed than pulled.

In their book Lean IT, Steve Bell and Mike Orzen discuss the need for a dual approach: operational excellence in IT internally and the integration with business processes improvement externally. The book was a pioneer in exploring the full integration of IT with the business allowing for the implementation of real pull.

HOW DOES THIS RELATE TO CORPORATE IT?

When we look at the adoption of these techniques and principles in today's business world, we witness a dichotomy: companies that deliver software as a service – like Google, Spotify, and the plethora of startups and App developers of this world – seem to take them on in earnest, while their application in traditional corporate structures is still in the early stages.

The typical transformation starts in operations, moves to administrative processes and finally reaches the leadership and management levels. Even in organizations that are advanced on their lean journeys, however, it is often rare to see IT involved in the transformation efforts. In some cases, the IT department remains something of a separate entity; in others, leaving it out ends up becoming a barrier to change. How often do you see proposed improvements entering the backlog and having to wait months for an IT system change that would only require a few hours of work?

Here is an example: we have seen a company struggle to implement kanban and flow in their future value stream just because the way the system was originally designed would require the manual registration of every inventory movement in between processes, including those that had been eliminated by the creation of the new flow. There are a lot of waste and noise along the value stream that tend to overload IT, gradually taking it further apart from the rest of the business.

Like with everything else in lean, understanding what problem you need to solve is the first step. Developing a piece of software with certain features can indeed be a countermeasure, but if all the people involved in the value stream haven't understood what problem needs solving great waste can result from what we hoped to be a solution.

There are also successful examples, however. Lean Institute Brasil supported a retailer of specialized products that shows the benefits of creating alignment between the IT area and the rest of the organization on the problem at hand, which necessarily comes before asking which software needs to be developed.

Preparing for the implementation of an ERP system, the company decided to streamline some problematic processes – namely, the failure to deliver the right products to the stores at the right time (resulting in lost sales, in the face of huge inventory) and wrong charges to customers. Working together, the different parts of the value stream (stores, finance, purchasing, suppliers, and of course IT) were able to achieve their inventory reduction goals and to improve customer service, using tools such as value stream mapping and kanban. Interestingly, but perhaps not surprisingly, the vast majority of the problems were solved by introducing flow and without the need to write a single line of new code.

Had the "traditional approach" been applied to this scenario, detailed specifications would have been made, heavy and expensive systems would have been developed, and the whole process would have taken much longer. Additionally, the backlog of to-be-developed software would have gotten bigger, and the problem would have possibly remained partly unsolved.

Lean is continual learning, and as a journey it is never over. It is therefore not strange that the idea of lean IT is still somehow "under construction". We are still learning and trying to understand this type of applications, as we are operations, product development or the office. What is already clear, however, is that different parts of a business have a lot to benefit from sharing concepts and their lean lessons learned with one another, as well as from working together to improve the value stream as a whole.

There is no doubt that IT is a strategic asset for the future of every organization, which somehow brings the need for value creation and waste elimination to a new level – due to the proximity to the end-user and the pace of change. By sharing the experience gained in 25 years of implementations in most sectors of the economy and areas of a business, lean has the opportunity to make a huge contribution to this leap forward.

‍_{THE AUTHORS}