Case Study Link: Going with the Flow: Agile Development at Dell | Harvard Business Publishing Education Access Link: https://hbsp

Going with the Flow: Agile Development at Dell 1

Going with the Flow: Agile Development at Dell

Denis Dennehy, National University of Ireland Galway Kieran Conboy, N ational University of Ireland Galway Janis Gog an, Bentley University

On a chilly February 6, 2017, Flow Project Coordinator Larry Ferreira walked across the large Dell Technologies-Limerick campus, after meeting with Programme Manager Peter O’Dwyer, to talk about an upcoming meeting with Dell’s Systems and Process Improvement (SPI) Board. Ferreira would have 20 minutes to brief the Board on an important initiative, and O’Dwyer informed him that the SPI Board wanted each presenter to succinctly deliver no more than “three key messages” to the Board.

Ferreira worked in two roles: as project manager of a Dell agile software development team, and as the Flow Coordinator. In this latter role, he devoted about 20% of his time to helping 36 software developers master new tools and techniques, collectively referred to as Flow. In Summer 2016 the SPI Board (the top echelon of leadership at Dell Technologies-Limerick) decided to adopt Flow, in the belief that these agile tools and techniques would support Dell’s new software-reliant service- centric strategy. Ferreira believed Flow was well suited to Dell’s globally distributed software development activities. Yet, he feared some directors’ expectations might not be realistic. “They want evidence that we are developing better quality code, faster, but it takes time to master new skills!”

Entering his office and hanging up his coat, Ferreira wondered: what could he say in tomorrow’s meeting, to persuade the SPI Board to be patient and supportive?

DELL TECHNOLOGIES Dell, headquartered in Texas, was founded in 1984 by 19 year-old Michael Dell as a personal computer company. In September 2016 Dell acquired Massachusetts-based EMC in a $67 billion deal. Founded in 1981 as a producer of computer memory boards, EMC expanded into storage devices and systems, content management systems, —————————–

[email protected]

Copyright  2021 by the Case Research Journal and by Denis Dennehy, Kieran Conboy and Janis Gogan. The authors developed this field-researched case for class discussion rather than to illustrate either effective or ineffective handling of the situation. Employee names are pseudonyms but the facts of the situation and company are not disguised. The authors thank CRJ Editor Gina Grandy, Associate Editor Karen Boroff, anonymous NACRA and CRJ reviewers, and NACRA 2020 roundtable participants. This work was supported with funding from Bentley University, Science Foundation Ireland grant 13/RC/2094, and the European Regional Development Fund through the Southern & Eastern Regional operational Programme to Lero – the Science Foundation Ireland Research Centre for Software (www.lero.ie). Contact Author: Janis L. Gogan, Bentley University, 175 Forest Street, Waltham MA 02452-4705 USA, 508-748-1952 .

NA0690

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

2 Case Research Journal •Volume 41• Issue 3• Summer 2021

security software and services, and cloud computing. Both companies had long employed a collaborative approach to product design and development; their engineers collaborated with customers and partners worldwide to design new systems, within the context of an architectural framework for integrating new technologies with existing products. In 2017 Michael Dell (CEO) achieved his long-term strategy – positioning the recently-renamed Dell Technologies (Dell Tech) as an end-to-end computing solutions company.1 Its FY2017 Annual Report2 stated:

We are focused on providing technology solutions and services that accelerate digital transformation, which is the enablement of organizations to maximize their potential through modernizing IT infrastructure, enabling efficient use of IT resources, providing the means to leverage data to make business decisions, refining processes, keeping data secure, and empowering individuals.

With more than 100,000 employees, Dell Tech sold its products and services to large businesses and public-sector organisations, small/medium-size businesses, and individual consumers. After acquiring EMC, its expanded portfolio offered hardware and software that enabled customers to implement private or hybrid clouds, software- defined data centres, and converged infrastructures. Dell emphasized its platform-as- a-service, data analytics, mobility and cybersecurity products and services.

In Ireland, about 2,500 Dell employees worked on three campuses: Cork, Dublin, and Limerick. The Limerick campus (open since 1991) was a strategic global hub that covered five vertical segments: 1) research and development, 2) software and solutions development, 3) service operations, 4) supply chain operations, and 5) finance. Limerick was also home to several EMEA (Europe, Middle East and Africa) operations, including Dell’s EMEA Applications Solution Centre.

SOFTWARE DEVELOPMENT AT DELL TECHNOLOGIES – LIMERICK

