Going With The Flow: Agile Development at Dell

For the exclusive use of Y. Lin, 2022.
Going with the Flow:

Agile Development at Dell
NA0690
Denis Dennehy, National University of Ireland Galway
Kieran Conboy, National University of Ireland Galway
Janis Gogan, 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,
-----------------------------
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 jgogan@bentley.edu.
Going with the Flow: Agile Development at Dell 1
This document is authorized for use only by Yanglin Lin in ISYS5943 (Fulltime) taught by Hartmut Hoehle, University of Arkansas - Fayetteville from Jan 2022 to Jul 2022.
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.
2 Case Research Journal •Volume 41• Issue 3• Summer 2021
Table 1. Software Development Teams at Dell-Technologies/Limerick

# of Team Members per
Team Project
Team Project Focus Country
Manager
Ireland India USA China
Dell Commerce
1 Larry Ferreira 6 1 1
Services 1
Dell Commerce
2 Pierre Dubois 8 1
Services 2
Dell Commerce
3 John Warren 8 1
Services 3
Dell Commerce
4 Niall Collins 9
Platform 1
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.
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
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).
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
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
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.
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. What they want to know is: Are the teams delivering better
code, on time?
Ferreira’s mood changed from confident to concerned; he realized O’Dwyer was
reminding him this was a critically-important moment for Dell in general and Dell-
Technologies-Limerick in particular. The company’s new strategy depended on rapidly-
developed high-quality software, and Ferreira believed Flow was the key to unlock
software value. Yet, he did not know if all of the directors in attendance at tomorrow’s
meeting would share that enthusiasm. He took a long sip from his water bottle before
replying: “I will fine-tune my Plan A.”
O’Dwyer replied: “Just remember: no more than three key messages.” Standing
up, he said “I’m sorry we can’t talk more, but I’m off to my next meeting. Do whatever
makes sense. See you tomorrow!”
Exhibit 1 - Themes, Epics, and Stories: Middleware for Real-Time Payments

