Business Horizons (2016) 59, 635—644

Available online at www.sciencedirect.com

ScienceDirect
www.elsevier.com/locate/bushor

EXECUTIVE DIGEST

Managing the transition to the new agile

business and product development model:
Lessons from Cisco Systems
Roger (Ronxin) Chen a,*, Ramya Ravichandar b, Don Proctor b

a
School of Management, University of San Francisco, 2013 Fulton Street, San Francisco, CA 94117, U.S.A.
b
Cisco Systems Inc., 170 West Tasman Drive, San Jose, CA 95134, U.S.A.

KEYWORDS Abstract Through an in-depth case study of Cisco Systems, this Executive Digest
Agile development; finds that companies face two broad challenges when transitioning to the agile product
Innovation; development model. The first is identifying and helping business units and engineering
Product development; teams adopt this method; the second is developing new management practices that
Organizational change; are compatible with and can sustain the agile development practices. Although extant
Cisco Systems; literature has conducted many analyses on these two challenges, there still exist gaps
Organizational agility in the research of the agile development method. Herein, we explore how Cisco
Systems addressed these two challenges followed by a discussion of the broad
implications of adopting the agile development method. This research deepens our
understanding of how to adopt and lead the agile development process.
# 2016 Kelley School of Business, Indiana University. Published by Elsevier Inc. All
rights reserved.

1. Introduction and literature review developing new organizational environment and

management practices that will sustain and support
Since the publication of the Manifesto for Agile agile development practices once the transition to
Software Development (Beck et al., 2001), the agile agile development practices is complete. Figure 1
development model has been adopted by many depicts these two major challenges.
companies and received increased attention in aca- Existing research has reported on many studies on
demic research. Organizations incorporating agile the agile development method. Regarding the first
development face two major challenges: managing challenge, prior research has proposed various
the transition for the company or business units, and frameworks to help companies make the transition
from a traditional to an agile development process.
Boehm and Turner (2003a) defined five decision
factors–—size, criticality, personnel, dynamism,
* Corresponding author and cultural–—to help companies decide whether
E-mail addresses: [email protected] (R. Chen),
[email protected] (R. Ravichandar), [email protected]
they should adopt a traditional method, an agile
(D. Proctor) development method, or some combination of the

0007-6813/$ — see front matter # 2016 Kelley School of Business, Indiana University. Published by Elsevier Inc. All rights reserved.
http://dx.doi.org/10.1016/j.bushor.2016.06.005
636 EXECUTIVE DIGEST

Figure 1. Key management challenges for organizational transition to an agile development model

Helping transition to the agile New management practices

development process required by agile development
Transition
processes
How can companies select and help
organizational units and teams to How can companies develop new
change from non-agile to agile management environments &
development processes? practices to enable and support agile
development practices?

