Chapter 1

Lean Primer for IT Professionals

Introduction

The purpose of this chapter is to provide the reader with some familiarity on various applications of lean to IT. It’s important to have a basic understanding of fundamental concepts and areas of practice in order to stay grounded in principles that really provide lasting results. We often see IT organizations jump from hot new topic to hot new topic, applying a flavor of the month strategy that never sustains itself.

There have been many great books that cover the fundamental concepts of lean, Six Sigma, and continuous process improvement; our intent is not to rehash that information (that wouldn’t be very lean at all). In the past, most of the books on lean were oriented toward manufacturing. That all changed around the year 2000 when the world saw a widening application of lean into areas including healthcare, service industries, product development, education, government, and our favorite topic: lean IT.

In 2010, Mike coauthored the book, Lean IT—Enabling and Sustaining Your Lean Transformation, ² which received a Shingo Research and Publication Award. Chapter 2 of the book, “Foundations of Lean,” has been widely used by IT and non-IT groups as a brief primer explaining many of the core concepts while placing them within the context of information management and technology. This reading will give you a conceptual overview of lean within an IT context.

We encourage you to download Chapter 2 of Lean IT and find additional resources at LeanITFieldGuide.com.

The Lean IT Cosmos

We use the term lean IT to refer to all applications of lean thinking, principles, methods, and tools in the world of information management, communication, and technology. There are numerous applications of lean in the IT field including software development, operations, infrastructure, and project management, to name a few. All of these approaches demonstrate the effectiveness and applicability of lean thinking to information technology. The clearer your understanding of these components, the more effective you will be at applying the tools and methods needed to achieve your specific objectives.

Agile/Lean Software Development

Many of the people in companies we work with seem to equate lean IT to agile. While agile effectively applies many of the core principles of lean, it uses only a subset of lean techniques and targets the software development process. We see lean IT as being much broader.

In 2001, a group of software developers introduced the Agile Manifesto ³ to evangelize short cycles of productivity, giving end users frequent releases of usable software with the express purpose of moving away from traditional overburdening bureaucratic development practices (e.g., Waterfall and Big Bang ⁴ ). The concept of using small batch sizes had been introduced in lean manufacturing 50 years earlier, but this was totally new to the world of software development. When the Agile Manifesto was first published, some rejected it as pure fantasy!

The Agile Manifesto proclaims 12 key principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from selforganizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The core characteristics of agile are short, rapid cycles of work (sprints), business involvement throughout the development process (product owner), team collaboration and self-direction (daily Scrum), visual management (work-in-progress boards and burn-down charts), and reflection (retrospectives, feedback loops, ongoing process improvement), as well as an emphasis on software engineering excellence.

As organizations experimented with agile and Scrum, ⁵ they discovered that exclusively focusing on software development without considering upstream and downstream operations severely limits the benefits. For example, when agile methods are applied to infrastructure, it often creates a more nimble and flexible infrastructure capability throughout public or private clouds with virtualized servers, storage, and networks. Agile infrastructure also applies many of the same core ideas of faster iterations, small lot sizes, self-directed teams, and kanban.

Kanban

Kanban is a tool originally developed more than 50 years ago to support the Toyota Production System Just-in-Time method of making only what is needed, when it is needed, and in the precise amount needed. Kanban (often a physical card) can simply be thought of as an authorization to produce and replenish parts that have been used. Over the years it has been adapted to many uses in manufacturing, service, and knowledge industries.

Kanban, as the term is used in IT, is a visual display board used to (a) visualize the flow of work, (b) limit work-in-process, (c) drive productivity through an awareness of what people are actually working on, and continuously improve the process!

David Anderson ⁶ introduced the Kanban Method in 2003. Anderson focused on six key elements of using kanban effectively:

