What is a Lean IT Organization? Interview with Mike Orzen

We will be back to part 3 on our Leveraging Agile in Operation early next week.  This week I have the honor to post the first question of many from an interview with Mike Orzen.

It’s difficult to find lean practitioners who focus and coach IT organizations well.  The reasons are many which may be the impetus for another blog but I have been fortunate to meet a great Lean leader for IT and healthcare.  I felt an obligation to share his knowledge with you and hope you enjoy his insight in to this topic as much as I have in my leanings from him.   

I have had a great opportunity to read Mike’s book Lean IT and recommend this literature to you regardless of you experience with lean.   

Mike Orzen delivers a unique blend of lean, six sigma, IT and operations. He has been consulting and coaching for over 25 years to companies in IT, manufacturing, aerospace, high-tech, medical device, healthcare, casting, legal, logistics, apparel, and food processing. His experience includes systems design, application development, numerous ERP implementations, enterprise-wide process improvement, and large-scale roll out of lean enterprise initiatives for global companies.  Mike is on the faculty of the Lean Enterprise Institute and teaches the LEI Lean IT workshop.

1.  Can you explain why IT has not seen a bigger movement in Lean, and what does it mean to be a Lean IT organization?

A Lean IT organization uses its information and information systems to enable the flow of value to its customers. IT systems are the connective tissue that coordinates most communication and execution of work throughout the value stream. A Lean IT organization applies the principles and tools of Lean to eliminate wasteful systems and processes to provide accurate and timely information to suppliers, employees, and customers. Above all, Lean IT organizations are comfortable with the inherent ambiguity of solving problems when solutions are not apparent.

In many organizations, IT is among the “last frontier” when it comes to applying Lean principles. Often we see Lean successfully applied to the shop floor in manufacturing environments and the front office (including HR, engineering, supply chain, and accounting) in both service and manufacturing companies, but IT is conspicuously missing from the Lean transformation. I after ask why and usually get one of three responses:

1)      IT is too busy, they have a multi-year backlog and don’t have the time to be pulled away to participate in improvement work.

2)      We don’t really see the need to bring IT staff into an improvement effort when we’re problem solving. We’ll tell them if we need a report or additional app functionality if and when the team makes that determination.

3)      IT staff are difficult to work with and best left with their heads down, coding software or deploying a new server!

These responses indicate a lack of understanding of the key role IT must play in effective process improvement. Although we all acknowledge that accurate information is essential to any business in creating value and flowing goods and services to the customer, we seem to think we can generate improvements with cross-functional teams that do not include IT associates. Let’s look at these responses one-by-one.

It’s true that, in many cases, IT does have a huge backlog which is only getting larger as a result of a) late delivery of projects and b) additional projects endlessly added the portfolio. Out of control IT backlogs are symptoms, not causes of conditions calling for improvement. By excluding IT from Lean improvements, we avoid the real issue (the root causes of the current condition). The fact that we view IT as being “too busy” to participate in Lean improvement is the best reason to involve them! Until we begin to move away from business as usually, we can only expect things to get worse: larger backlogs, more project overruns, and more frustration.

Having IT staff participate in Lean activities infuses Lean improvements with “systems thinking.” IT professionals are natural systems thinkers. Systems thinking is the ability to see the whole picture and not just a segment of the process. IT staff are well versed at seeing the entire flow of a transaction from data capture to final resolution (Seeing the Whole). They also understand the interaction of various elements of the information stream (hardware and software), the complexity of which can often require more than one IT associate to fully understand. Finally, when their skills are cultivated, IT professionals have a firm understanding of how changes within an information system impact the value stream and affect employees, customers, and suppliers.

The “geek nerd” is nothing more than a stereotype. The IT associates I work with in many diverse organizations including finance, logistics, healthcare and software, are well read, educated, thoughtful people. A key tenant in Lean is “respect for people.” We often mistakenly understand this to mean that employees are encouraged, treated fairly, given clear goals, and held to accountable for results. Actually, that’s not it at all. In Lean, respect for people is all about coaching people by challenging employees to solve problems; asking for deeper thinking, more data and facts, and more dialogue. This is experienced as uncomfortable and difficult work when employees (particularly in IT) just want to implement a solution!

IT associates are more than capable of responding to this kind of challenging work. They possess the aptitude for deep analysis and reflection that is required to make significant Lean improvements. All that is needed is a willingness to try. The first step is to make the time to involve IT in Lean activities. Lean IT is an untapped goldmine just waiting to be unearthed!

Who Is Responsible for Quality?

This week we’re going to take a break from talking about Agile in IT operations so we can examine quality in IT.

When Edward Deming, the Grandfather of Quality, taught his methods to the Japanese in the 1950's, he was working with a group that had historically been known for poor quality. Invited by the Japanese Union of Scientists and Engineers to assist Japan in their post-war reconstruction efforts, Deming taught Japanese management, scholars and engineers to focus on quality in order to produce world-class results and become competitive in world markets.