two. Qumer and Henderson-Sellers (2008) devel- different sources, ranging from mini cases to theory
oped the agile adoption and improvement model papers to professional opinion posts; few studies
(AAIM), which defines six levels of agile adoption— have examined the intricacies and complexities of
including agile infancy, agile initial, agile realiza- how these factors and frameworks work holistically
tion, agile value, agile smart, and agile progress. in the context of one company. In fact, scholars have
More recently, Gandomani and Nafchi (2015) used called for a comprehensive and disciplined approach
the grounded theory approach to develop an agile for companies to manage the transition to the agile
transition and adoption framework that includes method (Gandomani, Zulzalil, Ghani, & Sultan,
five components: practice selection, adaption, as- 2013). In response, we conducted an in-depth case
sessment, retrospective, and adjustment. analysis of Cisco, a company that offers system
Regarding the second challenge of developing products involving both software and hardware
new management practices to enable and sustain components, and a company in which some business
the agile development process, many studies dis- units have transitioned to the agile development
cussed the impact of adopting agile development on method while others have not. By focusing on the
management practices. Nerur, Mahapatra, and Man- experience of one company, it allows us to validate
galaraj (2005) analyzed the impact of the agile some of the arguments, deepens our insights into
method on management style, organizational con- the transition from traditional to agile development
trol, communication, and customer role. Hoda, No- methods, and allows us to explore new management
ble, and Marshall (2011) explained all required roles practices required to support and sustain agile
in an agile self-autonomy team. Moreover, previous development methods. Our analysis is organized
studies argue that project managers, especially as follows: We first introduce the case company,
those who are experienced in traditional software Cisco Systems, and our research method, and then
development, need to transition from a traditional present our findings and discussion of each research
commander role to a leadership role. For example, question.
Ambler (2005a) indicated that in agile teams, man-
agers need to act as the team coach. Other studies
analyzed the impact of the agile development meth- 2. Case company and research method
od on additional management functions and practi-
ces, including planning (Ambler, 2005b; Boehm & 2.1. About the case company: Cisco
Turner, 2003b), management coordination (Strode, Systems
Huff, Hope, & Link, 2012), and task design (James,
2010; Thomke & Reinersten, 1998). Scholars have We analyzed the two challenges depicted in Figure 1
also discussed characteristics of the customer in the through an in-depth case analysis of Cisco Systems
agile method (Cohen, Lindvall, & Costa, 2004; Turn- Inc. Cisco is a leading global network equipment
er & Boehm, 2003), which has important implica- company that offers a wide range of products–—such
tions for how agile teams operate. as routers, switches, and networking solutions–—
In sum, many studies on the agile development designed for enterprises and small businesses across
method have examined topics pertaining to our two a variety of industries. Cisco has traditionally used
research questions or challenges; however, most of the waterfall method to develop new products. In
these studies focus on software companies or soft- the waterfall method, tasks and deliverables are
ware products. It is unclear if the frameworks from clearly visible at each stage of the product devel-
these studies apply to companies offering system opment process; however, the entire development
products that include both software and hardware process can be lengthy. Waterfall methods typically
components. Furthermore, the arguments and start with various analysis reports (e.g., a business
findings of the existing literature are drawn from requirement document, product requirement
EXECUTIVE DIGEST 637

document, marketing requirement document) that 3. Findings

aid in creating development tasks, which are then
handed to various development teams (e.g., user 3.1. Challenge #1: Helping the transition
experience, engineering). The teams go through a to the agile development method
variety of product tests before launching the prod-
uct to the market. From start to finish, the process It is often difficult for business unit leaders and
can take up to 18 months or longer. In a fast- engineering teams to give up their old mindsets and
changing environment, such a lengthy development habits and adopt the new behaviors required by the
cycle can lead to an outdated product when the agile development method. To address this chal-
product is introduced to the market. lenge, Cisco established a dedicated corporate Agile
Under an agile development method, compa- Tiger Team (ATT) to assist business units and engi-
nies do not go through similarly lengthy and com- neering teams making the transition. The ATT focuses
prehensive analysis at the outset, and, as such, on the following assessment and transition tasks.
the planning period is much shorter. At Cisco,
business units that use the agile method have 3.1.1. Benefit assessment
major product releases every quarter. Within each When identifying business units for transition to an
quarter, product development is divided into agile method, the ATT first works with business units
sprints, with each sprint lasting approximately to evaluate the potential benefits of adopting agile
two weeks. After each two-week sprint, product processes. Identifying benefits is a crucial step to
managers demonstrate new features to customers get the buy-in and collaboration from business units
and seek their feedback. Thus, agile development to initiate and sustain the transition to the agile
processes are closer to market and faster. But it method. In general, the ATTobserved that transition
also involves more change and uncertainty. We to agile development brings the greatest benefits in
chose Cisco as our case study because some busi- three areas: time to market, customer satisfaction,
ness units at Cisco have transitioned to an agile and employee engagement. Because of the value
development method while others have not. Our added in these areas, the ATT focused on three
analysis below first examines how Cisco selects broad assessment questions: First, will the transi-
and helps business units and engineering teams tion to an agile development process help the busi-
transition to the agile development method. We ness unit reduce the time it takes to bring new
then analyze some of the new management prac- products to market? Second, will the transition
tices Cisco adopted to support and lead the agile significantly help the business unit develop the right
development practices. products to meet customer needs? And third, will
the transition increase employee engagement and
2.2. Research method morale? Only business units that can fully benefit
from the transition are good candidates for adopting
In this research, one co-author is a senior executive the agile method. In addition, Cisco’s experience
at Cisco who has led various business units using the also shows that it is not enough to clarify the
agile development method. Another co-author is potential benefits associated with transitioning to
directly responsible for helping business units at the agile method; it is also important to clearly
Cisco change from the waterfall to the agile devel- communicate such benefits to mid- to low-level
opment method and helping to establish new man- managers and to engineering teams.
agement practices to support agile development
practices. In addition to their direct knowledge, 3.1.2. Readiness assessment
we studied background information and various The ATT also identifies three conditions to assess if a
documents on Cisco’s agile development practices. business unit, including its engineering teams, is
We also conducted a broad range of interviews with ready for the transition. The first is leadership
people who played different roles in the agile pro- buy-in. Securing buy-in from engineering team man-
cess, including engineering team managers, product agers is important because they are the frontline
and program managers, vice presidents of the busi- people who guide engineers in implementing the
ness units that changed to the agile method, and agile process. The commitment from mid- to se-
trainers and coaches of the agile development nior-level managers in the business unit is also very
method. All the interviews were semi-structured important. During the transition to the agile devel-
and recorded; we interviewed certain individuals opment process, these managers will not only need
multiple times to avoid misunderstanding. Most of to adjust their own mindset and behavior, but they
the interviews were conducted by two interviewers will also need to support engineers and cultivate new
to ensure reliability. culture and behavior in the engineering teams. In
638 EXECUTIVE DIGEST