Exhibit 2 - Software Development and Waterfalls: A Short History
Software development entails requirements specification, analysis, design, coding, and testing
Beginning with their adoption in business in the 1950s, computers grew more powerful year
after year, yet software development productivity improved at a slower pace. Also, many
software development projects delivered software late or with sub-optimal functionality.
In the 1960s software development was a craft; individual skill was developed through trial and
error. Software languages were cryptic, and coding was highly specialized and difficult for
laymen to grasp.
The launch of the IBM PC in August 1981 set off a wave of innovation, with end-users
adopting off-the-shelf electronic spreadsheets and user-friendly database products, to develop
their own ad hoc applications. At the same time, software engineering took hold as a rigorous
discipline. Managers had come to understand that reliance on self-taught coders was risky; if a
coder did not document their work, their system knowledge walked out the door if they retired
or otherwise left the organization.
By the 1990s, hardware improvements and the Internet’s growing importance for information
sharing and commerce made it possible (and necessary) to build more complex and
interdependent systems to support teams, enterprises, and inter-organizational commerce and
collaboration-- which in turn meant that organizations had to cope with greater software
complexity and disappointing results.
In an ideal Waterfall model of software development, requirements inform analysis, which
inform design, which guides coding. In the 1990s many developers used structured Waterfall
methods and computer-aided software engineering (CASE) tools, to carefully specify and
codify system requirements. Analysis and design documentation relied on manual or computer-
supported modeling techniques to produce data flow diagrams, entity-relationship diagrams,
and “swim lane” system flowcharts. Programmers were required to document their code
(mostly by inserting explanatory comments in their programs). Use of models, CASE tools and
coding documentation helped ensure that functional requirements were incorporated into
systems and that the software could be subsequently modified by staff other than the original
developers.
Unfortunately, it took time to develop, review and approve flowcharts, data flow diagrams and
other models. These also had to be re-developed whenever circumstances gave rise to new
requirements. Because the pace of business operations and strategy was accelerating, it was
often the case that by the time a two- or three-year project was completed, the software no
longer suited the current business situation. Waterfall’s earliest proponents15 did recognize that
a to-be system model was subject to revision as circumstances changed, but they
underestimated both the pace of business change and developers’ frustration about spending
time building models or documenting their code, compared with actual coding (which they
prized).
To address these concerns, Rapid Prototyping, Extreme Programming (XP) and other newer
techniques helped reduce the documentation burden and empowered developers to build
software iteratively in shorter cycles, and in collaboration with customers.
In early 2001, 17 software developers met at a Utah ski resort to produce an Agile Software
Development Manifesto, based on four key values for team-produced high-quality software:
1. Emphasize individuals and interactions, not processes and tools
2. Emphasize working software, not comprehensive documentation
3. Emphasize customer collaboration, not contract negotiation
4. Emphasize responding to change, not following a plan
Source: Booch, G., 2018. The history of software engineering. IEEE Software, (35:5), pp.108-
114. Slightly paraphrased by case authors, for clarity and brevity.
Exhibit 3 - Adapting Seven Lean Manufacturing Principles to Software Development
1. Eliminate waste (anything that does not add value to a product). A component sitting on a shelf
gathering dust is waste. A requirements [document] gathering dust is waste. If a [factory] makes more
stuff than is immediately needed, that is waste. Coded features that are not immediately needed --
waste. The ideal is to find out what the customer wants, [quickly] make or develop it, and deliver it.
Whatever gets in the way of rapidly satisfying a customer need is waste.
2. Amplify learning. [Software] development is an exercise in discovery … like creating a recipe.
Great chefs ….are not expected to produce a perfect recipe on the first attempt; they produce several
variations. … Software development is a similar learning process, with the added challenge that
development teams are large, and results are far more complex than a recipe. The best way to improve
software development is to amplify learning.
3. Decide as late as possible. Development practices that [support] late decision making are effective
in domains that involve uncertainty, because they provide options. Delaying decisions is valuable
because better decisions can be made when based on fact, not speculation. In an evolving market,
keeping design options open is valuable. A key strategy for delaying commitments when developing a
complex system is to build a capacity for change into the system.
4. Deliver as fast as possible. Rapid development has many advantages. Without speed, you cannot
delay decisions [and] you do not have reliable feedback [in] a discovery cycle -- Design, Implement,
get Feedback, Improveiii -- the shorter the cycles, the more that can be learned. Speed [means]
customers get what they need now, not what they needed yesterday. It allows them to delay making
up their minds about what they really want until they know more. Compressing the value stream as
much as possible is a fundamental lean strategy for eliminating waste.16
5. Empower the team. … The people who actually do the work combine the knowledge of minute
details with the power of many minds. When equipped with necessary expertise and guided by a leader,
they make better technical decisions and better process decisions than anyone can make for them.
Because decisions are made late and execution is fast, a central authority [cannot] orchestrate workers’
activities. Lean practices use pull techniques to schedule manufacturing work. Workers use local
signalling mechanisms to let each other know what needs to be done. In lean software development,
the pull mechanism is an agreement to deliver increasingly refined versions of working software at
regular intervals. Local signalling occurs through visible charts, daily meetings, frequent integration,
and comprehensive testing.
6. Build integrity in. A system is perceived to have integrity when a user thinks, "Yes! That is exactly
what I want!" A [product’s] market share is a rough measure of perceived integrity, because it measures
customer perception over time. Conceptual integrity means that a system's central concepts work
together as a smooth, cohesive whole; it is a critical factor in perceived integrity.[15] Software needs
an additional level of integrity; it must maintain its usefulness over time. Software is usually expected
to evolve gracefully as it adapts to the future. Software with integrity has a coherent architecture, scores
high on usability and fitness for purpose, and is maintainable, adaptable, and extensible.
7. See the whole. Integrity in complex systems requires deep expertise in many diverse areas. One of
the most intractable problems with product development is that experts have a tendency to maximize
performance of the part of a product representing their own specialty, rather than focusing on overall
system performance, [which can lead to] sub-optimization. This problem is even more pronounced
when two organizations contract with each other, because people will naturally want to maximize [their
company’s] performance. It is challenging to implement practices that avoid sub-optimization in a
large organization, and it is an order of magnitude more difficult when contracts are involved.
Source: Poppendieck M. & Poppendieck T. Software Development: An Agile Toolkit, Chapter 1.