1. Visualize—The work in IT (and most knowledge work) is essentially invisible. There are no piles of half-finished work sitting around on the factory floor. Kanban exposes the flow of work (or lack of it)—being able to see the flow of work is essential to managing it! Without a clear understanding of what the work is, managing its flow effectively is nearly impossible.
2. Limit work-in-process (WIP)—The amount of potential work that is released to be actually worked on is limited based on available capacity. Most IT shops work under the infinite capacity model ⁷ of work management—basically saying yes we can do that and beginning work without regard to what is already in flight and what resources are available. Kanban uses a pull system to regulate the release of new work into the work stream. By limiting work-in-process, we only begin new work when work already released is completed or on hold pending some resolution. Work changing status from in process to done (or on hold) signals available capacity and creates a pull signal that additional work can be started.
3. Manage work flow —When work stops, bottlenecks can be addressed immediately and countermeasures can be put into place to re-establish the smooth flow of work. The flow of work through each stage of the process is actively monitored and managed.
4. Make policies clear—An unambiguous understanding and visualization of how the work flows through the system (based on facts) enables teams to move to a more cogent and objective dialogue of work flow problems and obstacles.
5. Implement feedback loops—Teams evaluate what is working and what is not (based on objective measurements which are under their control), feeding this information back as they identify the next step to move toward the higher levels of performance.
6. Improve collaboratively—Kanban provides teams with a shared understanding of what the work is, how the work flows, and their current state. With this understanding, teams are much more likely to build consensus around current challenges and countermeasures to address them.

Continuous Delivery

Continuous Delivery (or Continuous Deployment) is all about releasing functional software more frequently and in small chunks. This applies to companies that actually sell software (think Intuit) as well as companies who rely on software to deliver products and services (think Amazon). Continuous delivery (CD) leverages automation, recurrent releases of code, testing at every stage of the process, and a pull-based work flow that permits only successful releases to move to the next stage in the release cycle.

In 2010, Jez Humble and David Farley came out with Continuous Delivery ⁸ and articulated work practices around automation of the build- deploy-test process and supporting collaboration of development teams. Humble passionately explains Continuous Delivery with his mantra, “Reduce the cost, time, and risk of delivering incremental changes to users!” Here again is a clear application of lean thinking: smaller lot sizes, frequent releases, automation to drive quality, shorter time to market, faster feedback cycles of learning, and an emphasis on delivering value to the customer in terms of working software (as opposed to delivering new features).

The benefits of CD go way beyond releasing functional software and include faster reaction time to market changes and surprises, more flex ible release options, and a standard of production quality code with every commit. Moving to continuous delivery necessitates a significant building of infrastructure in a software architecture context as well as operationally. But once accomplished, it provides the business with more flexibility of how it delivers new functionality.

Lean Startup

It is estimated by Harvard Business School’s Shikhar Ghosh ⁹ that 75% of all startups fail! Steve Blank developed Lean Startup ¹⁰ and Eric Ries popularized it in 2011 with his highly readable book, The Lean Startup. ¹¹ The Lean Startup movement applies many of the essential ideas of lean to—you guessed it—conceiving and creating a successful business startup!

Lean Startup is a beautiful example of the Plan-Do-Check-Adjust learning cycle that lies at the root of lean thinking. The approach (described as Build-Measure-Learn) is based on building a set of hypotheses and identifying ways to test them as quickly and cheaply as possible.

In order for Lean Startup to be effective, a key concept known as Voice of the Customer plays a central role. Instead of the business deciding what customers want, and then secretly developing a finished product to be introduced to the market with the hope that interest (and sales) will be massive, a learnas-we-go approach is applied which relies on frequent feedback from prospective customers early and throughout the entire product development process.

This approach fast-tracks learning in order to understand what prospective users actually want and are willing to buy, allowing assumptions to be tested as quickly and cheaply as possible by releasing minimum viable products (MVPs) to prove or disprove assumptions on what customers need and want. This significantly reduces wasted effort, time, and money by limiting work done on features and products customers don’t want.

The traditional Business Plan is fading in many business sectors as the rate of change and degree of competition have grown exponentially in recent years. This is particularly true in companies that rely on innovation to create competitive advantage. Lean Startup is all about failing fast in order to continually accelerate learning. This means releasing less-than-fully functioning prototypes (only what is needed to test assumptions) with which to gather feedback from your target market.

Lean Startup significantly reduces the barriers to entry and the cost of failure since small, iterative tests of assumptions allow crucial course corrections (called pivots) early in the process. It is efficiently discovering the right business model rather than creating a full-blown but unsubstantiated business model that achieves ultimate failure. The focus is on speed, validated learning, customer-driven product development, a flat organization, and agile development.

We are fascinated to see how this community has exploded into an international phenomenon, with Startup Weekends ¹² (typically Friday evening, Saturday/Sunday affairs) occurring around the world. These events are open to anyone who is interested in launching a product. Attendees learn Startup basics and test their hypotheses over the course of the event. On the first evening, attendees give 2-minute pitches, vote on the best ideas, and then work in teams over the weekend applying Lean Startup methods, launching early tests of their concepts. On the final afternoon, attendees present their results to business leaders (and hopefully round-one funders) who critique the project and give valuable feedback on next steps.