Japanese Leadership

During his early lectures, Deming quickly realized that quality cannot be sustained unless an organization’s leadership focuses on its importance. Initially, he lectured plant managers and engineers who had no authority to implement change. When Deming consulted with his Japanese hosts, they understood the problem and arranged for him to speak to about 100 top-level business leaders.

Deming instilled in these leaders a sense of responsibility for quality in their organizations. He maintained that, ultimately, quality is created in the boardroom and is the responsibility of top management. With senior management supporting quality efforts, the Japanese companies and economy would flourish.

Japanese Success

Deming predicted that Japanese companies would export their products all over the world and companies in other countries would be clamoring for trade protection from the Japanese within five years if they followed his recommendations for improving quality. Although the Japanese business leaders did not initially share his vision, they did as he instructed so they would not lose face. Japan surprised the world with their success and even beat Deming’s prediction by a year.

You probably know the rest of the story regarding Japan's success and what American organizations had and still have to do to catch up with Japanese firms. American firms confused quantity with quality. Demand for American goods was so high in the 50's and 60's the American manufacturing companies assumed this translated to quality for the customer.

However, this misconception was created from the great economies of scale available to American companies due to the war engine. At the time, the United States was the only country in the world which could produce at levels necessary to meet demand. As soon as Japan could both meet demand and offer higher quality, American companies fell behind in world markets.

Putting Out Fires

I have found that many IT organizations function similarly to the manufacturing model that existed before Deming’s quality movement. They judge the quality of their product, IT services, by the demand for that product.

For example, when a system goes down and IT team members scramble to get it working again, companies reward this behavior by praising the heroes who got up in the middle of the night to fix the issue. These individuals are suddenly visible and valuable. They are motivated to continue putting out fires rather than to improve system stability. The incentive to become system arsonists is greater than the motivation to create quality systems.

Continuous improvement is a hard sell for some IT professionals because doing a quality job means nobody notices IT. The better the systems run, the fewer chances there are for heroics. A quality IT group is almost invisible.

Deming’s 14 Points

Below are Deming’s 14 points for management transformation. They were originally published in Out of the Crisis by W. Edwards Deming.

Although the 14 points were written for a manufacturing scenario, try to translate the recommendations into ideas for an IT team. Following these points in your IT group can help you focus on making quality everyone's responsibility.

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.

6. Institute training on the job.

7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company.

9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.

b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.

11. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

12. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means abolishment of the annual or merit rating and of management by objective.

13. Institute a vigorous program of education and self-improvement.

14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.

Deming’s 14 points transformed manufacturing into a quality-focused delivery system. The same benefits can be realized in IT, creating continuous improvement in IT processes and products. When quality is built into your IT systems you can increase the value of your department to the business, decrease time spent on downtime and reduce the load on team members who have to fix problems caused by a lack of quality.

The Journey Toward Quality

I realize I am not giving much in the way of suggestions for translating the 14 points into action but I would encourage you to study how you can facilitate making quality core to your business.

All the excuses you will hear from your team about why these 14 points won’t work in IT are probably the same excuses manufacturers made before they made the shift to quality. The arguments have already been made and overcome and the benefits of following the 14 points have been clearly demonstrated.

If you haven’t started the journey toward increased quality and would like help, feel free to reach out to me. I can provide you directions to start. Good luck!

Patrick Phillips and Jen Browne

Leveraging Agile Principles in IT Operations: 2 of 4

Working systems over comprehensive documentation

Agile Overview

Last week I discussed how you can reap the benefits of a structured framework and create opportunities for continuous improvement in your IT operations team by emphasizing individuals and interaction over processes and tools. This concept is based on the idea that the processes and tools that your IT operations team uses, including the organizational framework, should be driven by the team’s values rather than the desire to watchdog productivity.

This week I’m going to talk about the second precept of the Agile Manifesto: Working software over comprehensive documentation. Although software is integral to the work of a site operations team and members of the team are often required to code as part of their regular work, creating working software is not the primary function of an IT department, so we’re going to modify this precept to reflect the core competency of IT operations: Maintaining working systems over comprehensive documentation.

The Documentation Monster

If you want to provoke a negative emotional response in your IT operations team, tell them everyone needs to focus on documentation. It’s not fun. It’s hard to know where to start. It takes away from the time your team can devote to deploying, fixing and maintaining systems. It’s not generally the strongest skill in the IT professional’s toolkit.

On the other hand, it can save a significant amount of time when troubleshooting. It can foster knowledge transfer. It speeds the learning curve for new hires trying to find their way around your systems. It can be integral to a good disaster recovery plan.

Given the advantages and drawbacks to documenting your systems, how can you find a reasonable approach to creating the documentation?