addition, managers will need to help agile engineer- other areas such as task interdependence and even
ing teams cooperate with other teams or other seating layout of engineers within a team. The ATT
business units during the agile development process. then makes suggestions or works with the business
The transition to the agile method is not a simple, units and their engineering teams to modify or to fix
one-off event; it is a long, gradual process that conditions or issues that are unfavorable for adopt-
requires continuous change, build up, and follow ing the agile method.
through to develop and reinforce new culture Next, the ATT provides training on the fundamen-
and behavior. Without continued support, people tals of the agile method to engineering teams. After
can easily fall back into old habits in their product the training, the ATT embeds a coach in the engi-
development process. All this requires strong com- neering team for several months to help the team
mitment and buy-in from the business unit leaders get the agile process started. After the engineering
and managers. In general, the benefits of adopting team starts the agile method, the coach will leave
the agile method are an important factor affecting for several weeks, occasionally returning to review
the buy-in from business unit executives and man- the team’s progress and to check on any issues or
agers. problems. For example, the coach may evaluate the
The second condition for transition readiness is percentage of product features the team planned
minimal task interdependence for the engineering but failed to deliver after each sprint. During the
team. Engineering teams adopting the agile method coaching process, it is important for the coach to be
need to deliver new product features every two flexible and, more importantly, to observe and learn
weeks. This requires very intense collaboration the operating culture of the engineering team and
and coordination among engineers within the team its business unit. It is also vital to understand the
and across the teams. If the tasks of an engineering motivation or the areas the engineering team or the
team are highly intertwined with other teams, it will business unit looks to gain through the transition to
increase the complexity and difficulty of executing the agile method. This knowledge helps the coach
agile development projects. To assess this, the ATT find effective ways to help the transition to the agile
examines if an engineering team’s task can be self- method that will be better received by the engi-
contained or if it is highly intertwined with other neering team and the business unit.
teams or units. For example, the ATT examines the Early at Cisco, people who delivered agile train-
architecture of the product that an engineering ing were separate from those who did the coaching.
team is working on. ATT favors teams that work The company found that this leads to a problem
on modular product architecture because such ar- where coaches did not know what engineers learned
chitecture allows engineering teams to work on self- in the training, and engineers did not know how to
contained and autonomous tasks, which is important apply the training content to real agile processes;
for the agile method. the trainers were not on site to help the engineers
The third condition is early-stage product devel- connect the training content to real practices. To
opment. If an engineering team is working on a address this problem, the ATT recently changed to
development project using the waterfall process make the same person do the agile training and
and the project is in mid to late stages, it will be coaching.
costly for the team to change its development In addition, since most trainers/coaches are con-
process mid-stream. In contrast, teams at the be- tracted outside agile experts, the ATT made efforts
ginning phase of a project can make the transition to ensure that their training content is consistent
with minimal disruption. and tailored to Cisco. To achieve this, the ATT
analyzed the lessons and learnings from the engi-
3.1.3. Supporting the transition neering teams at Cisco that went through the tran-
For the business units and their engineering teams sition, especially the successful ones, and made sure
that are ready—or almost ready—to transition to the these learnings are incorporated in the agile train-
agile method, the ATT typically goes through the ing. To objectively assess how well engineering
following process to help the transition. First, the teams adopted the agile development method,
ATT examines various areas or conditions that the the ATT used different performance metrics. These
engineering teams need to change to successfully included customer satisfaction in collaborating with
adopt the agile method. For example, the ATT Cisco agile teams, how well engineering teams de-
checks to see if the engineering teams have appro- liver pre-planned new product features in each two-
priate roles required by the agile method, including week sprint, net promoter scores (how likely people
scrum team master, product owner, and product who went through the agile transition will be
manager. If such roles are missing, the ATT helps to recommend the agile method to others), and
the teams put them in place. The ATT also looks at employee engagement. These metrics also help
EXECUTIVE DIGEST 639