Addison Wesley, ISBN 0-321-15078-3. Slightly paraphrased by case authors, for clarity and
brevity.
Exhibit 4 - Flow Tools
Value Stream Map: Follows an item of work, in order to establish the value added in each processing step.
Useful for identifying value from four key perspectives: (i) financial, (ii) customer, (iii) internal business
process, and (iv) innovation.
Kanban Board: project focused visualisation of workflow states as work moves through the organisation.
This card-based system enables team members to observe work-in-progress (WIP), self-organise, and move
work from a backlog through to Done. A Kanban board can use physical or digital cards (or “tickets”).
Cumulative Flow Diagram (CFD): An aggregated view of work in each defined work state (represented
on the Kanban board). Useful for understanding the behaviour of queues and diagnosing problems.
Burn-down Chart: Shows an aggregated view of amount of work that remains versus time left in a sprint.
Useful for predicting when work will be complete, given the current pace of the team.
Source: Dennehy & Conboy 2018xiiii
Exhibit 5 - Comparison of Flow and Scrum
Flow Scrum
Work pulled through system in single- Work pulled through system in small batches
piece Flow
Cadence: continuous Flow Cadence: time-boxed iterations

(optional time-boxed iterations) (e.g., sprints)
Explicit work-in-progress limits Implicit work-in-progress limits
Roles required, Roles are prescribed:

but prescribed by team, not by method product owner, scrum master, development
team
Kanban board is used to visualise work Optional “Scrumban” board;

states reset at end of each sprint
(in continuous use)
Optional cross functional teams Prescribed cross functional teams

(specialist teams permitted)
Work item sizes vary; Work items broken into sprint-sized chunks
no rule requires item completion in
specific time-box
Release method and date at team’s Release at end of each sprint

discretion (after product owner approval)
Lead-time is default metric Velocity is default metric
No specific chart required Burn-Down chart required

(CFD is typical default)
Source: Dennehy & Conboy 2018,17 Slightly paraphrased by case authors, for clarity and
brevity.
Exhibit 6 - Physical Kanban board with ‘Stop Starting, Start Finishing’ slogan
REFERENCES
1 Dell Technologies FY 2017 Annual Report, Feb 3 2017.
2 Dell Technologies FY 2017 Annual Report, Feb 3 2017.
3Carmel, E., Espinosa, J.A., Dubinsky, Y. 2010. "Follow the Sun" workFlow in
global software development. Journal of Management Information Systems (27:1),
pp.17-38.
4Agile Software Development Manifesto.
https://www.agilealliance.org/agile101/the-agile-manifesto/
5Anderson, D., Concas, G., Lunesu, M.I., Marchesi, M., Zhang, H. 2011. “Studying
Lean-Kanban Approach Using Software Process Simulation,” In A. Sillitti, O.
Hazzan, E. Bache, X.Albaladejo (Eds.), International Conference on Agile Software
Development, pp. 12-26. Berlin: Springer.
6Poppendieck, M. & Poppendieck, T. 2003. Software Development: An Agile
Toolkit. Addison Wesley. ISBN 0-321-15078-3.
7 Lean Business Report 2017
8Fitzgerald, B. & Stol, K.-J. 2015. “Continuous software engineering: A roadmap
and agenda,” Journal of Systems and Software (123), pp. 176-189.
9Anderson, et al., 2011 (op cit.); Reinertsen, D.G. 2009. The Principles of Product
Development Flow. Redondo Beach, CA: Celeritas; Petersen, K. & Wohlin, C. 2011
“Measuring the flow in lean software development,” Software: Practice and
Experience (41:9), pp. 975-996.
10Anderson et al., 2011 (op cit.); Anderson, D. 2013. Lean Software Development.
Seattle WA: Lean Kanban University (LKU); Power, K. & Conboy, K. 2015. “A
metric-based approach to managing architecture-related impediments in product
development flow: An industry case study from Cisco,” In: A. Bertolino (Ed.),
Proceedings of the Second International Workshop on Software Architecture and
Metrics, pp. 15-21. Florence, Italy: IEEE Press.
11Sjøberg D.I., Jonsen, A., Solberg, J. 2012. Quantifying the effect of using Kanban
versus Scrum: A case study, IEEE Software (29:5), pp. 47-53.
12Gifford, R. 2009. “Dell to Close Irish Factory, Move to Poland.” National Public
Radio, Morning Edition, 13 January.
https://www.npr.org/templates/story/story.php?storyId=99276446
13 Roock, A. 2018. Stop Starting and Start Finishing. Lean Kanban University Press.
14Carmel E., Espinosa A., Dubinsky Y. 2010. “Follow the Sun” workflow in global
software development. Journal of Management Information Systems (27:1).
Royce, W. 1998. Software Project Management: A Unified Framework. Reading,
15
MA: Addison Wesley.

