Custom Writing Service http://StudyHub.vip/Agility-At-Scale 👈

1. Chapter 4
Agility at Scale
4.1 Introduction
Majority of business leaders know about agile innovating teams. The business group,
which is being small, are intended to remain connected to clients and adjust rapidly
to evolving circumstances. They quite often result in superior efficiency, lower risk,
and less duration to introduce the product to market and provide improved quality in
contrast with conventional methodologies, when executed accurately. Agile method-
ologies are not just bounded to simply the small and collocated group conditions that
are being advocated in early literature but have been adjusted to work in a wide vari-
ety of circumstances. Agile methodologies are being used all through the lifecycle
of the software development, not simply the development phase, and regularly in
complex situations that require more than the small and collocated team. The overall
objective of each team working in a project is to cope with unique problem, with its
own objectives, capacities. The common factor among these groups is to embrace
change in its own way and after that adapts agile strategies, practices, and provides
the most refined way to deal with those unique situations. Normally, there are many
common queries that are arising in the minds of practitioners that have experienced
or heard about the agile methodologies/groups. Imagine a scenario where an organi-
zation wants to launch handfuls, hundreds, or may be a huge number of agile teams
all through the firm? Is there a possibility that entire segments of the business are
trained to function in this way? As coordinated techniques enhance individual group
execution, would extend the agile enhanced business routine to a great deal in case
of an individual team?
In the present turbulent markets, where organizations are irately fighting from
startups and rebellious opponent, the possibility of moving quickly and adaptation
is very significant. In any case, transforming it into a reality can be demanding. It is
very difficult for organizations to realize what functions ought to be recognized in
multi-disciplinary agile teams. It is not advisable to initiate many fresh agile teams
© Springer Nature Switzerland AG 2020
S. V. Zykov and A. Singh, Agile Enterprise Engineering: Smart Application
of Human Factors, Smart Innovation, Systems and Technologies 175,
https://doi.org/10.1007/978-3-030-40989-0_4
55

2. 56 4 Agility at Scale
just to observe them bottleneck by bureaucratic administration. The change from
conventional chains of command to increasingly agile enterprises has confirmed that
there is more to gain by using these strategies. It also has considered the scaling up
the agile in many organizations, including little companies that entirely work with
agile methodologies. Spotify and Netflix are the examples of a large organization
that was born agile and companies like Amazon as well as USAA (the company
which handles the financial matters for the military) are transiting themselves from
conventional to more agile endeavor. It may provide the benefits to the companies by
enhancing the performance but to do so the leader should have a realistic view. There
are some situations where agile cannot be implemented, as a matter of fact that not
each project requires agile methodology. When you start launching some or many
agile teams, though, you cannot simply leave alone other parts of the business. In
new agile units, an absence of coordinated effort among operations and development
groups or bottlenecks by bureaucratic strategies, a disagreement may arise among
organization teams, which would prompt the poor outcomes and the differences.
Alteration is essential to make sure that the function that does not work as agile
teams support the teams that work in agile.
4.2 Understanding the Scale
Initially in 2000s, projects developed with agile methods were little in scope and gen-
erally simple. The techniques of the agile methods (like small and colocated teams)
still are able to do the tasks in these particular circumstances. In today’s era, advance-
ment in agile methodologies is applied to the broader set of projects as the percep-
tion of the organizations has changed considerably. Organizations frequently manage
issues that require large teams; distributed workforce; collaborating with other orga-
nizations; meet the terms of the policies and industrial standards; and addressing
technical or social problems. Each project team has its own difficulties and different
scaling factors; however, these issues add multifaceted complexities, and techniques
should be discovered to overcome these challenges. The agile restrained delivery
process needs to adjust, or scale to manage the numerous businesses, organizations,
and technical complexities your development organization faces [1].
• Large and Distributed Teams
Standard agile procedures work great for lesser groups of ten to fifteen individuals
yet imagine a scenario in which the group is a lot bigger. Since the size of the team
expands, the communication risks increase, and coordination turns out to be increas-
ingly troublesome. Thus, classic face-to-face communication techniques begin to
fall apart. Consider a scenario when the team is dispersed—maybe on the different
story inside a similar building, diverse areas inside a similar city, or even in various
nations? What occurs if you allow your employees to work from the home? What
occurs if your team is distributed in various time zones? All of sudden, collaboration
turns out to be all the more difficult and separateness is bound to happen.