the ATT learn in which area(s) an engineering team to develop new management practices to support
succeeded or failed in its transition and why, and and lead the agile process. Our analysis below fo-
how to help future engineering teams leverage the cuses on four aspects of management practices
learning to avoid similar mistakes. developed at Cisco: leading agile development
Cisco also learned that when a coach joins an teams, planning and forecasting, coordinating
engineering team to help the transition, the coach tasks, and recruiting early collaborative customers.
should not focus solely on the changes in the product
development process. Many times, the transition to 3.2.1. Managing and leading agile engineering
the agile method involves a broad range of issues teams
and parties. For example, the agile development Cisco’s practice shows that the transition from the
method requires frequent decision making on de- waterfall to the agile development method has a
veloping and adjusting new product features based fundamental impact on the roles and behavior of
on the feedback from collaborative customers. mid- to senior-level executives as well as engineer-
Many times these decisions go beyond engineering ing team managers. In the waterfall methodology,
teams. They involve other functional roles such as engineering team managers typically run meetings,
product manager and product marketing or require manage the task schedule, and are responsible for
the cooperation and coordination with other busi- delivering tasks. They are heavily involved in plan-
ness units or external partners. Typically these dif- ning, monitoring, and delivering individual work
ferent parties have their own interests, working products.
styles, and culture. Some departments or partners In contrast, management’s role under the agile
may work well with the transition to the agile method becomes decentralized as engineers take on
method while others may not. Due to this complexi- more authority to organize their work. Because agile
ty, effective coaches need to pay attention to these development teams need to deliver new product
broad issues and involve relevant stakeholders to features every two weeks, the interaction and in-
remove barriers for engineering teams’ successful terdependency among team members becomes ex-
transition to the agile practice. In addition, Cisco’s tremely important. Thus, it is more efficient for
experience shows that coaches should let engineer- engineers to interact with each other rather than
ing teams and business units know that there is no to go through team managers to resolve issues,
such thing as best practices in the agile develop- especially technical problems. As a result, both
ment method–—there are only better practices, and first-line engineering managers and mid-level man-
it is okay if the teams and business units do not agers must let go of traditional command-and-
achieve the best goals during the transition to the control management styles in order to give more
agile method. The key is to derive valuable learning autonomy to their teams. As one team manager
from the practices and to build a culture of contin- indicated about the waterfall process:
uous improvement. Besides training and coaching,
My boss used to come and tell me to get my
Cisco also developed standardized transition docu-
team to do this or do that. Now [after the
ments to help teams and business units change to
transition to the agile method], I tell him
the agile development method. For example, the
(the boss) that I cannot tell my team to do this
ATT developed CPDM (Cisco Product Development
or that; I can suggest (my boss’s idea) to them,
Method), a standard operating procedure to guide
but they will discuss and decide if that is the
engineering teams. In addition, Cisco set up an
right thing to do.
internal website to illustrate how to adopt agile
processes that meet industry quality standard poli- In leading agile development teams, managers also
cies like ISO-9000. The website includes tools and need to develop new behaviors. For example, in
effective practices from which engineering teams some business units at Cisco, mid-level managers
can learn and use in their agile process. Additionally, and first-line engineering managers attend engi-
Cisco conducts community building through internal neering teams’ biweekly product demo meetings.
conferences and workplace presentations to pro- By participating in these meetings, the leaders/
mote and educate employees on the agile method. managers can see the progress, make suggestions,
and ensure the team is moving in the right direction.
3.2. Challenge #2: New management The transition to autonomous teams in the agile
practices for the agile development method also opens up the possibility for managers to
method work in more flat organizations. For example, in one
business unit at Cisco, after the unit successfully
Once business units and engineering teams change adopted the agile development process, a director
to the agile development method, companies need in the unit had 45 engineers directly reporting to
640 EXECUTIVE DIGEST

