The Essence of Agile

E IL G Embracing Agility Means Agility by the Business, for the Business NCE OF A SE THE ES

Author By Nidhi Srivastava Global Head, Consulting Practices, Tata Consultancy Services The push for agility in software development started nearly 20 years ago. But today, with technology becoming essential to the way business is delivered, agility in the IT function alone is not enough. To make much faster changes in their product, service offerings, and the business processes that support them, companies need to implement agile principles and approaches throughout the enterprise. Enterprise agility encompasses all components of an enterprise’s design and management: its strategy, people, processes, technology, and infrastructure. The goal is to deliver what customers want, and to continuously adapt to market and customer changes. As with all transformations, this is a tall order. It involves altering the DNA of the organization, and how it senses and responds to the marketplace. Asking every function in a large organization to adopt agile principles all at once is a huge undertaking likely to produce both false starts, occasional resistance, and cynicism.

This is the holistic challenge of embracing enterprise agility to create a flexible, adaptable, responsive, and more competitively fit organization. Achieving enterprise agility takes commitment. It means investing in people skills, in new tools and technology, and in a workplace organized to encourage teamwork. It requires making the organization’s culture flatter. It calls for adjusting decision-making styles, including the speed at which people make them. It means spending time and resources on change management to sustain these new ways of working. The effort pays off. Enterprise agility improves collaboration. It leads to a higher quality of products and services delivered. It speeds time to market for those offerings. It improves processes for creating demand (through marketing, sales, and R&D) and for generating supply (through production and distribution). It strengthens customer service. It boosts productivity.

And the need for enterprise agility is clear. Established companies are learning that digital startups have three distinct advantages that enable them to make rapid inroads into markets once ruled by incumbents. These digital natives: 1. Do not have to compete on the same terms, with the same strategies, business processes, and legacy systems as incumbents to pursue market opportunities. (For example, to compete with taxi services, Uber and Lyft do not have to maintain a fleet of vehicles.) 2. Can develop digital systems far more rapidly, 0 using testing, and data from customer trials to ensure 0 1 1 0 a higher likelihood of success. (Consider Amazon’s 0 continual adjustments to its web store offerings.) 0101010 3. Typically develop these digital systems rapidly 10101010101 using lean-agile approaches (as do Airbnb, Spotify, 010101010 and Google, among others) rather than traditional, sequential, time-consuming waterfall project management. While the business urgency to create an agile enterprise is clear, it’s unrealistic to ask every executive running every business function to adopt agile approaches immediately. Eventually, organizations that wish to compete in a digital world will have to embrace agile as a new way of working, but because the transition is a significant shift in how business process and product managers operate, and what they value, asking them to do so at once is likely to be met with resistance.

Area Traditional Organization Lean-Agile Organization Organizing € Leaders delegate € Leaders empower People € Traditional hierarchy € Flatter organization Culture and € Strictly defined roles € Self-organizing teams Process € Structured groups with € People develop skills to take on assignments multiple roles Tools and Monolithic architecture Modular architecture with Technology micro services Infrastructure Figure 1: Differences Between Traditional and Lean-Agile Organizations A better approach to an enterprise’s The road to any large endeavor agile transformation begins with a begins with a thoughtful assessment tight focus on a core set of activities to determine where to begin. within a business function, making those activities agile, and then Where to Begin demonstrating their benefits to the Deciding which part of an enterprise rest of the organization—and then to make agile first should start with an replicating that work elsewhere to scale agile readiness assessment to identify it across the organization. We call this the business area best positioned embracing agile at the core of value to adopt agile practices. This area generation for the enterprise, and will become the agile pilot for the using success to enable change to enterprise. And as agility depends upon ripple across until it transforms the a foundation that makes it possible entire business. to develop and test new products and services iteratively and quickly, this determination should start with