3. 4.3 Leading Agile by Being Agile 57
4.3 Leading Agile by Being Agile
Teams working in agile methodologies are most appropriate for development where
creativity is to improve the quality of the products, methods, and services or the
business. It works in a modular approach in which huge and complex issue is bro-
ken into modules, produces a well-managed solution for every part through quick
prototyping and time-bound responses loops, and incorporates the solution into a
coherent entirety. They are adapted to change rather adhering to a particular plan,
and they consider themselves responsible for outcomes (e.g., development, benefit,
and client faithfulness), not for outputs (e.g., coded lines or the items produced). In
any circumstance where issues are unpredictable, solutions are not clear instantly,
project prerequisites are probably going to change, and these conditions are ideal
for agile development. The close coordinated effort with end clients is doable, and
creative groups may beat the performance of command and control teams. There
are many routine tasks, which are less prolific (e.g., maintenance, purchasing, and
accounting) where agile development may not prove fruitful. Agile techniques first
introduced in IT divisions and are now broadly utilized in software development.
With the passage of time, these methodologies have spread into different areas, for
example, HR, product improvement, and promoting [2, 3].
The working method of the agile team is unique in contrast to hierarchical admin-
istrations. They are mostly self-organizing: There is always guidance available to
colleagues by their senior colleagues, where to improve yet not how and the groups
work closely with clients. In a perfect world, this puts duty regarding innovation in
the hands of the individuals who are nearest to clients. It lessens levels of control,
subsequently accelerating work, and expanding the teams’ innovation. It likewise
frees up senior leaders so that they do what no one but only they can do: setting
up the vision, arrangement of key needs, and fabricate the authoritative abilities to
accomplish the determined goals. The moment at which leader may attempt to scale
up agile development in the manner in which they have approached the other method-
ologies, e.g., by top-down approach or by command. This may lead to chaos in the
team. The precedence is set by the executive team and corresponding chances to get
better clients’ experiences and improve their success rate. To take care of issues, the
leaders take the charge and remove the restriction other than assigning tasks to assis-
tants. Leadership teams of the agile, alike other teams of the agile, has an “initiator”
who is in charge of general outcomes and a catalyst who mentors colleagues and
helps keep everybody effectively occupied [4].
4.4 Getting Agile Rolling
In advanced agile enterprises, the visions are ambitious. However, it is not possible
for the leadership to plan everything up front that may be going to happen. Leaders
cannot distinguish that it is not known at this stage how many agile teams are needed

4. 58 4 Agility at Scale
for this purpose, how rapidly they should include them, and in what context they
should encounter technical limitations without putting the organization into chaos.
As a result, they can commonly introduce the initial phase for the agile team, collect
information on the behalf of those teams, the difficulties and the barriers they face,
and afterward choose what to do, when to do, and how to achieve this. These provide
a chance to determine the benefit of expanding agile (as far as budgetary outcomes,
client results, andworker performance) against its expenses (regardingbothmonetary
speculations and organizational difficulties). To implement the agile in other sections
of organization the main concern is whether the benefits exceed the costs; leaders
can keep on scaling up agile—deploy other agile teams, the organization has to
unblock restrictions in those parts of it, which are less agile. If it is not there, they
can take a break, keep an eye on the market condition, and investigate approaches
to expand the charge with regard to agile teams (e.g., by giving the preferences to
the task or improvement abilities for creating blueprint) and lessening the expenses
of modification (by broadcasting the agile success or recruiting experienced agile
devotees). To begin on test-and-learn cycle, management can regularly utilize two
basic devices: a scientific classification of potential teams and a sequencing plan
reflecting the organization’s key needs. Allow first to take a gander at how each can
be utilized and afterward investigate what more is expected to handle extensive scale,
long-term agile activities.
4.5 Create Taxonomy of Teams
Similarly, as agile compile backlog of work going to implement in future iterations,
organizations that effectively upgrade agile usually start by making a full taxonomy
of the opportunities. Taking actions using agile’s modular approach, they can divide
the taxonomy into three parts—customer experience groups, group associated with
business procedures, and development systems groups—and afterward integrating
all the parts. The first segment distinguishes all the issues that could fundamentally
influence external and internal client decisions, behavior, and fulfillment. The second
level considers at the associations among these segments and important business
forms, planning to minimize overlapping responsibilities and cooperation exertion
between procedure and customer experience groups. The third spotlights on creating
innovation frameworks (e.g., better portable checkout applications) to improve the
procedures that bear client experience teams.
The people in charge of business units and product lines can be tied to the activi-
ties of agile teams. The manager in charge is responsible for the explicit parts of the
product development and sees how cross-functional and self-organizing teams affect
their outcomes, and it is the sole responsibility of the senior member who is working
as a general manager in the company. Yet, leaders depend on client engagement,
cross-functional teams to complete a significant part of the work. There is a depen-
dency of the organization, which relies upon technical and resources based on digital
technology assigned to the experienced staff; the objective can be to guarantee that