him. Such breadth of oversight is only possible the plan would have to be short term–—several
because the director empowers engineering teams weeks at most.
and gives them a lot of autonomy. The practice at Cisco, however, illustrates that it
In addition, managers leading agile teams need to is possible to forecast and plan several quarters
learn to play supporting and servant leadership roles ahead under the agile development process. One
(Ambler, 2005a). For example, they need to focus business unit at Cisco developed the following pro-
more on helping their agile engineering teams com- cess to improve the accuracy and predictability of
municate and coordinate with other departments to its planning. This business unit adopted the agile
resolve obstacles or to protect their engineering method by talking to early collaborative customers
teams from excessive external requests. Some about new product features every sprint (two
teams at Cisco developed very efficient processes weeks) and releasing new product features to mar-
so mid-level managers could remove obstacles for ket every quarter (three months). Before an engi-
their engineering teams or escalate the obstacle neering team starts developing a new product, the
issues to upper-level management. Managers and product manager, product architecture manager,
leaders in this context can also play other supporting and other relevant managers carefully identify
roles, including helping their teams learn, reflect, use cases. These managers then translate the use
and improve their agile working process; motivating cases into engineering tasks, prioritizing tasks and
engineers; and helping them in their professional slotting them into future quarters, with an emphasis
development. on the first two to four quarters (i.e., the first six to
12 months). Because these plans look at detailed
3.2.2. Planning and forecasting in the agile engineering tasks, they are very specific. And while
development process the task plans will be adjusted, they give the engi-
Transition to the agile method also significantly neering team strong guidelines to organize and
affects management planning. Under the tradition- arrange future work. As the business unit executive
al waterfall process, Cisco follows a multi-phase summarized: ‘‘This is a bottom-up (planning) ap-
process to plan and arrange resources. The first proach and you get into many details


. You can
phase is the concept commit, followed by execution gain about six months’ predictability that is very
commit. Once a project enters an execution com- accurate, though not perfect.’’
mit phase, business unit and engineering teams This bottom-up approach rests on a two-team
define what they plan to deliver, what resources methodology that works as follows. When an engi-
they need, the scope of the tasks, and product neering team starts to develop the new product, the
features. When project execution begins, managers business unit establishes another team to continu-
expect monthly status reports and expect engineer- ously forecast and adjust the future plan. For a given
ing team deliveries based on pre-planned mile- product, as an engineering team (‘execution team’)
stones. The typical waterfall planning cycle is finishes the new product development of the first
12 to 18 months. Such a long planning cycle gives quarter and begins second quarter work, another
companies predictability in planning resources and team (‘planning team’) is established to plan the
arranging work. development tasks for the future two quarters (in
But in the agile development process, such long- this case, third and fourth quarters) with an empha-
term predictability can be difficult. Engineering sis on the upcoming one (in this case, the third
teams, for example, seek customer feedback after quarter). This planning team looks at very specific
every two-week sprint. Yet, because customer re- task items for the future two quarters, assessing
actions may change, establishing stable and predict- which engineering works are needed and whether it
able plans can be problematic. To overcome this makes sense to move certain development tasks to
challenge, scholars have analyzed the types of proj- earlier or to later quarters, or to take the tasks out
ects or circumstances in which either a traditional of the plan. They plan these tasks by relying on
planning method or the agile method is suitable customer feedback and engineering execution in-
(Boehm & Turner, 2003b). Some business consultants formation from the first quarter. These two teams
suggest that in the agile method, companies only continue this parallel working process as new prod-
‘‘schedule in detail several weeks ahead but not uct development continues.
several months, and only do a high-level scheduling In order to make specific task arrangements for
for future iterations’’ (Ambler, 2005b). These anal- the subsequent two quarters, the planning team
yses assume that planning for several months or meets with the execution team every other week
longer would only be possible in the agile method to seek feedback and comments on the proposed
if the plan was at a high level and not detailed. If plans. Because the execution team not only knows
companies did want to develop detailed planning, their own ability and development speed but also
EXECUTIVE DIGEST 641