Company Business Activity with Focus on Agile Reason for Focus 1 PayPal Product development Shift from projects-based work to product focus to emphasize team accountability to quality customer experience Kraft Foods2 Marketing Changing consumer behaviors required faster metabolism; real-time decision- making for defining consumer targets and communicating marketing messages 3 Zappos Customer service application Strengthen the company’s reputation for quickly responding to customer requests for information about goods for sale, to generate more loyalty and future business Figure 2: Examples of Companies That Have Embedded Agile in Their Business an examination of the existing ways before it adopts lean-agile principles, in which people are organized, the along with the characteristics that culture in which they work, and the describe organizations and functions processes, technologies, and tools they after they have adopted them. use to accomplish that work. A critical consideration in discussing Figure 1 provides a simplified view. It how enterprises become agile is noting includes characteristics in place that that it is not an all-at-once proposition. describe a traditional organization Figure 2 shows how companies have (or functions within an organization) incorporated agile techniques in parts of their businesses to meet specific business needs. 1 TechTarget SearchCIO, Four Pillars of PayPal’s ‘big bang’ Agile Transformation, August 2014, accessed March 13, 2018, http://searchcio.techtarget.com/feature/Four-pillars-of-PayPals-big-bang-Agile-transformation 2 Forbes, How Data Nourishes Agile Marketing at Kraft Foods, October 26, 2014, accessed March 13, 2018, https://www.forbes.com/sites/avidan/2014/10/26/how-data-nourishes-agile-marketing-at-kraft-foods/ 3 Fast Company, How Zappos Uses One Week Work Sprints to Launch Big Projects Fast, July 11, 2014, accessed March 13, 2018, https://www.fastcompany.com/3032947/how-zappos-uses-one-week-work-sprints-to-launch-big- projects-fast

Performing an agility assessment calls for analyzing the organization’s work activities and separating them into two categories: AAAA Pattern A applies to the parts of the organization AAAA working on software development, maintenance, and operations. This includes areas such as IT, operations, AAAA and quality assurance testing. These IT-centric functions AAAA are poised to adopt lean-agile principles as well as agile AAAA methods and practices. By lean and agile principles, we 4 use the terms outlined in the Scaled Agile Framework: AAAA € Respect for people and culture, in which people perform work to benefit customers; € ‘Flow’, describing how teams achieve optimized work pr ocesses to create continuous and sustainable value; € Innovation, in which producers create new products for customers to validate; € A focus on relentless improvement. Agile methods include scrum (in which the product owner works with team members to identify priorities for development), sprints (periods lasting a set period Scrum of time in which the team develops minimally viable products to test), and stand-up meetings (daily, or regular team meetings to get fast status updates). Sprint While in most organizations it’s common for Pattern A activities to occur in IT-centric functions—after all, agile began as a software development movement— they can also occur in other functions. Some Stand-up meetings companies will find these activities in sales (such as with a customer app), or in HR (if recruiting is central to that company’s business model). 4 Scaled Agile Inc., Lean-Agile Mindset, November 17, 2017, accessed March 13, 2018, http://www.scaledagileframework.com/lean-agile-mindset/

BBBB Pattern B applies to business functions such as BBBB strategy and planning, marketing, finance, HR, R&D, learning and development, and others. These BBBB functions are well suited to adopt lean-agile principles, BBBB but not necessarily all agile methods. The adoption BBBB of agile methods and practices should be reviewed BBBB for their applicability and real benefits, as opposed to force-fitting agile to proven business processes. Selecting an Agile Pilot Project The next step after identifying the area of a company to make agile is selecting a pilot project. An ideal pilot project should be neither too short (to be credible and representative) nor too long (so the company can see timely outcomes and benefits). We typically recommend three-month pilots, giving the company sucient time to inspect, adapt, and adopt lessons after four or more iterations during the project. The pilot project should matter to the larger organization—but not be a top priority. Top priority projects will place too much pressure on a project team engaged in what is also a learning exercise. On the other hand, unimportant projects will not gain adequate commitment by participants, and will fail to establish credibility for lean-agile approaches. A successful pilot project provides proof that lean-agile practices are valuable. It demonstrates to leaders and the organization that they can execute an agile project in the company’s core. With a successful pilot complete, it’s time to build on that experience.