After working ten years in Brazil as a software developer, Ferreira joined Dell Tech in September 2016 (shortly before the EMC acquisition was completed), as Project Manager for Team 1 (see Table 1). He came to realize that Dell Tech’s focus on developing state-of-the-art scalable solutions at competitive prices meant that software development was mission-critical, in light of two big challenges in the intensely competitive computing industry: rapid hardware obsolescence and competitors’ rapidly-changing software offerings.

Ferreira’s 8-person team included one member located in India and another in the USA. Team 1 worked on middleware (“bridging” software that connects applications based on different data structures or programming languages).

Other Dell Tech software teams were located all over the world (most in India and the USA, some in Brazil, China and Ireland). Most teams operated on a follow-the-sun model that maximized software development productivity by ensuring that work proceeded continuously around the globe; at the end of each day, a software team in one time zone handed work to a team in a distant time zone.3 Clear cross-team communication was essential to follow-the-sun development.

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

Going with the Flow: Agile Development at Dell 3

Table 1. Software Development Teams at Dell-Technologies/Limerick

Team Team Project Manager Project Focus # of Team Members per Country Ireland India USA China

1 Larry Ferreira Dell Commerce Services 1 6 1 1

2 Pierre Dubois Dell Commerce Services 2 8 1

3 John Warren Dell Commerce Services 3 8 1

4 Niall Collins Dell Commerce Platform 1 9

Source: Larry Ferreira

Dell software teams included both recent graduates and experienced senior developer/testers. Local resources included the University of Limerick, National University of Galway, and Lero | Science Foundation Ireland Research Centre for Software. Lero worked with 50 sponsoring organizations and 250 researchers on various IT-related projects.

Ferreira and other team project managers (formerly referred to as “scrum masters”) reported to both Product Owner Amélie Berger and O’Dwyer — each of whom reported up to the Senior Manager for Manufacturing, who reported up to Director of Manufacturing Mark Fitzpatrick.

Berger was responsible for gathering detailed user requirements from the business side and conveying these to software teams. She coordinated with various units via conference calls and frequent visits to headquarters in Texas. In agile development, requirements were conveyed to developers in three forms (See Exhibit 1): “themes” (cross-organization focus areas) “epics” (large work products), and “user stories” (multiple stories for each epic). Thus, a Principal Developer, a Solution Architect, and Ferreira worked with Berger to define technical specifications for Team 1’s themes, epics and user stories.

O’Dwyer supervised 34 direct reports, including technical project managers, software development engineers, and release managers in the USA and EMEA countries. O’Dwyer supported Dell’s global sales organisation by overseeing the delivery of new enterprise-class sales applications; mentoring developers and monitoring their productivity; directing quality improvements in programme delivery; and coordinating with internal stakeholders (e.g., sales, IT, sales operations, supply chain, product development, training and marketing).

In 2012, Dell software developers began transitioning from Waterfall (See Exhibit 2) to Agile (by using “Scrum” techniques – see next section). O’Dwyer explained that a few years later, in summer 2016, the SPI Board decided that Dell software teams should adopt a newer set of Agile tools (collectively referred to as Flow), as it was gaining popularity in the global software community.

WHAT IS AGILE SOFTWARE DEVELOPMENT?

“Agile” described lean software development methods, consistent with guiding principles described in a 2001 Agile Manifesto.4 In 2017, Scrum and Flow were the two leading agile practices.

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

4 Case Research Journal •Volume 41• Issue 3• Summer 2021

Scrum Scrum consisted of four ceremonies:

1. Sprint Planning: Work was divided into two-week or four-week “sprints” (at Dell, two-week sprints were the norm).

2. Daily Scrum (or Standup): Each day, each team member reported to their scrum master and teammates, about what they did the previous day and intended to do this day.

3. Sprint Review: At the end of each sprint, team members demonstrated new software code to stakeholders.

4. Sprint Retrospective: Also at the end of each sprint, the team gathered to reflect how things went and what they would like to change.

A sprint Product Backlog – a prioritised list of tasks for a team to work on next (e.g., features to support, bugs to fix) — was derived from a Roadmap and its requirements.

O’Dwyer focused on two agile software development performance indicators: user stories per project and user stories per two-week sprint (a.k.a. “velocity”). Regarding this latter metric, O’Dwyer told Ferreira that Dell software teams typically completed 12 to 15 user stories per sprint. Flow Flow,i inspired by lean manufacturing (a waste-reduction/quality improvement technique) supported continuous software delivery.5 A promotion for an early Flow book6 explained that developers could “achieve breakthrough quality, savings, speed and business value by adopting seven ‘lean’ principles that … already revolutionized manufacturing and R&D” (See Exhibit 3). Flow described how development tasks moved through a system. In a system with good Flow, work moved through steadily and predictably. In a system with bad Flow, work stopped and started frequently.7 Thus, Flow supported software deployment by emphasising continuous movement of value-added work, instead of discrete activities performed by separate teams or departments,8 through the entire development process.9 It differed from traditional software project management, in its focus on managing queues instead of project timelines and phases.10