has direct knowledge of customer requirements, the For interteam/interunit coordination, some agile
execution team can provide valuable insights in teams at Cisco work on products that involve multi-
these meetings. Sometimes, the execution team ple subproducts, such as hardware and software,
will tell the planning team they do not have enough which belong to different units or departments.
manpower to deliver the proposed plan over the Because the agile process is commonly used in
next two quarters or they cannot move certain software development while hardware develop-
features to other time slots because of prior com- ment follows a more traditional process, cross-de-
mitments to customers. At other times, the discus- partment/unit coordination challenges are created
sion between the planning and execution teams can when an engineering team working with other units
result in disagreements. Any disagreements be- switches to the agile method. As a result, Cisco
tween product and engineering managers about developed several solutions to mitigate cross-
engineering capacity and planning that cannot be unit/department coordination challenges. One is
resolved are sent to senior level managers for reso- through product design. When a product involves
lution. both hardware and software components, overall
The planning team is a dedicated team usually product architecture design must be well estab-
consisting of senior people–—such as senior product lished from the outset. The design provides a frame-
manager, user experience manager, and product work and flexibility for software teams to use the
architecture manager–—who have overall platform agile method to build and adjust new product fea-
knowledge and a wide range of expertise on the tures. It also reduces the possibility of drastic
product. It is critical that the business unit places changes later in the development phases, which
their best people in the planning team. Because the can be costly. Another solution is to modularize
planning team has one and a half months to develop the interfaces of different components (Thomke &
each quarter’s plan, it is under great time con- Reinersten, 1998). Cisco also established weekly
straints. Yet any mistakes by the planning team meetings where agile teams give other teams/units
can greatly affect the ultimate execution. As the updates on new product features. In addition, the
executive of the business unit indicated: ‘‘For the company created boundary-spanning roles such as
execution team, it is common that you have A or B or program managers, who coordinate all the constit-
C level players, but in this [planning] team, you uencies or subprojects.
better have all A players.’’ The agile method also creates new challenges in
coordinating with external development partners.
3.2.3. Coordination in the agile development In the agile method, engineering teams need to
process constantly work with collaborative customers to
At Cisco, when engineering teams change to the test features, get customer feedback, and adjust
agile development method, new coordination com- future development work. If the teams rely upon
plexities arise at three levels: within agile develop- external partners for their development work, it will
ment teams (intrateam coordination); across require continuous and very close collaboration with
different teams or departments (interteam/inter- the external partners to synchronize their efforts.
unit coordination); and between the company and Problems can quickly occur if the Cisco agile devel-
its external partners. opment teams and their external partners are out of
At the intrateam coordination level, when engi- sync or miscommunicate. In one agile development
neering teams finish developing features at each project, Cisco had to rework about 80% of the
two-week sprint, they will immediately let custom- software code provided by an external partner
ers try the features. This requires that within each due to lack of communication and coordination,
agile sprint, engineering teams not only finish new which caused significant stress and problems to
feature development, but also complete other tasks the project. Because of the risks posed by situations
such as unit testing and code review. Accomplishing like this, it is very important to build closer coordi-
these many tasks within each two-week cycle de- nation and monitoring mechanisms with third par-
mands intense and effective coordination among ties on agile development projects.
engineers within the agile team. To achieve this,
Cisco co-locates engineers of the same team, re- 3.2.4. Recruiting collaborative customers
duces or avoids multitasking of the engineering Cisco’s experience also illustrates the potential
teams, and optimizes team size (about seven to challenges in recruiting collaborative customers
nine people). In addition, Cisco created open space who provide feedback to Cisco’s agile development
to allow engineers to collaborate and interact, and teams. These customers are different from ordinary
built a strong suite of collaboration tools to enable customers. Collaborative customers are typically
engineers in multiple locations to collaborate. early adopters of new products; they need to know
642 EXECUTIVE DIGEST