5. 4.5 Create Taxonomy of Teams 59
the higher authorities in business possess all the required resources for providing the
outcome which they have in their mind. The main aim of the taxonomy is to ascertain
that the right set of people have been engaged in the right set of tasks to eliminate
confusion This sort of link is particularly essential if there are many levels which do
not align with the conduct of the clients.
4.6 Sequence the Transition
Taxonomy ready, the management can initiate the transition process based on its
priorities. There are multiple criteria for initiating transitions, e.g., ROI, availability
of resources, interdependence of teams, etc. Some important issues that have been
overlooked by customers/employees on the one hand and constraint of the organiza-
tion on the other hand can create problem in agile transformation. These overlooked
issues if given proper weightage can help set right balance between the pace of agile
roll-out and number of teams that organizations can handle. Companies facing strate-
gic threats have pursued big bang change. In 2015, the Netherlands face the same
threat, including IT development, project management and abolish all the job roles.
By then, it created minimal agile “squads” which requires around 3500-man force
to reapply for 2500 overhauled designations of the squads. There is an extreme dif-
ference in about 40% of the staff occupying the designations expected to adjust new
occupations and all expected to altogether change their mindset [5]. It is always not
possible to bring change in one shot. To modify, it requires full-scale management
support, an open culture, skilled and experienced agile practitioners to staff teams
without draining their diverse capacities, and profoundly prescriptive guidance man-
uals to adjust everybody’s behavior. They similarly need a high tolerance of risks,
alternative approaches to oversee unanticipated breakdowns. ING continues settling
wrinkles, as it becomes lightweight throughout the enterprises.
4.7 Roll-Out Agile in Steps
Many organizations adopt shortcut methods and made mistakes. The teams are man-
aged from offsite location. They try to create a way around to systemize obstacles.
This rather alleviates the chances of success for the team, but it disrupts the learning
process or chances of scaling of the teams from a few too many. The agile team, which
is deployed in the early stages of the organization, carries the burden of destiny. It
is like a test for that team as a testing a product prototype under several circum-
stances. Before rolling agile, organizations have to do some groundwork. In reality,
rolling agile does not mean that success is sure if things are arranged systematically.
It implies that the teams should be focused on a business prospect, responsible for
outcomes, trustworthy to work without dependency, guided by clear choice rights,
legitimately resourced, and working in a small team having specialists in multiple

6. 60 4 Agility at Scale
Fig. 4.1 Rolling agile
domains that are enthusiastic regarding the chance (see Fig. 4.1). Along with these
teams must be dedicated to agile value implementation, standards, and practices,
authorized to work together intimately with clients, able to make quick models and
quick input cycles, and support from higher officials will deal with an obstacle and
drive the selection of the collaboration.
4.8 Master Large-Scale Agile
There is a misconception among managers in having trouble in visualizing little agile
groups which can affect the projects that run for long-time duration and are of large
scale. Principally, no restriction is there for creating a number of agile teams and the
time span related to the activities. You can create “teams of teams” that take a related
activity—a methodology that is profoundly adaptable and scalable. It is required by
the organization that their leadership teams instill agile values.
4.9 Building Agility Across the Business
It is a vital step to increase the number of agile teams in order to increase business
agility, and however, equally important is whether the communication is taking place
within a team or teams with the rest of the organization. Indeed, even the most
progressive agile organizations like Amazon, Spotify, Google, Netflix, Bosch, Saab,
SAP, Salesforce, Riot Games, Tesla, and SpaceX work with a blend of agile and
conventional teams. The following areas guarantee that bureaucratic functions do not
hamper effort by agile teams or neglect to embrace agile and market the innovation
created by those teams; such organizations always push for change that is more
prominent.

