Lean Startup

Lean Design & Delivery

Stable Teams

A team is no more than a collection of individuals until they develop a working rhythm. Many organizations are in the habit of frequently moving people around.

But teams should stay together until they reach productivity, which is defined as the ability to deliver finished work in a timely manner. This is also a leadership discipline, as it sometimes requires working through personality issues. Committing to stable teams means paying attention to personal growth of team members and working through issues that arise.

Scaled Agile

Teams using agile practices are autonomous and fast moving and require frequent customer feedback. When we spread these practices throughout an organization, coordination is critical. This means deeply understanding the needs of agile teams and how they fit into larger objectives.

There are large, complicated schematics out there showing how to scale up agile methods throughout an organization. We did not find these useful. Instead, we have used a lean framework along with design thinking tools throughout CI&T and our partner organizations to manage work in a way that is consistent with the spirit and practices of agile.

Short Cycles

This cornerstone is about embracing rapid experimentation. When we have teams breaking their work into segments and then sprinting toward interim goals, we create the ability to quickly test ideas and encourage innovation. The trick is to resist prescribing a completed product. Let the team experi- ment with new ideas, guided by customer needs.

When leaders tell a team, “This is what we want you to produce in the next three months,” the excitement and energy of the team will be stymied. Our teams regularly produce fresh ideas

for meeting customer needs in two or three weeks because they are not given lists of specifications and precise timelines. If experiments do not produce hoped-for results, we lose weeks instead of months.

Pull Production/Continuous Flow

A pull production system is one that responds to the custom- er’s wishes (or pull) instead of internal schedules based on forecasts designed to maximize the use of assets like coders and test equipment. Continuous flow is a system designed to move each piece of work along its path toward completion without delays due to organizational needs.

Put these together and you have a system that works smoothly to meet customer demand instead of guessing at what customers might want next year and then creating the product in batches that build up between functional depart- ments. In software development, the old “push production” meant that we guessed at what products a customer might want, designed the product, built the code for it, and sent it to marketing or sales to push out the door, hoping that it would catch on. When we begin with the customer in mind and then build cross-functional teams to avoid intradepart- mental holdups, we are working toward continuous flow.

DevOps

A compound of development and operations, this practice aims to eliminate the old functional wall between software development and operations (deploying that software). Seeing the two as one continuous cycle enables us to eliminate redun- dancies, pick out the most important — the most customer centric — elements, and automate the rest.

DevOps is what led us to automate software integration and testing in the Azul case study, allowing faster and more confident cycles of development. Quicker software releases meant more customer feedback into the process, which allowed us to better understand what those customers really wanted.

Value Engineering

This is the prioritization of all work tasks based on customer needs. All projects have tasks that will result in creating what the customer really needs and tasks that produce what the customer merely wants. Customers first need, for instance, to redeem frequent-flier points for products as painlessly as possible. Without this, a frequent-flier app is worthless. Redeeming points then is the first order of business for an agile team. It would also be cool to present the customer with bonus points for selecting certain products, such as a special offer for flights that are not heavily booked on certain days. Optional features like this are “wants” that fall further down the development cycle.

Experience Design

This is an investigation of the customer experience with a product. Their experience is the journey they take — from awareness of the product to selection and usage — and how they feel about it along the way. Our job is to understand the job a product is doing for the customer, study how well the product performs, and maximize the good (value) while elim- inating the pain points. We do not know what will make our products easier and more valuable until we understand the role the product plays in the customer’s life.

MVP

The concept of minimum viable products — creating the sim- plest product to meet customer needs first, before adding bells and whistles — is easy enough to understand. But its true power is realized only when MVP is employed in an envi- ronment of short cycles, rapid learning, and PDCA to solve problems. MVP is not an end goal; it is an important concept in the process of building, measuring, and learning.

Lean Management System

If processes change is to be sustained, management must change as well. This is a cardinal rule that is often overlooked. Remember that leading radically different teams — auto- nomous, customer focused, and dynamic — requires a new skill set for managers that must be taught.

We have grouped some cornerstones under the “lean manage- ment system” pillar to guide organizations as they begin train- ing managers for a lean digital world.

Visual Management