how to effectively work with external agile engi- of the new products. Managers should then use the
neering teams, be able to use unfinished products criteria to guide the selection and recruiting of the
that are under development, and be willing and able collaborative customers.
to adjust their use of the products. Sometimes,
multiple departments within the collaborative cus-
tomer group will be involved in using and testing the 4. Conclusion
products under agile development. Not all custom-
ers are qualified for such tasks. As a result, if agile The Cisco experience suggests that when companies
development teams do not give enough consider- change to the agile development process, they need
ation to these unique characteristics when recruit- to tackle two major challenges. The first is to help
ing collaborative customers, the teams may recruit teams or business units within the company to make
wrong customers that could undermine the agile the transition, and the second is to develop new
development projects. management practices that can support agile de-
In addition, agile engineering teams at Cisco velopment method. We summarize these lessons in
typically rely on other departments at Cisco to Figure 2.
recommend and recruit early collaborative custom- Besides the key learnings summarized in Figure 2,
ers. Sometimes the departments recommend such we next highlight a few other implications of adopt-
customers based largely on their own interests, ing the agile development method. Our study shows
including the desire to please customers or to influ- that companies need to take a holistic, systematic
ence certain sale deals, even though these custom- approach to handling the transition to the agile
ers might not be appropriate to serve as agile development method. Although this research focus-
collaborative partners. For example, when such es on the experience of Cisco, a large company, it
customers’ needs are incompatible with the direc- also sheds light on the challenges of adopting agile
tions or market positions of the developing prod- development practices by small to medium-size
ucts, the customers’ feedback can steer the product companies. For example, as discussed earlier, com-
development in the wrong direction. panies need to recruit the right customers to help
This misdirection occurred at Cisco. An agile steer their agile development process; talking to the
engineering team at Cisco planned to develop a wrong collaborative customers can lead to costly
new product that was positioned as a horizontal detours for the company. On the other hand, only a
platform for companies from a broad range of sec- small subset of customers is qualified to serve as
tors. Another department recommended a financial early collaborative customers. This dilemma
institution as a collaborative customer. However, presents challenges for small to medium-size com-
the financial institution asked the agile develop- panies. Small customer pools and limited resources
ment team to put extra layers of security and will reduce their ability to find the right early
privacy protections on the product. Although com- collaborative customers. This type of challenge
mon among financial institutions, these requests could be especially true for small to medium-size
were not appropriate for a horizontal platform companies in B2B space where the customer base
where open access is important. Yet this financial tends to be more limited and more relationships
institution was an important customer and had a lot would be required to recruit collaborative custom-
of clout in influencing the product direction. It took ers.
the product development unit over a year to stop This study also sheds light on the challenges that
the misdirection. It also forced the agile team to the agile development process poses for global
redo much of its development work and caused operations. Our study illustrates that the agile
delay in the development process. method demands close and intense coordination
Based on Cisco’s experience, one solution to with customers and requires organizational units
address the above problem is to work with multiple and engineering teams to be self-contained and
collaborative customers, which allows engineering autonomous. These characteristics create new chal-
teams to compare and validate different customers’ lenges for global integration and global operation
feedback. Another solution is to clarify the require- where employees and organizational units from
ments for early collaborative customers from the different countries work together on certain proj-
onset. One executive at Cisco indicated that before ects. Such multi-location operations lead to more
selecting early collaborative customers, related coordination complexity, which can be detrimental
managers—such as product and engineering manag- to the agile development process. As more compa-
ers—needed to get together to identify the charac- nies adopt the agile development method and as
teristics and qualifications of the collaborative globalization and integration further develop, com-
customers based on the market position and nature panies will have to find new global operating models
EXECUTIVE DIGEST 643

Figure 2. A summary of management tasks to cope with the organizational transition to the agile development
method
New management practices to enable and support
the agile development process

Leading agile engineering teams