Flow relied on two key quality metrics: • Cycle Time: how long a task spent in specific individual or combined workflow

states. • Lead Time: how long it took for a work item to move from initial request to

delivery to a customer. Before Ferreira was hired, Dell Tech – Limerick teams were told to learn to work

with four Flow tools: Kanban boards, Value Stream Maps, Cumulative Flow Diagrams (CFDs), and Burn-Down Charts (See Exhibit 4). These and other Flow techniques reportedly yielded higher development productivity than time-boxed Scrum sprints, which interrupted the fluent flow of work11(See Exhibit 5).

O’Dwyer said that several directors – including Solution Management Director John O’Brian, Digital Supply Chain Director Mike Mulligan, and Manufacturing Director Fitzpatrick — were keen to demonstrate the Limerick software development and IT divisions’ commitment to continuous, efficient software delivery. Since Dell had produced computers in Limerick since 1991, O’Dwyer explained, he and other Directors recognized that Flow was both agile and lean; similar cycle time and lead time metrics would help managers monitor software development productivity.

In 2009 manufacturing was moved from Limerick to Poland (eliminating 1,900 production jobs12 — two-thirds of the Limerick workforce at the time). Fitzpatrick still

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

Going with the Flow: Agile Development at Dell 5

relied on two Lean Six Sigma manufacturing metrics in use at Dell for many years — cycle time and lead time.

Two Lero-supported NUI Galway faculty members were conducting a study of teams’ successes and challenges during Flow pilot testing. A Flow Coordinator, appointed earlier in Summer 2016, left Dell shortly before Ferreira was hired at the end of the summer. After learning more about the Flow pilot testing from O’Dwyer, Ferreira volunteered to add Flow Coordinator to his team project manager role. O’Dwyer agreed enthusiastically, and added that he hoped that as the pilot testing of Flow Techniques continued, some team members would become Flow experts, who could then be tapped to help other Dell developers learn Flow techniques, in Ireland and elsewhere.

As Flow Coordinator, Ferreira resolved to spread the word about helpful tools and metrics and to celebrate early wins as the four Limerick teams mastered new tools and overcame challenges. LISTENING AND LEARNING

After meeting the two NUI Galway faculty members, Ferreira decided to embark on a one-year research master’s degree (MPhilii), under their supervision. First, he conducted a literature review to compare control techniques and challenges in Waterfall and agile development projects (both Scrum and Flow). He soaked up information in books like Stop Starting, Start Finishing.13 This book explained how work- in-progress (WIP) limits helped teams finish tasks better and faster. The four Dell Tech software teams relied on physical Kanban boards to track work-in-progress on sticky notes (“work tickets”) that listed specific tasks, from Backlog through to Done. On his team’s board, Ferreira posted the “Stop Starting, Start Finishing” mantra (See Exhibit 6). At the start of each daily standup meeting he restated that phrase.

At one standup, software tester Patrick Connolly complained that the code management tool offered “limited digital Kanban functionality.” Code management (version control) software tracked changes made to software over time. If a major flaw was discovered in a recent version (necessitating reinstallation of a previous version), a code management tool was especially helpful. Dell installed this system in 2014 (it was introduced to market in 2006). Connolly, who complained it did not let a user “drag and drop virtual sticky notes (work tickets) from a backlog,” explained a workaround: “One has to batch-upload work tickets using a home-grown Excel application.” He also complained that this tool did not colour-code tickets to denote priority of work items, defects, and blockages. When distributed follow-the-sun14 teams worked on different modules of a large system, version control with this tool was particularly cumbersome and error-prone.

Ferreira agreed; software teams needed digital Kanban functionality, both for their daily work and for automatically generating Flow work metrics (e.g., cycle time, lead time). In fall 2016 he formally requested that the Dell Change Management Board (in Texas) upgrade the code management tool to include the Kanban features Connolly wanted, and to periodically produce key Flow metrics. Ferreira hoped this functionality would be ready before the teams’ early February 2017 code-release date. Meanwhile, another developer and a college intern began developing a separate virtual Kanban board — to address the problems Connolly described, as well as other code management tool limitations (e.g., generic workflow states, which did not accurately reflect a team’s actual work).

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