7. 4.10 Values and Principles 61
4.10 Values and Principles
A few agile teams sprinkled around the traditional hierarchical organizations can be
used to initiate the agile within the company. There may arise clashes between the
agile teams and traditional methodology of developing the software, the personal
interference as well as workarounds are needed for settling the matter. When an
organization launches a few hundred agile teams, then this sort of ad hoc arrange-
ment between agile teams and traditional methodologies is never going to work.
Generally structured parts of an organization maintain the status quo, whereas agile
team will work hard on each front for the progression of the business. Likewise, if
any change happens, the disbelievers of agile develop the antibodies and rise doubts
on agile methodologies, going from refusals to work on a timeline to the reten-
tion of funds from opportunities that require developing innovative solutions. The
parts of the organization that doesn’t organize into agile teams must be included by
the leadership group of the organization wanting to scale up agile needs to impart
agile values and principle all through the projects. Agile would be at the nucleus
of the organization culture as the new management standards might be fanned out
all through the organization to guarantee that everybody comprehended that things
would be unique.
4.11 Operating Architectures
Modularization is required for executing agile at scale and afterward consistently
integratingworkstreams. Inthecompany’s multifacetedframeworks, anorganization
can deploy software many times each day since its IT engineering was intended to
enable designers to make quick, releases without any hustle. However, numerous
large organizations, regardless of how quick they write the code for the programs,
can deploy the software just a couple of times each day or even in a week; that is
how their architecture works.
In organizations that extended agile, organizations outline the support procedures
and routine activities largely look the same as they did before, however, with less
control hierarchies and wider range of control as a leader figure out how to trust and
enable individuals. The bigger change is the way functional division works. Utilitar-
ian needs are essentially lined up with corporate methodologies when organizations
key needs are set such as improving clients’ mobile practice that cannot be used on
the last of the list, e.g., at the 15 locations on the account’s funding list or HR’s hiring
list (see Fig. 4.2). Furthermore, offices, for example, legal may require buffer ability
to manage imperative needs from high-precedence agile teams [6].
Routine activities with various leveled structures are probably going to grow
progressively toward agile over time. Obviously, it is included in the routine work
of the finance divisions that they will dependably oversee spending plans; however,
they do not have to continue scrutinizing the choices of the owners of agile activities.

8. 62 4 Agility at Scale
Fig. 4.2 Agility across
business
These trades-offs are hard to accept and tough to implement for a few people and
organizations. If you find that individuals are more joyful and success rates triple,
then it is a good decision to reducing control on the teams.
4.12 Talent Acquisition and Motivation
Organizations that are scaling up the agile teams need a framework for obtaining
experienced, valuable resources, and inspiring them to improve teams. They likewise
require releasing the capability of colleagues and imparting responsibility, commit-
ment, and trust to achieve results. There’s no pragmatic method to do this without
altering HR strategies. An organization can never again employ only for technical
skill, for example; it now needs skill in conjunction with passion for working in a
self-organizing team. It is not an accurate criterion to assess individuals as indicated
by whether they achieve their primal: It now needs to take a gander at their exe-
cution on lightweight teams and at colleagues’ evaluation of each other. Execution
appraisals normally move from a yearly premise to a framework that gives perti-
nent feedback and training at regular intervals of weeks or months. Coaching and
training programs support the improvement of cross-functional abilities redid to the
requirements of the employees. Position in the organization matters less and changes
less often with self-overseeing groups and less hierarchical levels [7]. Vocation ways
show how item proprietors—organization vision and possess the repercussion of an
agilegroup—canprecedewiththeirself-dependent,growtheirimpact,andincrement
their pay.

9. 4.12 Talent Acquisition and Motivation 63
Organizations may likewise need to reconsider their pay frameworks to compen-
sate the team as opposed to individual achievements. They need acknowledgment
programs that praise commitments right away. Open acknowledgment is superior to
secret money rewards at reinforcing the qualities—it rouses beneficiaries to improve
much further, and it persuades others to imitate the beneficiaries’ practices. Leaders
can likewise remunerate a team member by drawing in them in challenging tasks,
furnishing them with the most progressive tools and the best conceivable opportunity,
and associating them with the most capable guides in their field.
4.13 Annual Planning and Budgeting Cycles
Yearly planning and financial discussions are the most substantial tools for regulating
the organization and verifying commitments to extend objectives, but agilist starts
with other pre-assumptions. Usually, customer needs change as regularly as would
be prudent and that cognizance can happen anytime during the project lifecycle. In
their view, yearly cycles restrict innovation and modification: Unproductive ventures
devour assets until their financial plans ran out, while important innovation sits aside
in line for the next financial cycle to raise funding.
There could be different financing methodology in an organization that works
in conjunction with an agile team. The financiers accept that in 2/3 of the positive
innovations the underlying perception will alter amid the product improvement life-
cycle. They expect that product improvement groups will drop a couple of features
and deploy others without waiting for the following yearly cycle. Investor normally
observes financing decisions as opportunities to purchase options for further expo-
sure. The goal isn’t to immediately make a substantial scale business yet, rather, to
locate a critical segment of the eventual solution. However, this prompts numerous
failures yet enlivens and diminishes the cost of learning. Such a philosophy functions
well in an agile organization, hugely improving the speed and efficiency of innova-
tion. The majority of the agile test-and-learn techniques are dynamic and iterative in
nature, and however, nobody should confuse incremental development forms with
incremental thinking. SpaceX, for instance, expects to utilize agile development to
start transporting individuals to Mars by 2024, with a dream of building up an inde-
pendent colony on that planet. Presently, the query is how it turned into a reality? It
isn’t arranged, yet the individuals working in the organization have a faith that it may
be conceivable and have a dream for this. They need to lessen the expenses mostly
by reusing rockets as this can be possible in case of airplanes also and improve the
consistency. Following are some of the points that need to be critical thinking in
planning.
• Domain Complexity
Some applications require the straightforward solution of the projects such as devel-
oping an application, which handles data entry of the organization or a simple website