Actions to help the transition
to agile process • Reduce micromanaging. Delegate and empower
engineering teams. Focus on serving and
• Identify potential benefits
supporting agile teams by removing task barriers
for transition to an agile
and garnering cross-team/department supports.
method (faster to market,
Planning & forecasting in the agile development
right products, and higher
process
employee engagement).
• Dual-team approach. One team focuses on
• Three criteria to assess the developing new products, the second team
Transition
readiness of business units continuously plans and adjusts tasks of future two
to make the transition to quarters (six months).
the agile method Coordination in the agile development process
(leadership buy-in, task
interdependence, and • Intrateam coordination. Need to reconfigure
stages of the tasks). engineering teams, including co-locating
engineers within the same team,
• Multi-step efforts to help reducing/avoiding multi-tasking, optimizing team
the transition, including size (about 7 to 9 people), etc.
adjusting working • Cross-team/Unit coordination. Well thought-
conditions, agile training, through product architecture design to provide
embedded coaching, review clear framework, modular interface design to
for further improvement, provide flexibility, regular cross-unit/department
internal website to show info. Sharing, cross-unit coordination by program
best agile practices, etc. managers, etc.
• Coordinating with external co-development
partners. Requires more tight and intimate
coordination mechanisms with the external
partners.
Recruiting early collaborative customers

• Working with multiple collaborative customers to

minimize the risks of being influenced by wrong
collaborative customers.
• Need to clarify the criteria of early collaborative
customers and use the criteria to guide the
recruiting of early collaborative customers.

to reconcile the potential conflict between fast- Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunning-
paced agile development processes and multi-coun- ham, W., Fowler, M., et al. (2001). Manifesto for agile soft-
ware development. Retrieved February 8, 2016, from http://
try global operations. In sum, although this study agilemanifesto.org/
only analyzes a small set of management practices Boehm, B., & Turner, R. (2003a). Balancing agility and discipline.
associated with the adoption of the agile method. In F. Maurer & D. Wells (Eds.), XP/Agile universe (pp. 1—8).
We hope our work will invite more research analyz- Berlin: Heidelberg.
Boehm, B., & Turner, R. (2003b). Using risk to balance agile and
ing new management practices and systems to en-
plan-driven methods. Computer, 36(3), 57—66.
able and support the implementation of the agile Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to
development method. agile methods. In M. V. Zelkowitz (Ed.), Advances in computers
vol. 62: Advances in software engineering. Cambridge, UK:
Academic Press.
References Gandomani, T. J., & Nafchi, M. Z. (2015). An empirically-
developed framework for agile transition and adoption:
A grounded theory approach. Journal of Systems and Software,
Ambler, S. (2005a). Roles on agile teams: From small to large 107, 204—219.
teams. Ambysoft. Retrieved February 9, 2016, from http:// Gandomani, T. J., Zulzalil, H., Ghani, A. A. A., & Sultan, A. B. M.
www.ambysoft.com/essays/agileRoles.html (2013). Towards comprehensive and disciplined change man-
Ambler, S. (2005b). Agile project planning tips. Ambysoft. Re- agement strategy in agile transformation process. Research
trieved February 9, 2016, from http://www.ambysoft.com/ Journal of Applied Sciences, Engineering, and Technology,
essays/agileProjectPlanning.html 6(13), 2345—2351.
644 EXECUTIVE DIGEST

Hoda, R., Noble, J., & Marshall, S. (2011). Developing a grounded methods in practice. The Journal of Systems and Software,
theory to explain the practices of self-organizing agile teams. 81(11), 1899—1919.
Empirical Software Engineering, 17(6), 609—639. Strode, D. E., Huff, S. L., Hope, H., & Link, S. (2012). Coordina-
James, M. (2010, March 15). Obstacles to enterprise agility. tion in co-located agile software development projects. Jour-
Collabnet. Retrieved February 9, 2016, from https://www. nal of Systems and Software, 85(6), 1222—1238.
open.collab.net/media/pdfs/How_to_Steer_Large_Scale_ Thomke, S., & Reinersten, D. (1998). Agile product development:
Development.pdf Managing development flexibility in uncertain environments.
Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of California Management Review, 40(1), 8—30.
migrating to agile methodologies. Communications of the Turner, R., & Boehm, B. (2003). Balancing agility and discipline: A
ACM, 48(5), 72—78. guide for the perplexed. Boston: Addison-Wesley/Pearson
Qumer, A., & Henderson-Sellers, B. (2008). A framework to Education.
support the evaluation, adoption, and improvement of agile