Document Key Information

The key difference in this approach lies in understanding the difference between comprehensive documentation and valuable documentation. Valuable documentation supports the needs of your team.

Lay the groundwork for creating a culture that embraces documentation by discussing the values of your group. What drivers would make documentation valuable to you? As a team, determine what system information you need to track. This will generally come down to four key ways the knowledge will be used:

1. Reducing troubleshooting time
2. Sharing knowledge
3. Training new hires
4. Supporting disaster recovery

Recognizing the value and purpose of documentation can support the culture of creating and maintaining it. Keep in mind that if the information doesn’t strongly support how your group will use the documentation, it is extraneous. Extraneous information is a waste of time and energy to track and doesn’t maximize the IT operations team’s value stream.

Maintaining Working Systems

It’s rare to have the luxury to build systems and documentation together from the ground up. Many start-ups are scrambling just to have working systems, much less document them. Most of us have to start with a system that is already in place.

Examine your system. Is it mature? Do you have instrumentation in place, including telemetry, monitoring and alerting, failure detection, and comprehensive, readable logs? Does it fail gracefully? Is it designed for recovery? Are the necessary high availability sub-systems in place? These are the foundation for maintaining working systems. Identify your gaps, prioritize them and create a plan for putting them in place.

Document as You Go

It’s not practical to drop the regular work of an IT operations department and go on a documentation spree for a week. For one thing, everyone will take the week off. For another, knowing where to start documenting is a daunting proposition.

Instead, document as you go. When a team member is working on a standard tasks – deploying, fixing and maintaining – use the opportunity to look at the system from a documentation standpoint as part of the standard task. Refer back to the ways your group will use the documentation as a guideline to creating it.

Another way to create documentation is to embrace failure. When your systems fail, use the opportunity to strengthen them, address the root causes, and document both the fix and the new, stable state. This can support future troubleshooting efforts while creating training material.

Looking Ahead

In part 3 of this series I will examine how the third precept of the Agile Manifesto, customer collaboration over contract negotiation, supports an IT operations environment.

Jen Browne and Patrick Phillips

Leveraging Agile Principles in IT Operations: Part 1

Individuals and Interactions over Processes and Tools

Agile Overview

“Agile” refers to a set of methodologies that focuses on iterative and incremental software development, emphasizing collaboration between cross-functional teams. I was recently asked by a CEO to explain the value of using Agile principles in IT operations, a group that doesn't typically embrace Agile tools and processes.

At its foundation, relating Agile to IT operations rather than to the development world, where Agile was founded, means understanding the differences between the needs of a group that follows a pattern of planned work (software development) and a group that is largely interrupt-driven (operations).

The Agile Manifesto lists four main precepts:

• · Individuals and interactions over processes and tools
• · Working software over comprehensive documentation
• · Customer collaboration over contract negotiation
• · Responding to change over following a plan

In this series of blog posts I will discuss how each precept can bring value to the responsibilities of your IT operations team.

Traditional Frameworks

When seeking an organizational approach, there are compelling reasons behind constructing an IT department using an ordered framework such as ITIL or MOF. This approach locks the team into a safe, prescriptive approach that is hard to fault. It reduces the need for personal judgment and critical thought while defining roles and responsibilities, offering a clear trail for audits.

However, there are associated drawbacks. Frameworks don’t foster creativity. They’re often top-heavy, requiring a great deal of time and effort to implement and maintain. Additionally, overlaying a framework on a disorganized IT team won’t create useful process and can bog down the team when implementing the framework, rather than providing structure for the department, becomes the goal.

Structured frameworks also fail because they don’t foster continuous improvement. Even though root cause analysis is often included within the framework, the step that remediates the root cause and creates process improvement is frequently not addressed. Thus the value of understanding the root cause is lost.

Individuals and Interactions

Fortunately, you can reap the benefits of a structured framework and create opportunities for continuous improvement in your IT operations team by following Agile’s first precept: individuals and interaction over processes and tools.

The processes and tools that your IT operations team uses, including the organizational framework, should be driven by the team’s values rather than the desire to watchdog productivity. Focusing on individuals and interactions puts a framework into perspective; it becomes a set of guidelines that support the team rather than setting the framework itself up as the goal.

The concept of individuals and interaction over processes and tools also forms a philosophical stance for the management of teams. Trust your IT team. Many IT people are intelligent, internally-driven professionals who want to find ways to improve department processes and customer service. If you don’t trust your team, get a different team, either by getting different people on the bus or by shifting yourself to a new bus. Using processes and tools to lock down the behavior of team members as a substitute for trust can be disheartening for teams and is an ineffective management approach.

Looking Ahead

In part 2 of this series I will address the second precept of the Agile Manifesto, working software over comprehensive documentation, and discuss how it applies in an IT operations environment.

Jen Browne and Patrick Phillips