10. 64 4 Agility at Scale
for information. Agile methodologies can give good results where the problem state-
ment is complicated such as measurements of a biochemical procedure. Some tasks
involve varying situations such as financial derivative trading. As the field is more
multifaceted, it requires huge importance on the exploration and carrying out large
experimentation, as well as not confined to prototyping, modeling, and simulation.
• Organization Distribution
There might be conditions when a team incorporates people from different divisions,
associated organizations, or from outside firms. The more hierarchically dispersed
teams are, the almost certain the relationship will be authoritative in nature rather
than collaboration. An absence of the administrative cohesion can phenomenally
expand the risk of the project in light of the absence of trust and trust which may
diminish the capacity to collaborate and can grow the risk with Intellectual property
(IP). Sometimes a couple of applications are more complex than others. Sometimes,
your team work with legacy frameworks and legacy data sources that are not com-
pletely perfect. Some other time, you are building a framework for heterogeneous
platforms or for few distinct technologies. Likewise, at different events the sort of
the issue your team is attempting to solve is complicated in its own right, requiring
an intricate arrangement.
• Organization Complexity and Discipline
Your current association structure and culture may reflect waterfall values, expand-
ing the multifaceted nature of embracing and scaling agile procedures inside your
organization. Then again, a few teams inside your organization may wish to pursue
techniques that are not superbly perfect with the way yours needs to work.
The primary goal of any organization is to drop down the costs, lessen the time to
reach the product to the market, improve consistency, and continuous evolvement.
This can be troublesome if your development team focuses just on their immediate
requirements. To use regular infrastructure, development teams need to exploit orga-
nization archetypes, business models, and portfolio management. These disciplines
must work together with, and even better improve, your agile development process.
Regardless, this does not come free. Agile teams need to incorporate architecture spe-
cialists as partners. The project specialists also need to make sense of how to work
in an agile way, a way that may be altogether different in contrast to the manner in
which they have worked.
• Organizing Large Teams
At the point when agile groups involve no less than 30 people, it is viewed as large
team. A substantial group (large team) may be divided into subgroups. Some other
explicit roles need to be added in the large agile teams especially leadership and
coordination roles. These jobs for coordination are alluded to as the coordination
group. Sometimes large teams require an integrator, yet this isn’t a mandatory job
and not normally utilized by the administration. By and large, team coordination is
taken care of by the leadership group, which is ordinarily headed up by someone

11. 4.13 Annual Planning and Budgeting Cycles 65
in the activity of program coordinator, every so often implied as an undertaking
executive, who is in generally overall in charge. The leadership team comprises of
the persons in senior jobs. Together, these individuals address the aspects of team
cooperation.
Any issues that emerge among the teams are regulated by organization subgroups
(PO, Project Management) by means of group meetings and by electronic techniques
as required. Numerous agile groups find that these coordination issues have distinct
rhythms. For example, requirements and technical coordination occur toward the
beginning of every iteration, however, diminish later in the cycle, yet coordination
is required every day and throughout the iterations of the project. An increasingly
critical need exists for shared models, documentation, and plans, particularly if the
group is geographically distributed. Utilization of incorporated tooling that is instru-
mented to give key measures, which thusly are shown on project dashboards, can
give more exclusive perceivability of what’s going on inside the group and in this
manner help coordination.
4.14 Best Practices
It is very tricky to standardize techniques for working. It is likewise hard to perform
well, however, simple to do poorly. Standard methods for working are related to
making a normal way for working that makes it simpler to complete things, lessen
friction, and empower collaborative effort and effective utilization of time. Joint
effort and transparency must connect to customers and business stakeholders than
enterprise only. Making such a communitarian organize through dynamic affiliations
and collective ecosystem for value creation requires extensively higher degrees of
empowering people. The question emerges here why? These forefront workers can
work hands-on with clients, sellers, and other parties for the development of new
solutions, services, and products. This cohesion just originates from a sound cul-
ture reinforced fundamentally through leadership role models, peer pressure, and
fit-based enrollment and not through strategies, rules, or order and control chain.
Job adaptability is vital. This implies your role on some random day and for some
given group may change in all respects rapidly as needs change and new opening
emerges. Typically, mobilization of role among team members requires an inside
talent market to help match individuals with the most appealing and value-oriented
roles they could play. Organizations that made inner talent markets get enormous
advantages because the market regularly can match individuals and work signifi-
cantly more adequately and effectively than various hierarchical decisions cascaded
down the organization. The new innovations are utilized which are as proficient and
versatile in nature share information. Big data and artificial intelligence will require
agile organizations to keep up a practically unprecedented level of cross-functional
coordinated effort among innovation, digital groups, and the business. Technology
must have measured, adaptable engineering to react to quick evolving needs. It must
be integrated flawlessly with key procedures, so it is simple and natural for clients.