DevOps

DevOps is more of a movement than a methodology. ¹³ The objective is to create a seamless flow of value from IT by coordinating and integrating the activities of Development (Dev), Operations (Ops), and beyond. The concept of a value stream has been applied in lean (both in Service and Manufacturing environments) for decades. DevOps leverages many of the lean tools we apply in this book. In The Phoenix Project, ¹⁴ Gene Kim, Kevin Behr, and George Spafford share a wonderfully illustrative novel, which lays out a general application of DevOps.

Mike had the opportunity to work with one of the authors of The Phoenix Project, Gene Kim, and help develop the three insights included in the book. Gene calls these the 3 Ways. ¹⁵ The 3 Ways represent the core principles of DevOps and have sparked a great deal of conversation and debate. Lean practitioners will recognize these as key components of lean thinking ¹⁶ and The Toyota Way ¹⁷ :

1. Apply systems thinking—appreciating and understanding the interdependent nature of the parts of business systems and how they interact with their environment and influence each other. The focus is on the interactions between the Dev and Ops groups and its impact on the uninterrupted flow of value from concept, to development, to release, to service, to maintenance, to upgrade, and eventually to retirement. DevOps places a key emphasis on breaking the silo-based barriers that have traditionally segregated these activities.
2. Amplify feedback loops among stakeholders—almost all system-level improvement is reliant on feedback from customers and suppliers. Without feedback (both positive and critical), there is very little check/ adjust activity to continuously improve. In IT, we often see a lack of collaboration from internal IT staff (think Dev to Ops) as well as from end users. This leaves people assuming that everything is working well or that the other parties don’t care enough about the problem to communicate. Both suppositions are often wrong and lead to costly outcomes!
3. Create a culture of continual experimentation and learning—learning based on trial and discovery is the bedrock of improvement. To master something is to understand it at each progressively deeper level. DevOps stresses collaboration and fact-based experimentation as the means to build a culture of continuous improvement. Taking risks assumes a new meaning, in that experiments are run using a formalized thoroughness that leads to true learning. That learning is applied to the way work gets done (more about this in Chapter 6).

Lean Project Management

Mike first wrote about Lean Project Management in Lean IT—Enabling and Sustaining Your Lean Transformation. ¹⁸ He found that much has been written on applying agile (Scrum) methods to project management, ¹⁹ but less has been shared on how project managers can apply core lean concepts to their work practices. This topic is essential because so much of what we do in the world of IT revolves around effective project execution—the purview, the raison d’etre of project managers.

Most project managers have formed their understanding of project management practice through on-the-job experience and some form of for mal education and/or certification. By far, the most common source is the Project Management Institute (PMI). ²⁰ At the time of this writing, PMI offers many project management certifications ranging from Project Management Professional to Agile Certified Practitioner. There is no lack of information in PMI’s collection of project management best practices. ²¹ That being said, we find that the majority of practices concentrate on prediction and control and are not conducive to lean thinking and behavior. We believe planning activities often facilitated by project managers are critical; however, they often devolve to a level of granularity that is neither possible nor helpful. Project managers often struggle with knowing when, where, and how to flex the plan.

In 2012, the PMI introduced a new certification, Agile Certified Practitioner, in response to the huge demand for knowledge on how to apply agile tools and practices to project management. The training was a response to the firmly established Certified Scrum Master training offered through the Scrum Alliance ²² and added an experience requirement (1500 hours working on agile project teams or with agile methodologies) to distinguish itself from the latter. Many resources are available online and from both organizations to compare the two certifications. ²³

Control versus Discovery

As we will explore in detail, the essence of all lean thinking is fact-based discovery and conscious adjustment (check/adjust) based on the reality of the current situation. Traditional project management emphasizes the execution of a fixed project plan. A colleague pointed out that a fixed project plan might actually be a symptom of fixed constraints around the plan that lead to a reluctance to flex as discoveries are made. What may be fixed are our goals, measures, and expected results (and possibly our reluctance to bringing the customer along when new things are discovered).

Of course, there is no way to know precisely what steps will be required to complete a journey when the journey has never been taken. ²⁴ Lean project management emphasizes the power of discovery and anticipates that project schedules and deliverables must change based on the real-time learning taking place as the work is done.