We cannot manage or change what we cannot see. This is the central truth behind visual management. If a process attribute such as productivity, cycle time, or error rate is important enough to measure, it should be displayed for all to see. The same goes for work-in-progress. Just as our agile teams display the pieces of work (stories and tasks) in categories — to be done, in process, finished — organizations should post work of any type to allow everyone to see progress and problems.

Transparency has become a popular watchword. Visual manage- ment can be thought of as internal transparency. By being honestand open about how work is done, we can make strides toward removing shame and secrecy and promote problem solving.

PDCA

Plan-do-check-act is a well-known problem-solving sequence. More importantly, it is a management tool. When we teach others how to work through problems using a scientific method, we give them the tools to find and solve their own problems. We recommend using the same PDCA form throughout the com- pany to ensure common understanding. Make sure the PDCA has columns for due dates and to show who is responsible for completing items.

Teaching PDCA is not a one-off task. Anyone in management should expect to coach PDCA multiple times. Sometimes we are introducing the concepts fresh or reminding a person how to work through a certain step. Sometimes we coach to underscore the importance of the discipline and to create clear expectations of how a person should work through a problem.

Production Metrics

We use production metrics to help us see where we are head- ing as well as where we have been. Metrics that we include under this category help us predict user interaction outcomes and business outcomes, such as number of items waiting for user acceptance (this should be kept low to avoid stocking), number of defects, productivity, etc.

Objectives and Key Results: OKRs

Objectives are clearly defined goals. Key results are measur- able benchmarks toward achieving those goals. OKRs were used at Intel in the 1970s and popularized at Google, where cofounder Larry Page said, “OKRs have helped lead us to 10x growth, many times over.”1

Objectives are the big goals, the moon shot, of any project and should be limited in number. Three objectives are the norm in our work. Key results are signals we choose to help us determine whether the objectives are on track. If our obj- ective is to run a marathon, attending regular training ses- sions and showing greater endurance over time would be key results. If training is not accomplished, it is unlikely the marathon can be run.

Lean Leadership Development

Companies that have attempted systemic transformation are accustomed to making bold changes in frontline work processes and management. That’s where the problems are, right? So leaders hire consultants who produce reports about how the front line needs to follow some new rules about how work is delivered. This rarely transforms anything much.

To create and sustain change, leaders must think in two other dimensions: leadership and management. We need to trans- form ourselves from authoritarian leaders into teachers and coaches who enable good work. And then we need to be prepared to ride the wave of change because transformation does not end. It evolves as our needs evolve.

Go-see @ Gemba

Becoming a coach and teacher begins with the simple idea that you do not know everything (or even, probably, much of anything). And there is no other way to learn what you do not know than by going to where value is being produced in your organization, watching how it is done, and asking respectful questions.

This is a discipline that is difficult for anyone who is used to having the answers and telling people what to do. Many of us require the presence of a coach at first, or a colleague who can help keep some of our instincts in check. Leaders who become comfortable learning at gemba must then coach others to do the same.

Once we learn to truly see the work, our fundamental ideas about how to collect information — and about the source of good information — will change forever. This is the ground- work for being able to accurately assess current conditions.

A3/Hoshin Kanri

Chapter 7 explains how we work though A3 in a group setting. But we also use A3 as individuals to solve more focused problems. The A3 guides us to solve problems using the scientific method, and that is its power.

In a lean digital environment, an A3 is one of the most com- monly used tools. It is one of the first stepping-stones most people encounter on their lean journey, and organizations must be prepared to teach and coach everyone in its use.

Shuhari/Learn by Doing

Shuhari, or Shu Ha Ri, is a three-part learning cycle borrowed from the martial art aikido. In the first stage, Shu, a person learns a discipline precisely, following prescribed rules. In Ha, students explore the underlying principles of the rules and

learn to make adjustments. Ri is when students take what they have learned of the discipline and creatively construct new practices to serve their needs.

The shuhari practice can be observed in our use of A3 in hoshin. In the beginning, we applied ourselves to learning and following the A3 rules as established in the Toyota Production System. Then we looked at each section of the A3 and asked, how can we better achieve our objectives? Finally, we experi- mented with design thinking tools to construct new practices. Our experience of precisely following the rules of the TPS A3 in the beginning meant we really understood the purpose of each part of the A3 and could improve our practice.

Now, when we coach colleagues who are new to a practice, we first teach the principles of shuhari so that they understand why we begin with a disciplined approach.