12. 66 4 Agility at Scale
On a fundamental note, the organization ought to be very far along its journey
before scaling agility over the entire organization. That is the most ideal reason to
have some successful pilots added to repertoire to help gauge the value that can
achieve when you do start scaling agile enterprise.
• Leverage a strategy that works for you
Leading toward agile requires some extensive changes in terms of roles and responsi-
bilities, organizing and the software development lifecycle itself. This is when firms
would benefit by assessing their approach in achieving agile and guaranteeing that
it accommodates their project needs. There are various choices to choose from, e.g.,
large-scale scrum, concerning how scrum can be connected in numerous dimen-
sions to suit large-scale improvement—and disciplined agile delivery—which is a
people-first, learning-focused mixed agile methodology.
• Break down big jobs
In large enterprises, there is likely going to be huge teams of individuals committed
to projects. It is a challenging situation and makes things extensively complex while
coordinating everyone, particularly if employees are disseminated across organiza-
tion areas or work remotely. In Leffingwell’s book “Scaling Software Agility: Best
Practices for Large Enterprises,” he noticed that in conventional development mod-
els, problems can be overwhelming and can affect job satisfaction across teams (see
Fig. 4.3).
However, the main perspective of agile is that it splits the whole work into smaller
tasks so that they can be handled easily. This will enable the team to keep on the
schedule list, monitor changes being made, and reduce risks. Utilizing agile test
management instruments help teams stay aware of activities, regardless of whether
individuals are not working at the same location. The real-time updates will ensure
that everyone is always on the same page, eliminating redundancies, and helping
improve overall employee satisfaction. This will help facilitate continuous develop-
ment efforts and enable teams to roll out updates faster and more frequently than ever
Fig. 4.3 Best practices in agile implementations

13. 4.14 Best Practices 67
before. “With agile, progress and job satisfaction are constant, frequent, and in real
time,” Leffing well wrote. “The next opportunity to show your wares to a customer,
peer, or other stakeholder is at most a week or so away” [8].
• Scale-up and Scale-out
There are many significant variations that occur in agile software development in con-
trast with how the development team handles the work, yet it can likewise influence
how the organizations advance to keep pace with competitors. Agile has the capabil-
ity to answer the question regarding success and failure in the long term according to
ZDNet contributor Stephen Younge. Younge gave the case of a producer that could
develop from a group of 100 designers to more than 1200 by pursuing a large-scale
agile transform. This enabled the organization to improve employee engagement by
almost 10%, lessen the time to market and production by 20% each and decline
field issue goals time by 42%. For organizations, agile should not simply scale up
to help the developing number of employees; it should likewise scale out over the
value chain to deliver the valuable product. That even if large enterprises cannot be
supported by all values in the Agile Manifesto, taking those concepts and stretching
them will help achieve agility at scale.
4.15 Failure of Agile in Large Organization
Agile software development methodologies have benefited various teams and orga-
nizations regardless of their sizes but the actual effect on business depends upon
how the integration of these methodologies into their operations. Agile may give a
significant advantage over traditional devolvement methodologies but the journey of
this transformation may not be so easy. According to Dr. Dobb’s Journal, 71.5% of
agile projects succeed as compared to project build with traditional methodologies
that have a success rate of around 68% [9]. It’s important to know the root cause
of the difference in the success rate of the projects so that you can prepare your
organization for agile methodologies. Some of the common areas that may impact
the adoption of the agile development process in large enterprises are.
4.16 Lack of Clarity
Large organizations are scaled organizations that mixed kind of man forces some
working in colocations, some working in distributed teams, and some working
remotely (work from home). However, it is important to have close collaboration
and communication among everyone, if remote or distributed workers/teams cannot
do this then it will be very difficult for them to contribute and hence reducing the
chances of project success. A common challenge that a large organization faces is