Scaling vertically along the organization and horizontally across the organization .) , c Business Unit 1 Business Unit 2 Business Unit 3 , et es with AD ticeSS, DProducts Products Products , L e ile pracPrograms Programs Programs g tically along the businessTeams Teams Teams er ean and A o scale v Horizontal functions spanning across the business units (for i.e. HR) T adopt Lscaling methods (SAF To bring agility in the horizontal functions, adopt lean-agile principles Figure 3: Scaling Agility Across the Enterprise Spreading Lean-Agile Practices to Other Areas The decision to bring the benefits of lean-agile practices to other areas of the company typically requires choosing between two paths. To spread agile approaches across an enterprise, companies either can scale lean-agile practices vertically within a business unit or horizontally across business units. Vertical scaling within a business unit calls for adopting lean and agile practices using proven frameworks. Scaling methods such as the Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined Agile Delivery (DaD) are all well-established examples of frameworks that companies can follow to promote and propagate lean-agile practices and methods. For example, a retailer could first adopt agile for its portfolio of merchandising products in a particular value stream (the steps required to make goods for available for sale, and then sell them). Next, it would adopt agile methods and practices for supply chain products related to the same value stream.

Horizontal scaling would follow a similar pattern by emulating the successful experience in the company’s core in a different business unit, bringing lean-agile practices to the new functional area. For example, a company could begin in its development organization, and then bring lean-agile principles to operations, and later to customer service. Whether scaling horizontally or vertically, success factors include: DCreating a competency pool within the organization using a construct such as an agile center of excellence where talented staff can practice agile principles and methods, and be available to work on subsequent projects. This can help a company disseminate agile approaches effectively. DBusiness support. The goal of spreading lean-agile practices throughout the enterprise is nothing less than a thorough transformation. In our experience, agile enterprise transformation succeeds best when the business drives changes, and IT works as an equal partner. DBuilding cross-functional, agile teams with people possessing the authority to drive change. Cross-functional knowledge will help the team to spread agile ways of working when the company moves from a pilot project in one area to adopting agile ways of working in another. This team will create clarity for stakeholders, defining both the roles they play, and the work they do. To initiate the journey to spread agility to other parts of the organization, start by using the agile readiness assessment to identify areas for improvement that are well positioned to adopt the new practices. Then prepare a transformation roadmap, for second, third, and more projects, and functional areas. Organize teams around value streams in the business area so the team’s work is focused on projects valuable to customers (whether external or internal). Invest in coaching to help teams learn lean-agile practices and methods. During projects, inspect results and adapt accordingly. Review progress according to relevant business metrics. Track outcomes. Conduct regular retrospectives to identify project areas that met or exceeded their goals, and those that could be improved. Correct course and adapt as required to meet the company’s objectives.

Results from the Field The examples of two companies that disseminated lean-agile principles across their organizations illustrate the kinds of benefits others can expect. Example 1: A large Australian energy company Problem: Challenges included new energy options like solar and wind, stiff competition from new market players and new energy regulations giving customers more choice in providers. Solution: The energy company adopted agile across the enterprise with the goal of reducing time to market for new products to support frequently changing business priorities. It increased its capability to develop fit-for- purpose solutions to compete in its market, and prepared for a major digital transformation. Driven by its CEO and CIO, the company’s initiative reorganized business and IT based on customer experience value streams. The company established capacity-based agile teams with a ‘core and flex’ model (core team members were helped by people with right skills added as needed). It made investments to improve collaboration, including redesigning the work floor, and strengthening the technology infrastructure to support distributed agile teams. It automated software development and operations activities using DevOps practices. Results: The company achieved a 90% reduction in deployment time for software products, a 40% reduction in production incidents that could lead to disruptions, and faster resolutions of application problems, leading to higher customer loyalty.

Example 2: A large U.S. retailer Problem: Traditional project delivery methods were unable to meet business expectations for quality and timeliness. Functional silos dominated. Too many interdependencies among applications meant that software products depended on other software products to work—making them unreliable and inecient. Solution: Reorganized the enterprise, transforming it into a business portfolio-based product organization. It switched to agile and Scaled Agile Framework delivery methods across all business lines. A technology refresh included infrastructure upgrades that supported automation, including DevOps. New work spaces were created to improve collaboration and agility for business stakeholders and development teams. Results: The retailer saw an eight-fold increase in annual product deployments. New product features reached the market 40% faster than before. Production problems fell by 20%. IT costs dropped by 20%. And IT infrastructure improvements led to a 95% reduction in lead times needed for providing required resources. Time for an Agile Enterprise Lean-agile is a proven approach being adopted by all types of enterprises. For companies facing new competition, especially from non-traditional, digitally native companies, not pursuing lean-agile is not an option. When starting this journey, draw the vision for agility at an enterprise level. Every company is unique, so, where to start and how to scale will be different for everyone. But prioritizing the need for speed is always the same. Then experiment, learn, and adapt. And do not look for perfection; do not fear failure. In agile terms, failure is an opportunity to learn, refine, and improve the organization, and the result. Fail quickly. Learn. And then go fast.

E L I G A How to Make Location- F Independent Agile Work Authors K. Subramanian Head, Delivery Excellence, Tata Consultancy Services Mohammed Musthafa Soukath Ali NCE O Head, TCS Agile Initiative Network, Tata Consultancy Services SE While it is very beneficial to have all the team members of small agile teams co-located, insisting on having all inter-related agile teams in the same location is not worth the effort and is unrealistic in today’s global business environment. In fact, in the last article of this issue of Perspectives (“Why Your Agile Team E ES is Better Off Dispersed: The Case for Location-Independent Agile”), TCS makes the case that agile programs whose teams TH are distributed can more quickly develop new processes and systems that are more on target with customer needs. In our own work, we have observed several hundred projects that use location-independent agile teams. Given the challenges involved, it is clear that one way of working does not fit all projects. For example, some projects may be best suited to having agile teams co-located, at least at first, while others may succeed best with contributions from different agile teams in many places. Companies that are new to agile approaches can also benefit from starting with co-located teams as they work to build distributed capabilities. Which model a company

chooses will depend on a variety of factors, including the business knowledge needed and where it resides, whether the work is urgent or has non-negotiable constraints, and the maturity of the organization’s agile development processes. There are three aspects to successfully implementing location-independent agile teams: 1. Assess the organization’s distribution of business expertise, the nature of work, and agile maturity. 2. Choose the right agile working model to meet the organization’s needs. 3. Continuously improve the agile capabilities of the teams to gain the benefits of location-independent agile. First: Assess the Organization 11 Use the three criteria referenced above to determine the organization’s capabilities for location-independent work. Answer these questions: € What is the level of business expertise and other skills required, and to what extent do they exist at a specific location? If a location lacks business expertise, it will require more of it to be able to support agile teams there. As team members accumulate experience, they will build business knowledge, making them both more valuable, and more able to work as part of a distributed organization. € How urgent and volatile is the work? At first, location-independent agile teams should focus on work that is neither urgent nor volatile. If the work is both, if it has non-negotiable constraints (such as overnight fixes, intra-day scope changes, or regulatory requirements), or if there is a need for constant access to the project owner, it’s best to work with teams in the same location, if at all possible. € How mature is the organization? When teams are relatively new to agile approaches, team members should be co-located. Having a common understanding of agile culture, especially among the leadership, indicates the organization can succeed with location-independent teams.

Having a clear understanding of the organization’s starting point will point leaders to select the best approach for moving forward. Second: Choose the Right Location Model 2 We have identified four potential models for organizing agile teams, ranging from teams that should start in the same location to those that can be effective in a highly-distributed arrangement (see Figure 4). Descriptions of the models follow: Local (Model 1) This model is best when the teams are new to the business area, when continuous access to a product owner is paramount, or when regulatory concerns require the project to be executed in a specific geography. However, when a project or program is ready to scale up, enterprises will need to consider evolving to one of the other models. Minimally Distributed (Model 2) The product owner and a few members of a project or program are located together as one team, while the rest of them work together as another inter-related team in a different place. This model requires the teams to understand the underlying business processes for their product. They will still need frequent access to the product owner and infrastructure teams for business decisions and infrastructure privileges. When it’s time to expand the project or program, enterprises using the Minimally Distributed model will need to adopt one of the remaining two models for quick on-boarding of talent in additional locations.

Location-Independent Agile Model Model 1 Model 2 Model 3 Model 4 Business Knowledge Not Medium to High High at Distributed Location Applicable High Nature/Criticality Regulatory/ All Except All Except All Except of Effort Urgent/ Regulatory/ Regulatory/ Regulatory/ Volatile Urgent/Volatile Urgent/Volatile Urgent/Volatile Organization’s Nil Low to Medium High Experience in Agile to Low Medium to High Way of Working Figure 4: Four Models of Location-Independent Agile Significantly Distributed (Model 3) The product owner and few members of a project or program team are located together as one team, while other teams working with them reside in multiple locations. Enterprises that have already distributed teams with a shared understanding of the business processes of a project or program are well positioned to adopt significantly distributed agile work processes. This model not only offers the scale for enterprises to deliver large programs as well as frequent releases by increasing their access to the right talent, it also provides for business continuity. Fully Distributed (Model 4) The product owner may be at any site, while the rest of the project or program team members are grouped in agile teams across distributed locations. These teams each include product specialists with sucient business knowledge to drive day-to- day decisions within a framework defined by the product owner. A Fully Distributed model is useful when enterprises need to empower teams with independent decision-making capability, such as when business experts do not have enough bandwidth to drive product leadership on a daily basis.

We have observed that many work in parallel across time zones, an organizations experience dramatic organization can accomplish more in benefits after successfully deploying the same time than co-located teams one of these four location-independent that are limited by an eight-hour agile models. For example: work day. Leveraging 24-hour, five- days-a-week development coverage € Location-independence makes an with significantly distributed (Model enterprise more agile. Using the 3) teams across U.S., India, and Mexico, minimally distributed model (Model a large financial company was able to 2), a large U.S. retailer with a delivery cut the time it took to introduce new team of 1,500+ members in India products to market by 78%. € reduced its IT operations costs by By sharing skills across multiple teams 20% and improved end customer in different locations, companies can satisfaction by 40% in 18 months. accelerate work without requiring These benefits resulted from a business experts to participate in daily combination of steps, including decision making. One U.S. retailer role rationalization, product re- was able to complete an integrated architecting, and the application of channel delivery project in just 11 DevOps practices for automating new months with fully distributed teams product deployment. (DevOps is an (Model 4) by leveraging the domain approach to IT software development skills of product specialists in many and operations that emphasizes locations. While product owners still automation to speed up software have to make prioritization decisions building, testing, and installation.) and confirm product acceptance, € Location-independence makes an they can delegate significant enterprise more productive. By using amounts of knowledge work involved all 24 hours available to execute in product development.

Third: Improve the Agile Capabilities of Teams 3 Organizations that want to move from the Local model to one of the location-independent models can improve their agile capabilities in five ways: 1. Build business knowledge-oriented teams at distributed locations. Consistently seek to optimize each team’s product and business expertise by promoting the team structure around business concepts. A U.S. retailer was able to move from a fully co-located model to a minimally distributed model in three months by relocating some experienced team members with business knowledge to another location, and leveraging their expertise to form a new team around this business knowledge. 2. Configure teams to take advantage of time-zone differences. F or effective collaboration and communication, agile teams need a minimum overlap across time zones. Calibrate each team’s work hours so that as one team heads home, another team can pick up the work, with enough time for communication to ensure it continues at a steady, sustainable pace, with minimal confusion. Take the experience of a leading U.S. bank as an example. The bank had one team in Texas, and another in Chennai, India. The teams adjusted their hours to overlap based on how much time they needed to resolve their interdependencies. They became motivated to improve how they worked to reduce the number of overlapping hours they needed. 3. Minimize planning overhead. An Australian retailer synced up the sprints and product releases of its three agile teams, reducing the teams’ planning time by 20%. To achieve such results, it’s critical to automate as much of the teams’ work as possible using DevOps automation and design engineering practices.

4. Create a ‘one team’ culture. T eams across the enterprise should use the same agile practices, same work and infrastructure privileges, and share common work characteristics. Culture coaches can help geographically distributed teams understand and appreciate their cultural differences, ensuring the teams have healthy working relationships. 5. Pl an the right distribution of work across locations. Organize the work to minimize dependencies across teams while maximizing workflow. At a European telecom provider, software development teams were originally aligned on horizontal areas such as routers and signal processors. When it created agile teams, it restructured to focus on business features such as customer gateways, thereby reducing dependencies among the horizontal areas and enabling more frequent and value-added product releases. Overcoming Skills, Process, and IT System Challenges As the scale of change involved For example, instead of having some suggests, aligning multiple agile team members who are application teams located in different time zones developers and others who are testers, and countries is a complex endeavor. train some people to be adept at Challenges may emerge involving both jobs. shortages of the right skills, employees’ adapting to new work processes, and a Legacy ways of working, and employee company’s IT infrastructure. attitudes toward them, can hinder the cultural change needed to pursue agile. To get the most from location- Some employees will have trouble independent agile teams, an enterprise adapting. They can benefit from needs to put people with the right coaching that goes beyond teaching skills in the right places. In addition to agile techniques to practicing new universal coaching and training in agile roles. Hands-on practice will help them practices, one way to do this is to train understand the benefits of pursuing team members in more than one skill. agile approaches to their own work lives.

One important stumbling block to more than a two-week lead time to setting up distributed agile teams is schedule a test, the agile team will frequently the existing enterprise IT fail to meet its deadline and become architecture which may not support demotivated. Furthermore, the ripples agile ways of working. The systems that of that failure will hurt productivity underlie the work of developing and across other teams and degrade the releasing new products must be able company’s ability to innovate. Leaders to handle increased production loads. should assess the strength of the For example, if an agile team has to company’s IT architecture when they produce a product in two weeks, and start planning for agile adoption to the supporting architecture requires identify the necessary improvements. Capturing the Benefits of Location-Independent Agile It is possible to take advantage of distributed agile teams and thereby maximize enterprise productivity and innovation, but companies need to know how to do it correctly. That means knowing yourself—your business expertise, where it resides—and the level of your agile maturity. It also means determining the right location model for your work—local, minimally, significantly, or fully distributed—based on your business’s needs, goals, capabilities, and the competitive landscape. As your organization gains experience, you can move up the ladder toward a more fully distributed model. With advancement comes the opportunity to acquire additional benefits from organizational agility, as well as the ability to compete more successfully on a global scale.

Q A From Making Autos to Making Software: The Evolution of Lean and Agile Interview with Dr. Michael Cusumano 5 Michael A. Cusumano is a professor at the Massachusetts Institute of Technology’s Sloan School of Management in Cambridge, Massachusetts. For more than 30 years, he has conducted research and taught classes on software company strategy, product development and entrepreneurship, as well as (early in his career) manufacturing and product development methods in the automobile and consumer electronics industries. He has published 13 books and more than 120 articles and columns on these topics. His latest book (Strategy Rules: Five Timeless Lessons from Bill Gates, Andy Grove and Steve Jobs, published with David Yoe in 2015) has been translated into 17 languages and received widespread media acclaim. He has also lectured and consulted to nearly 100 organizations around the world. In the last two years, Professor Cusumano had been on leave from MIT and served as VP and Dean at the Tokyo University of Science. Because of his extensive studies over the last four decades on software development, product development, manufacturing, and (more recently) software business strategy, he possesses unique insights on technology and technology-based business strategy and product development. 5 Michael Cusumano, MIT Sloan School of Business, Faculty and Research, accessed March 15, 2018, http://mitsloan. mit.edu/faculty-and-research/faculty-directory/detail/?id=41459

TCS: Your research on lean management practices dates back more than 30 years. Can you tell us about the genesis of lean thinking? Michael Cusumano: As part of my doctoral thesis on the Japanese automobile industry, and eventually for a book I published (The Japanese Automobile Industry: Technology and Management at Nissan and Tokyo, Harvard University Press, 1985), I analyzed the Toyota production system in the 1980s. I studied their productivity at the company level—units [outputs] per company as well as value-added—and I adjusted for things such as labor hours, capital investment, and capacity utilization. Toyota was producing vehicles with half the number of people [used by the American companies], but with the same amount of capital equipment. That was interesting. So what was ‘lean’ at that time was the number of people. Then, a student of mine—John Krafcik, who was working on his master’s thesis here at the MIT Sloan School— studied the Japanese production system at a more abstract level. John took this thinking to the assembly plant level: What was productivity like there? What degree of automation did they have in the assembly plants? What management practices did they use?

Q A A number of us here at MIT worked on this research and debated what was the right term to describe these management practices we saw at Toyota. John came up with the term ‘lean.’ Today, he is CEO of Google’s automobile self-driving subsidiary, Waymo. At that time (1988), John published a companion article to mine (on Japanese manufacturing innovations) in the MIT Sloan 6 Management Review called ‘The Triumph of Lean.’ That started the whole thing. Since then, lean has been applied to everything under the sun. But the original idea was doing roughly the same amount of work in terms of having the same number of outputs or products, with much leaner staff. A book that came out in 1990, The Machine That 7 Changed the World [by the three co-directors at the time of MIT’sInternational Motor Vehicle Program, James Womack, Daniel Jones, and Daniel Roos] documented that the Japanese car makers were assembling cars in less than half the time the U.S. manufacturers were—12 hours vs. 25 hours. 6 MIT Sloan Management Review, Triumph of the Lean Production System, Volume 30, Fall 1988, accessed March 15,2018, https://www.lean.org/downloads/MITSloan.pdf 7 Amazon, The Machine That Changed the World, 1990, accessed March 15, 2018, https://www.amazon.com/ Machine-That-Changed-World-Production/dp/B007ZHTZ8Y#reader_B007ZHTZ8Y

TCS: By the mid-1990s, your research Their heavyweight projects might began focusing on product development appear lean if you look at them in the automotive sector. Tell us more individually. But if you look at a about that. company with a portfolio of products, Cusumano: One of my doctoral the Japanese heavyweight project students at the time (Kentaro Nobeoka) management teams were too self- and I studied automotive product contained. They weren’t sharing very development. An earlier study by two of much. So it was actually becoming our colleagues (Kim Clark and Takahiro expensive for them to develop new Fujimoto, who published the research automobiles. Nobeoka and I wrote in their book Product Development more about that in our 1998 book8 Performance), found U.S. automobile (Thinking Beyond Lean). companies were generally taking 60 to 64 months to develop a new vehicle. TCS: So then you shifted your research on The Japanese were pretty close to a automotive manufacturing and product 48-month schedule and doing it with development to the software industry. Tell about two-thirds the engineering hours. us more about that. Cusumano: I actually shifted my But we had identified a problem in major research emphasis to software our research in the mid-1990s: The engineering even before I published Japanese automakers had become my first book in 1985 on the Japanese in many ways too lean. They weren’t automobile industry. Large-scale sharing much technology across software development became my projects within the same company. main focus from 1984. 8 Amazon, Thinking Beyond Lean, September 4,1998, accessed March 15, 2018, https://www.amazon.com/ Thinking-Beyond-Lean-Transforming-Development/dp/0684849186#reader_0684849186

Q A When I wrote my doctoral thesis at project management, and so on— Harvard in the early 1980s, it was clear to large-scale industrial software. to me that the next future challenge for Japanese companies would be writing I found most were taking IBM software. In a post-doctoral project I did approaches to software development. at Harvard Business School from 1984 There was nothing lean about it, by the to 1986, half of my time I spent studying way. It was almost the complete opposite consumer electronic projects with a of lean or what we would today call agile. Harvard professor, Richard Rosenbloom, and the other half I spent studying TCS: So it was true waterfall approaches Japanese ‘software factories’—i.e., to software development? largely how the big Japanese computer Cusumano: It was very waterfall. manufacturers such as Fujitsu, NEC, and However, Japanese software developers Hitachi developed their software. were good at quality. But they didn’t have a good business model for making Then I published a book in 1991— money from the software itself. They called Japan’s Software Factories—on were essentially selling hardware who started the factory idea, how like IBM had done for many years, they evolved, and so on. The Japanese building operating systems and some essentially copied how U.S. computer applications. But they didn’t really know manufacturers like IBM ran their own how to make money from software. software development centers in the 1970s and 1980s, because the After this study came out in 1991, from Japanese companies were mostly being very interested in software and making IBM-mainframe compatible the new personal computers, I decided hardware and software. I got interested to ‘follow the money,’ as I like to say. in the question of whether Japanese Who was actually making money from companies could apply the expertise software? It was Microsoft. Yet nothing they had accumulated in manufacturing had really been written about how and engineering—quality control, Microsoft developed software.

In 1992 or so I suggested to an IBM person (Stan Smith), who was doing a master’s thesis under me at MIT, that he write his thesis comparing mainframe and PC software development. So he compared IBM and Fujitsu with Microsoft and Lotus, and got an interview at Microsoft, and I went with him there. When I heard the story of how Microsoft was developing software, I immediately knew this was very, very different from the waterfall world of software development that I had learned. Almost all the principles of agile development— Microsoft was doing back then. They just didn’t call it that at the time. So I immediately pitched a book to Microsoft, which eventually had to be approved by Bill Gates, which he did. I co-authored it with a professor of computer science, Richard Selby, because Stan went back to IBM. [Cusumano and Selby published the book, Microsoft Secrets, in 1995.] TCS: So what did you learn about the ways that Microsoft developed software in the 1990s? Cusumano: Since this interview is about lean and agile management approaches, I think you’ll find this interesting: Almost all the principles of agile development—Microsoft was doing back then. They just didn’t call it that at the time.

Q A They did certain things differently. But the basic tenets of daily builds, continuous integration testing, working around small chunks of code, features, small feature teams—Microsoft developers were all doing those things. I must note that the company wasn’t doing this in all of their [product] groups. But they were doing it in their best groups—Excel and Word, among them. The Excel group pushed these techniques the furthest. Eventually all development groups in Microsoft adopted these practices, with some variations. We never called it ‘lean,’ but they thought of themselves that way, especially when they compared themselves to IBM. TCS: So now we circle back to agile development. When you look at your research over the last 30-plus years, starting with manufacturing and product development processes in the auto industry, and then moving to software development and software business strategy more recently, are there any principles in developing and making cars that transcend to software?

Cusumano: At a higher level of If you look at waterfall vs. agile/lean principles, there are a half-dozen points methods, or what Selby and I called the that I make. The most critical one is ‘synchronize-and-stabilize’ approach, about waterfall’s sequential approach which is the name we used in the to development vs. doing things book about Microsoft, the company concurrently or in parallel. In both was doing a lot of things in parallel. cases, when you do things sequentially They would start writing code before it’s going to take a longer time. they had a complete specification. Sometimes they never got a complete So why was GM’s product development spec. They would start integration cycle 64 months back then? It was testing as early as possible; they didn’t because of the way they scheduled wait to test a system until the end. things. They had certain bottlenecks and couldn’t do certain things in parallel Another thing we found was that there because they had never tried to do could be a lot of wasted effort if you them in parallel. When we looked at have to redo a lot of work. If you built how the Japanese auto companies got a prototype of a software product and product development down to 40-42 showed it to customers early, you could months, they were doing a whole eliminate a lot of those changes later bunch of things in parallel. For example, on. Even if you were doing a lot of what they were starting their manufacturing seemed to be re-work, or fixing bugs, preparations and die manufacturing early by throwing code into integration almost concurrently. They were sharing tests early, you were still saving yourself information with the different teams. a lot of time in the end. As soon as they could figure out the dimensions of a car door, the die guys Firms that did early prototype-driven would start working. They didn’t wait development—and not just throw-away until the whole car was designed. So they prototypes—but working prototypes, started overlapping a lot of those phases. and then did small incremental but frequent builds, and continuous design

Q A and coding reviews ended up with Netscape was just posting new versions higher productivity and better software of Navigator on its website and you quality than software developed downloaded it. So we saw at Netscape through waterfall-ish approaches. that they would have new releases every week, or every other week. That was a TCS: So the last thing we come to is the completely different way of developing topic of building software for Internet and releasing software. In Microsoft, applications. You’ve written about this those would all be internal releases. In too, starting 20 years ago, comparing Netscape, they were public releases. how one of the early Web browser companies (Netscape) and Microsoft Microsoft came up with its own browser competed against each other in the early (Explorer), but the first couple of versions days of the Web. weren’t very good. But by version 3 Cusumano: When Netscape came to they had caught up and Netscape got market with one of the first Internet bogged down. Netscape had added all browsers (Navigator), they had basically these features around the browser and copied some of Microsoft’s practices. they were not as disciplined as Microsoft. They were doing daily builds, for So eventually the daily builds wouldn’t example. But one of the things that was work. They had around 30 million lines very different with Netscape is that they of spaghetti code; those are the phrases weren’t printing software on disks and Netscape engineers used internally. putting disks in boxes and shipping boxes to stores and that kind of thing. So Netscape did things too fast and They weren’t delivering software that they were not very disciplined at way. They also weren’t necessarily testing. We think Microsoft won the delivering software to PC manufacturers. browser wars because they actually That’s the way that Microsoft delivered had a better browser by the time you software; that slowed the cycle. got to version 3 or 4. And then, of course, Netscape sold itself to AOL, although the code lives on in Firefox.

TCS: And of course, since those early Web days of browser wars, we’re seeing whole industries being upended by the Internet: media, retailing, banking, the taxi, and hotel industries, and many more. What do you think that means for the way companies develop software, and whole Internet-based businesses that of course require software? Cusumano: I must admit that I don’t know much about how these companies develop software these days. But I don’t see software development as a problem for them. Whereas 30 years ago software development was a huge problem, the bigger problem now seems to be their strategy or business model. Perhaps software development is much less of a problem today because people have more knowledge of what good practices are, and that they’ve largely abandoned, although not completely, the old waterfall style. They have become much more careful about how and when they use the waterfall and are more eclectic in methods. In addition, a lot of big companies today have outsourced their software development. That’s another reason why it’s not a problem. These companies may have some lean in-house staffs, but outside specialists are building a lot of their software, although that might be different for defense companies or large banks, or small Internet startups. In general, once companies stopped trying to force square pegs into round holes, or force a methodology that might work for space shuttle software but is not necessary for a smartphone app, then software development got a lot easier for a lot of companies.