16Roos, D., Womack, J.P, Jones, D. T. 1991. The Machine That Changed the World :
The Story of Lean Production, Harper Perennial, ISBN 0060974176, ISBN 978-
0060974176
17Dennehy, D. and Conboy, K., 2018. Identifying challenges and a research agenda
for flow in software project management. Project Management Journal, (49:6),
pp.103-118.
NOTES
iThe concept of Flow in software development literature is not related to
psychological Flow, which refers to a state of concentration or complete absorption
in an activity (Csikszentmihalyi; 1975; 1991).
ii As compared with a course-based MA or MSc program, an MPhil program involves
independent research under the supervision of a faculty member. See
https://gradireland.com/further-study/advice-and-funding/advice/research-vs-
taught (downloaded April 25 2020).
iii This is similar to the Lean Six Sigma DMAIC technique (Define, Measure, Analyse,
Improve, Control).

Going With The Flow: Agile Development at Dell

Uploaded by

Copyright:

Available Formats

Going With The Flow: Agile Development at Dell

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Going With The Flow: Agile Development at Dell

Uploaded by

Copyright:

Available Formats

For the exclusive use of Y. Lin, 2022.

Going with the Flow:

Going with the Flow: Agile Development at Dell 1

SOFTWARE DEVELOPMENT AT DELL TECHNOLOGIES -

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

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

WHAT IS AGILE SOFTWARE DEVELOPMENT?

Going with the Flow: Agile Development at Dell 3

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

LISTENING AND LEARNING

Going with the Flow: Agile Development at Dell 5

In fortnightly sprint planning meetings Ferreira’s team discussed the product

FLOW OPINIONS AND OUTCOMES

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

Going with the Flow: Agile Development at Dell 7

developers and some managers, communicating flow metrics to management, creating

PREPARING FOR THE FEBRUARY 7, 2017 SPI BOARD

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

2. Given a proposed transfer of software development from Limerick to

Going with the Flow: Agile Development at Dell 9

Exhibit 1 - Themes, Epics, and Stories: Middleware for Real-Time Payments

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

Exhibit 2 - Software Development and Waterfalls: A Short History

Going with the Flow: Agile Development at Dell 11

Exhibit 3 - Adapting Seven Lean Manufacturing Principles to Software Development

Source: Poppendieck M. & Poppendieck T. Software Development: An Agile Toolkit, Chapter 1.

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

Exhibit 4 - Flow Tools

Source: Dennehy & Conboy 2018xiiii

Going with the Flow: Agile Development at Dell 13

Exhibit 5 - Comparison of Flow and Scrum

Cadence: continuous Flow Cadence: time-boxed iterations

Explicit work-in-progress limits Implicit work-in-progress limits

Roles required, Roles are prescribed:

Kanban board is used to visualise work Optional “Scrumban” board;

Optional cross functional teams Prescribed cross functional teams

Release method and date at team’s Release at end of each sprint

Lead-time is default metric Velocity is default metric

No specific chart required Burn-Down chart required

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

Source: Larry Ferreira

Going with the Flow: Agile Development at Dell 15

MA: Addison Wesley.

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

You might also like