14. 68 4 Agility at Scale
forming complete cross-functional agile teams and making sure that these teams’
clear backlog in time. At scale in larger enterprises, it’s very difficult to figure out a
pattern that permits agile groups to collaborate and sit together and held responsible
and establish a steady velocity for progress. Cottmeyer wrote, “We look for places to
align business process and technology and teams into these units that can ultimately
become agile teams and become more loosely coupled from the rest of the organi-
zation.” A standardized process of information sharing can be brought agile teams
together, and such kind of resources help in agile development efforts. Tools used
for project management can provide clarity for the whole team concept especially
when teams are distributed, and the leadership team needs combined information
about the progress of the project in a consolidated form.
4.17 Continual Reliance on Legacy Methods
Cultural shift is required when you transition to agile methods, but sometimes teams
use waterfall and other traditional methodologies for certain operations that can lead
to failure. As per data, 9th annual survey by VersionOne, almost 37% of participants
felt pressure from leadership teams to follow traditional methodologies and 42%
have a view that their organizational culture is at odds with core agile values. The
worst part is, lack of leadership team support and reluctance of the team to work
with agile methodologies, increase the failure rate of their agile projects. Since agile
methodologies involve substantial changes like frequent releases, shorter time to
market and continuous development, having resources and support is very critical for
the success of these methodologies. However, the survey exposed that around 44%
of the participant mentioned that bringing change in organizational culture is the
biggest obstacle to increase the agile adoption, while 32% supposed that dominance
of traditional frameworks creates hindrance in agile adoption [10]. “We know that
agile is first about ‘how you think’ and then about ‘what you do’”. This is quoted by
the Agile Alliance in response to the survey. Agile influences organizational values
and enabling this change is the primary step to have a wider adoption of agile, and
success with agile means, successful value delivery.
4.18 Inadequate Experience with Agile
One of the reasons for the failure of agile projects in large enterprises is the fact that
people lacks in the practical experience of working with agile methodologies and its
integration in organizational culture. For better integration, enterprises should create
a game plan and provide experience through pilot programs and coaching.
Organizations often take small projects within a larger context or transform large
projects into agile initiatives. Although, deprived of essential knowledge, chances
of failure scaled up, this is an important aspect that is often underestimated while

15. 4.18 Inadequate Experience with Agile 69
doing agile transformations. Finding answers to some of the quires like, how do role
changes in new software development approach or what is meant by iterations can
provide essential inputs to the team for transforming into agile.
Training team members for different roles that can assist in building cross-
functional teams will leverage agile testing methodologies and ensure that projects
succeed with a new development approach. Leadership teams may also be trained as
roles and responsibilities will change radically while applying agile methodologies.
This will help the leadership team to understand the working of self-organizing
teams and help in creating a suitable environment for teams to excel. They have to
comprehend the new metrics and how to obtain them. Another problem is a lack
of collaboration among the members of different subcontracting enterprises. All the
teams working in different subcontracted organizations share the same objectives
and plans. There are many games that are playing in different subcontracted firms
and every game has different objectives. Team members need to respond to project
objectives as well as those put forth by their own organization. However, the latter
may not be aligned with the goals of other subcontractors working on the same
project. To make matters worse, in many occasions a company is subcontracted to
fulfill all positions in an area of expertise (e.g., subcontracting a company to do the
testing). Entire team is responsible for maintaining the quality of the code, but if a
disagreement arises it will be between expertise and companies. But, these kinds of
issues generally do not arise in agile development, but in agile settings, iterations
in which all members have to interact and actively collaborate can become a major
problem. For this, creating a team that shares the same objectives and where members
really collaborate is a major challenge, and we know that effective collaboration is
important to project success.
4.19 Looking for Testing Strategy
Whenever an organization transforms from traditional to agility, it misunderstood the
concept of testing in agility. There is a change in the role of a tester in agile software
development, so the skills required for testing in agility also change.
In agile development, testing must be performed iteratively over features that if
seen from traditional software development point of view are still not fully complete.
Furthermore, regression testing is to be performed continually to make sure that
already built features keep working. This infers that quality assures ace team must
do undergo major reshuffle and changes. Failure to understand this results in a major
cause of disappointment in many agile transformation endeavors. As mentioned
before, passable training for QA personnel and the selection of a good agile test
management tool is of utmost importance.