6 Case Research Journal •Volume 41• Issue 3• Summer 2021

In fortnightly sprint planning meetings Ferreira’s team discussed the product backlog, divided epics into stories, and planned for future sprints to deliver on prioritized requirements. Ferreira also met informally with team members and other colleagues at coffee breaks and lunch. In the seating-limited canteen, colleagues often would stop by a table to join a conversation for a few minutes. On the day Ferreira volunteered to add Flow coordination to his workload, O’Dwyer thanked him and said: “It will take time to fully embed Flow changes into the team; change will be a challenge.” A passing colleague paused to comment: “Flow aims to produce financial savings. People may wonder: Will we work ourselves out of a job? There’s a challenge for you!”

Another time, O’Dwyer mentioned that some Dell teams combined Scrum and Waterfall techniques, ”which works really well for them.” He added: “Perhaps some teams should combine Scrum and Flow.” Ferreira replied: “That would be a good question to put to my NUI Galway professors.” Later that day, Ferreira spoke with Jimmy Delaney, a Senior Software Developer, to learn about his team’s hybrid approach. Delaney explained,

We only blend Waterfall and Agile at the beginning of a project. Our experience is that successful projects use the Agile frequent delivery approach (two week sprints), after first getting a robust preliminary definition of the expected final product or customer experience. I believe Flow will benefit the organisation end-to-end. It will take time. How we nurture interest and get people really engaged — that’s a challenge in itself.

Next, Ferreira spoke with Project Manager Pierre Dubois, who told him that Team 2 worked on backend order-processing systems, including an internal web-based sales tool. Dubois said: “People depend on scrum masters [team project managers] to show how to use Flow tools and explain basic principles, such as what work is in process or prioritized. Everyone needs training on Flow tools and on how to interpret Flow metrics.”

During Fall 2016, Ferreira participated in many in-house and online Improving Your Flow presentations to project teams in Ireland, U.S., India and Brazil, co-delivered with the two NUI-Galway researchers. In November 2016 a Value Stream Mapping workshop was held for the four Limerick teams. Later, these software developers and nine managers attended a one-day Managing Impediments to Flow in Project Portfolios workshop at NUI Galway. The researchers explained that the workshop would help managers and teams learn how to manage impediments to Flow, and to scale Flow techniques beyond individual projects to teams’ and organizations’ portfolios of projects. They also shared their plan to conduct other workshops early in 2017, to help participants from Dell and Lero partner organizations compare Flow experiences and consider how to apply others’ lessons learned to their own organisations. Other workshops would focus on advanced Flow techniques. FLOW OPINIONS AND OUTCOMES

In December 2016 Ferreira established a Limerick campus Communities of Practice SharePoint site (Microsoft SharePoint was a browser-based document management and collaboration tool) to share Flow tips, lessons learned, and academic research papers across project teams. He also created a Project Portal repository containing photos, Flow literature, and slides used in presentations to Dell project team managers around the world. The purpose of this portal was to inform Dell developers about

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

Going with the Flow: Agile Development at Dell 7

specific benefits arising from use of specific Flow tools. Ferreira hoped both of these knowledge repositories would help build momentum for an eventual worldwide Flow rollout.

In early January, Ferreira learned that on 7 February 2017, at the Systems and Processes Improvement SPI Board meeting, he would have a 20-minute slot to summarize Flow successes and challenges thus far. Fitzpatrick, Mulligan, O’Brian and other Dell-Tech Limerick Directors would attend this meeting; Ferreira learned the tone would be formal, not casual. In order to prepare for his presentation, Ferreira asked each project manager to report on their team’s use of four key Flow tools (See Exhibit 4), and their lead time and cycle time metrics. All four teams were piloting physical Kanban boards, but Teams 1 and 2 were farther along than teams 3 and 4 in adopting Flow practices. Teams 1 and 2 pulled some relevant data from the code management tool, to achieve limited digital Kanban functionality and to generate more accurate CFDs. Teams 1 and 2 also created value stream maps to identify Flow impediments, and they were achieving a steady and predictable (“good”) workload. Teams 3 and 4 had not yet produced value stream maps, and experienced unpredictable (“bad”) flow.

Ferreira concluded that Teams 1 and 2 were making good progress on two key practices:

1) value clearly defined by customer (via Product Owner-reported customer requirements)

2) work ‘pulled’ through the system in single-piece Flow (when a story is completed by a developer, it is immediately released to testing; not released in sprint batches).