The centerpiece of most projects is the project plan—often a Gantt chart, which attempts to identify all the steps that need to be accomplished in order to deliver the project on time, on budget, and with the promised results. Project plans can tend to take on a life of their own as 1000+ line spreadsheets are only viewed by project managers. In fact, a great deal of time is invested (some would say wasted) gathering status updates and updating schedules. In terms of lean, much of this activity is non-valueadded work! ²⁵

At the heart of lean is team-based problem solving and learning through experimentation. Instead of project managers enforcing standard practices on running a project (status reports, time sheets, percentage completion estimates, etc.), the focus shifts to enabling active and rapid learning cycles. Notice a common theme here? Learn-as-you-go is a central theme in agile development, kanban, continuous delivery, lean startup, DevOps, and all things lean!

Agile Project Management

The focus on applying agile techniques to project management practices is well and good, but there is perhaps an even more impactful use of lean thinking when it comes to project management practices: the role of the project manager as lean coach and value stream advocate. As agile techniques have proven to be effective in many environments, many project managers have been banished as self-directed teams have said, “We don’t need you!”

We strongly disagree. There is certainly a place for an effective project manager on agile software development, infrastructure, process improvement, and change management teams. Agile teams need to ask, “What is the role of the Project Manager in this environment?” The impactful use of lean thinking for project management is for the project manager to take on the role of lean coach and value stream advocate.

When the term agile project management ²⁶ is used, it typically implies the application of core lean (agile) concepts including:

• Customer value focus—As we’re sure you’ve noticed, a central theme of lean is creating value for the customer and stakeholders. Agile project management stresses this concept and the supporting principle of systemic thinking: All activities that make up the stream of events that deliver a product or service ²⁷ are interrelated and interdependent. You cannot change one element without impacting one or more of the other elements. Project managers who appreciate this insight play a key role on the team, ensuring that people see the whole and avoid local optimization at the expense of enterprise.
• Emphasize the business problem—Someone once said, “All IT projects are business projects or they should not be performed!” We endorse this sentiment and believe the key message is that it is the business problem/opportunity that informs the IT project and not the other way around. All too often, we see IT project proposals that are rich in technical benefits (e.g., a database upgrade, ²⁸ more robust connectivity) that fail to identify and advocate for the business benefits the project will deliver.
• Collaboration—Shared learning is at the heart of any effective team. Very often, informative communication is an elusive objective. Anyone who has ever endured a project planning meeting or weekly status meeting can attest to this! Agile practices popularized daily standup meetings (also called Scrums or huddles) that have significantly increased collaborative discovery, commitment, and timely communication among team members and project stakeholders.
• Value creation over task execution—We’ve all been on projects where there was intense focus on task completion at the expense of value creation and emphasis was placed on documented precision, not actual reality.

  Agile project management is about acknowledging that the project plan is a static snapshot of our understanding of the problem or opportunity right now. The focus is on accuracy over the life of the project, not precision at any given point in time. We expect our understanding to change as we validate our speculation on how to proceed (see the section on Lean Startup and validated learning). Instead of mindlessly following a plan that we know is based on an incomplete understanding, we anticipate the plan will change as we learn more.

• Plan-Do-Check-Act—Building on the concept of learn-as-you-go, agile project management is applying the scientific method of learning to make course corrections grounded on fact-based discovery. This cycle is often referred to as PDCA. ²⁹ Although this model is well known, it is deceptively simple and quite difficult to accomplish effectively. We’ll explore PDCA thinking throughout this book.
• Changing role of the project manager—Lean project management extends agile project management practices beyond methods and tools and moves toward the realm of lean coaching. In a lean enterprise, project managers take on a more extensive role of coaching team members to apply new ways of behaving in order to learn for themselves how lean IT impacts the entire organization.

Lean IT Frontier

Since the release of the Agile Manifesto in 2001, the world of IT has seen a storm of innovation in how ideas are tested and validated, software is developed and released, teams are organized and led, and projects are managed. With the gains of agile, kanban, virtualization, cloud computing, Big Data, and Lean Startup, the time has come (at last) to explore how lean IT can transform IT as a key enabler of business results. These various disciplines of IT practice can be united to create a unified field theory with which to ignite an IT transformation! We will share examples of what has worked for others and for us, while providing a framework based on our lessons learned over 30 combined years of experience applying lean in IT, service, manufacturing, and healthcare environments.

Notes