16. 70 4 Agility at Scale
4.20 Lack of Alignment in Areas of the Enterprise
It is commonly seen that large enterprise works with both software development
methodologies, some projects are handled in agile and other in traditional method-
ologies. The issues arise when these teams need to interact with each other. At the
problem sight when an agile team needs some inputs from the team that do not work
with agile methodologies and during the iteration if agile team demands something
from other team working with some other methodology and could not provide the
required inputs, as a result agile team cannot complete the work which is being
committed by it during the iteration.
It is a common mistake in large organizations to think that interaction between
agile and non-agile teams will be possible and will work smoothly. It is worth men-
tioning here that agility is about removing the dependencies across entire enterprise.
Aim in a large organization working with both kinds of methodologies is to get
team aligned and ensure that managers of teams that are not working with agile to
understand the implications of interacting with teams that do work in a new way.
4.21 Larger Teams and Pyramid Structures
Size of the teams should the same irrespective of the size of the organization. The
ideal number as suggested by many practitioners of agility is around seven team
members. But many times, teams working in large enterprises end up being larger
than a team that is required for the project. There can be many reasons for this:
restructuring of teams, pyramid structures lean toward the creation of bigger teams,
culture or organizations may have many employees. The problem may exaggerate if
those team members are partially allocated to the project as the commitment is not
the same, in addition problem of middle manager’s contribution to the project from
an even more external perspective. As a result, a price must pay for overstaffed teams
that include increases complexity, large meetings, and less productivity.
Additionally, situation may arise that teams of big organization may have more
than one boss. Though agile recommends the team to self-organize and each team
member can suggest and decide the best way a task can be completed by team col-
laborative effort but having a boss inside the team (e.g., technology lead or architect)
may create hindrance to the core values of agility. Innovative teams prefer flat struc-
tures, and this is not the case in big organizations. Large organizations, e.g., Amazon,
are working with autonomous teams having less than ten members. Amazon called
it “two-pizza team rule” as the model team should be small enough that its members
can be fed with two pizzas. Jim Highsmith in his book on Agile Project Management
raised one point that “If change, adaption and flexibility are the trademarks of agile
projects and conforming to plan is the trademark of traditional projects, then why
do we still measure success on agile projects using the traditional frameworks?”

17. 4.21 Larger Teams and Pyramid Structures 71
Fundamentally, if you have changed the development approach then change in per-
formance management objectives of the organization is also required. Otherwise, the
software development group will be working around one set of objectives, and the
management team will be working around another [11].
4.22 Conclusion
Significant changes in the business have been seen by the organization that scaled
up agile implementation. Scaling up mix of work with objective that business will
do more innovation rather than routine work. This help business to examine vary-
ing conditions and requirements, make adaptable courses of action, and sidestep
the constant crises that severely affect traditional structures. Disruptive innovation
will come to feel not so much disruptive but instead progressively like adaptable
just the same old thing new. This kind of scaling furthermore passes on composed
characteristics and benchmarks to business undertakings and supports limits, paying
little mind to whether various ordinary activities remain. It drives to efficiency that
is logically prominent and productivity in a part of the business’ tremendous cost
focuses. It improves operational building and hierarchical models to update coordi-
nation between agile teams and routine activities. Changes are consistently receptive
to client needs. Finally, there will be an improvement in desire-related outcomes
similarly as dynamically observable client faithfulness and authority satisfaction in
the business, which passes on quantifiable updates in results.
Big enterprises usually deal with problems having more complexity than small-
or medium-scale enterprises, reasons behind is they have more employees, subcon-
tracting, and different business units. At the same time, they have the pressure to
deliver system continuations and frequently in an ever-changing environment. They
have to be agile. Large enterprises that are transforming from traditional to agile
methodologies must learn for the organizations that have already been transformed
for traditional to agile and learn from their experience. Agile mindset may take time
to adjust, but by understanding challenges those firms have faced may help the begin-
ners to learn from it and mend their ways. This will help businesses plan better for
their transition to agile processes and improve the chances of successful projects.
References
1. Subramaniam, V., & Hunt, A. (2006). Practices of an agile developer: Working in the real
world. Pragmatic Bookshelf.
2. Embracing Agile. (2016). HBR. Available https://hbr.org/2016/05/embracing-agile. Accessed
12.11.2018.
3. HR Goes Agile. (2016). HBR, March–April 2018. Available https://hbr.org/2018/03/the-new-
rules-of-talent-management. Accessed 2.11.2018.

18. 72 4 Agility at Scale
4. Shore, J. (2007). The art of agile development: Pragmatic guide to agile software development.
Newton, MA: O’Reilly Media, Inc.
5. One Bank’s Agile Team Experiment. (2018). HBR. Available https://hbr.org/2018/03/the-new-
rules-of-talent-management#one-banks-agile-team-experiment. Accessed 02.11.2018.
6. Do you need an Architect in a Software Company? Available https://blog.rapid7.com/2015/
09/16/do-you-need-an-architect-in-a-software-company/. Accessed 29.11.2019.
7. Layton, M. C., & Ostermiller, S. J. (2017). Agile project management for dummies. New York,
NY: Wiley.
8. Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. London:
Pearson Education.
9. IT Project Success Rates Survey Results. (2007). Available http://www.ambysoft.com/surveys/
success2007.html. Accessed 10.11.2018.
10. VersionOne. (2018). Available https://www.versionone.com/about/press-releases/versionone-
releases-9th-annual-state-of-agile-survey-results/. Accessed 05.01.2019.
11. Highsmith, J. R. (2009). Agile project management: Creating innovative products. London:
Pearson Education.