Ferreira asked the project managers to describe benefits their teams achieved from Flow thus far. All four teams noted that their heavy development workloads made it difficult to continuously reflect on value delivered or Flow impediments. Although they could not claim to be continuously improving, all four teams nevertheless reported they did feel the following benefits were already being realized:

o 100% compliance with work states in the code management tool. o greater ownership of defects. o greater visibility of defects not being closed promptly. o quality control checks integrated throughout each sprint. o improved planning and resource allocation. o improved communication between teams. Ferreira knew the SPI Board would ask about productivity. Learning that teams 2,

3 and 4 had not yet captured baseline cycle time or lead time metrics, he focused on his team (Team 1). Since the code management tool did not automatically produce Flow metrics, he extracted relevant data from its time stamp feature (e.g., date when a software requirement was requested and date when it was completed). After going through a laborious manual process to extract six months’ data (through January 2017) and convert it into Microsoft Excel, Ferreira reported that Team 1’s average lead time dropped from 109 to 39 days, and its average cycle time dropped from 31 to 24 days. When Ferreira mentioned how he obtained these metrics, O’Dwyer commented: “The only way to embed a process is to automate it. If it’s not in the code management tool, it will fail.”

Later in January, Ferreira participated in a Scaling Flow to Project Portfolios workshop at a national bank’s Dublin headquarters; this bank made advanced use of Flow. Of the 40 attendees, 10 were from Dell and 30 from five other companies. As part of a breakout activity, Ferreira listed Flow scaling challenges: getting buy-in from software

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

8 Case Research Journal •Volume 41• Issue 3• Summer 2021

developers and some managers, communicating flow metrics to management, creating an organization-wide business language. PREPARING FOR THE FEBRUARY 7, 2017 SPI BOARD MEETING

In early February Ferreira held a meeting with the two NUI Galway researchers, a solution architect, the project managers for Dell software teams 2, 3 and 4, and Berger, to discuss Flow progress, challenges, and next steps. First, an NUI Galway researcher recapped the August 2016 Flow review (held before Ferreira was hired). He stated the teams “experimented with various Kanban boards — such as a design that incorporated work-in-process limits.” All four teams experienced “challenges related to the scale and complexity of their [software] projects, but all seemed committed to overcoming those challenges.”

The two researchers reported (based on subsequent weekly interviews, observations, and other data gathering) that Dell teams were making “some progress” on cycle time, lead time, and quality. They noted that before the teams began to pilot- test Flow, on average one in five stories contained defects. The lead researcher stated: “Early indicators suggest this number has been reduced to about one story in eight. This is good progress, at this stage of Flow assimilation.” Both researchers praised Ferreira’s positive attitude and commitment to the Flow project, and his support of their research collaboration. After thanking them, Ferreira described his frustration with the Change Management Board (in Texas):

With no word back from them, it is unclear when or if the code management tool will be upgraded with virtual Kanban functionality. This is a setback, since a physical Kanban board cannot effectively support our daily handoffs in our follow-the-sun globally-distributed environment.

Then Ferreira reported on another concern: although teams continued to produce their deliverables on schedule, he thought they were working “too hard.” Unplanned overtime was “taking a toll on morale,” he stated. Ferreira also speculated that this might be “contributing to [recent] staff turnover issues.” Ferreira believed that when workloads piled up, it was hard for developers to learn new techniques.

On February 6 Ferreira met O’Dwyer for lunch in the canteen. O’Dwyer asked: “Are you ready for tomorrow’s review with the SPI Board?” “Here’s what I have in mind,” replied Ferreira.

I will provide a brief overview of the Flow Pilot Project – why it’s important, who’s involved. I will discuss a chart showing planned and actual deliverables. Our progress has not been as rapid as planned, but my message is: A little struggle is to be expected when implementing a new and radically different development method. I will leave a few minutes for questions.

O’Dwyer paused before describing a meeting he had attended that morning: “I heard three important comments”, he said:

1. One director said the 2016 SPI presentations conveyed “way too many bullet points; way too much information.” Each presenter should convey two or three key messages at most.

For the exclusive use of A. Patel, 2022.

This document is authorized for use only by Ankitkumar Patel in BADM 623 – Project Management Processes taught by Daniel Kanyam, University of the Cumberlands from Jan 2022 to Jun 2022.

Going with the Flow: Agile Development at Dell 9

2. Given a proposed transfer of software development from Limerick to Cork, several directors emphasized the importance of showing clear progress, based on solid evidence.

3. Most Dell directors assume teams choose the methods and tools that best suit their work. …