WHITEPAPER
AGILE METHODOLOGY
Implementing the Best Scaled
Agile Framework for Faster and
Better Business Results
Akhila Pant
Scaled Agile
Framework - how
it can be applied to
any organization to
get better business
results
Implementing the Best Scaled Agile
Framework for Faster and Better
Business Results
Challenges, Comparison of Frameworks,
Recommendations, Use Case Scenarios
Almost all IT organizations have adopted agile software development techniques in some
manner. The results have been positive for the most part. However, few organizations nd that
agile works well for them when the teams are small and face relatively straightforward
situations. They believe that their teams were struggling and spending signicant eort to
determine how to be agile in the situation that they face. It is not this hard. The good news is
that organizations are applying agile techniques at scale and are succeeding in doing so. They
nd astounding business results, a substantial increase in quality and productivity.
This paper is about the Scaled Agile
Framework and how it can be applied to any
organization to get better business results. It
attempts to provide answers to the following
questions:
What challenges do the teams face when
scaling agile?
What are the frameworks used to scale
agile, and how do they compare?
What have you to do to scale agile
delivery?
What is Disciplined Agile Delivery (DAD)
and why?
How does the process-goal-driven
strategy enable scaling?
How do disciplined agile teams work at
scale?
02
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
Agile teams achieve
better quality,
higher levels of
stakeholder
satisfaction, quick
time to delivery and
better ROI.
Challenges of Agile and Scaling
Majority of organizations have embraced or are in the process
of adopting agile software development techniques. For many
of them, this works out well. Agile teams achieve better quality,
higher levels of stakeholder satisfaction, quick time to delivery
and better ROI. Organizations experience challenges withapplying
agile strategies at scale. This happens because agile methods
are:
Software-focused: Agile promotes the
philosophy of working software becoming
the primary measure of success. Software
alone should not be the only measure.
Development teams are also dealing with
hardware related issues, documentation,
evolving business processes around the
usage of the system, etc. Shouldn't we
consider all of those questions and not just
software?
Construction-focused at the expense of
delivery: Scrum, one of the agile methods,
focuses on the construction part of the
software lifecycle, yet agile teams in
practice still need to perform initiation and
release activities. They are likely to forgo
the benets provided by a bit of up-front,
strategic thinking.
Oriented towards small teams in
straightforward situations: Most of the
agile methods are oriented towards small
group size, who are either co-located or
near-located, who have access to the
primary stakeholders and who are working
on software. What about large teams?
What about geographically distributed
teams? What about teams working in
complex situations? Can't we implement
agile there too?
Prescriptive at the expense of exibility:
Agile methods such as Scrum are rigidly
prescriptive. For example, in Scrum, one
way to address changing requirements is
the product backlog, one way to
coordinate activities within a team is
through daily Scrum meeting, and so on.
And the Scrum community is very clear
that this is the way it has to be done. Teams
work dierently in dierent situations, and
they need several options to choose from
to achieve these goals. Indeed, advocates
of lean techniques have argued that
iteration-based approaches like Scrum are
not always the best choice.
Too narrowly dened: Agile tend to focus
on a portion of the overall delivery process.
We need to gure out how to t them
together into a cohesive whole that is right
for you.
03
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
Agile methods
provide the starting
point but need
substantial
eort to make
them scalable.
The team is focused at the expense of the overall enterprise:
Scrum stresses the value of sheltering the team from external
distractions. This is often used as an excuse for not
collaborating with other delivery teams, which results in
discrepancies and miscommunications. It leads the team to
increase technical debt, miss opportunities for reuse, and even
implement functionality that exists in other products.
Agile methods provide the starting point but need substantial eort to make them scalable.
04
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
Agile has various
approaches and
frameworks in place
to make the
transition painless
Comparison Matrix Of Scaled Agile
Frameworks
Worshippers of Agile argue that scaling this framework is pretty
straightforward. Just let your teams and units decide whats best
for them, and trust them to improve their work. Agile has various
approaches and frameworks in place to make the transition
painless.
Table 1. Agile approaches and frameworks
Criteria
Large Scale
Scrum (LeSS)
Scaled Agile
Framework (SAFe)
Disciplined Agile Delivery
(DAD) + Agility at Scale
Description
LeSS helps to
implement Scrum in
the organization. It is a
minimal framework
that oers a high
degree of exibility for
implementation. It is
non-prescriptive, and
merely gives
suggestions.
SAFeis a highly
structured and
prescriptive
method that
helps large
enterprises to set
out on the road
to Agile. The
Scaled Agile
Framework is
mainly implemented at three
levels: Team,
Program, and
Portfolio.
Disciplined Agile Delivery
(DAD) process decision
framework is a people-rst, learning-oriented
hybrid agile approach to IT
solution delivery. DADs
strength is in architecture,
design, and DevOps. On
another hand, its
documentation lacks
coherence.
Portfolio
Medium
Medium
Medium
Program
Structure
Medium
High
High
Inter Team
Coordination
High
High
High
Team Level
Medium
High
High
Tech Practices
Medium
Medium
High
Here DAD proves to be an appealing option.
05
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
DADs Life Cycle
DAD inspires teams
to be more exible
in your approach.
It has been found
that four of the
twenty-two process
goals seem to take
about 80% of the
tailoring impact
Concept: This is the phase where we envision the idea.
Inception: This phase comprises the following activities.
Form initial team
Develop shared vision
Align with enterprise direction
Explore initial scope
Identify initial technical strategy
Develop initial release plan
Secure funding
Form work environment
Identify risks
Construction: This phase denes how
we produce a solution.
Provide a potentially convenient solution
Address changing stakeholder needs
Move closer to deployable release
Improve quality
Prove architecture early
Transition: This phase denes how we deploy.
Ensure solution is consumable
Deploy the solution
Production: This phase is a pure support
phase.
PRODUCTION
CONCEPT
TRANSITION
INCEPTION
CONSTRUCTION
06
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
DAD's Goals:
Explore initial
scope
Identify initial
technical strategy
Move closer to a
deployable release
Coordinate
activities
Scaling Factors Faced by
Agile Team
What are the scaling factors that should be considered when
tailoring our approach? The table below summarizes the six
scaling factors of the Software Development Context
Framework and indicates the range of each of its factors. Any
given team will nd itself somewhere close to the simple
extreme.
Table 2. Scaling Factors of the Software Development Context Framework
Factors
Team Size
Geographic Distribution
Organizational Distribution
Compliance
Domain Complexity
Technical Complexity
Simple Extreme
2
Co - located
Single Division
None
Straightforward
Straightforward
Challenging Extreme
1000
Global
Outsourcing
Life Critical
Very Complex
Very Complex
DADs Goal Driven Approach to Scaling
DAD inspires teams to be more exible in your approach. It has been found that four of the
twenty-two process goals seem to take about 80% of the tailoring impact.
These goals are:
Explore initial scope
Identify initial technical strategy
Move closer to a deployable release
Coordinate activities
We have mentioned considerations for each objective below.
07
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
The greater the
domain complexity,
the team will need
to invest more in
modeling its initial
requirements.
Explore Initial Scope
When a project release begins, one of the process goals which
team needs to address is to explore initial scope.
The team needs to have at least a high-level understanding of
what theyre trying to achieve.
Teams should be able to answer few of the fundamental questions like what you are
attempting to make, the duration and the overall cost of it.
DAD recommends starting with usage modeling, domain modeling and non-functional
requirements.
The team needs to think even about addressing its non-functional requirements like availability,
security and performance.
The greater the domain complexity, the team will need to invest more in modeling its initial
requirements.
Geographical distribution of the team may require you to spend more eort in capturing and
communicating the needs or requirements.
Identify Initial Technical Strategy
Another signicant phase which comprises
of initial architecture envisioning or simply
initial architecture modeling.
of working in an enterprise sensible
manner.
The team will have to evolve a strategy to
build a solution from scratch.
First, the team should think up-front about
their architecture so as to identify a viable
strategy to fulll that.
The greater the technical complexity, the
more the teams need to invest in its initial
architecture modeling.
Second, the team will have to think about
leveraging their existing frameworks, web
services, etc. to reduce the overall time and
cost. This is an aspect of DADs philosophy
Work for the geographically distributed
team by enabling them to work in greater
isolation
and
thereby
reducing
collaboration overhead.
08
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
The majority of
projects face testing
and quality
assurance early in
the life cycle so that
they can reduce the
cost of xing
defects.
Move Closer to a Deployable Release
Moving closer to a deployable release is another important
process goal.
First, it deals mainly with the packaging aspects.
Second, it also deals with deployment planning
Third, this goal covers critical verication and validation
procedures. The majority of projects face testing and quality assurance early in the lifecycle
so that they can reduce the cost of xing defects.
This process goal is primarily aected by the scaling factors of domain complexity, technical
complexity, and compliance.
Coordinate Activities
Coordination plays another major phase
here.
First, one of the major issues found in the
projects is the artifact ownership and
coordination of the team.
Second, as DADs teams are enterprise-aware,
it describes the strategies to coordinate with
an external group.
Third, the team needs to address issues
related to scaling.
Also, the team will have to devise strategies
to communicate within the team based on
its size.
A technically sophisticated project team
would prefer to adopt the architecture
owner and the ones having domain
complexity would have product owner as a
part of the team.
A team where there is vendor involvement
may choose to adopt a disparate ownership
strategy for some project artifacts.
Use Case Scenarios
Scenario A: Large Development Team
This scenario describes a large software development initiative to build a large number of
features in parallel to meet an aggressive timeline.
A technically sophisticated project team would prefer to adopt the architecture
owner and the ones having domain complexity would have product owner
as a part of the team.
09
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
Table 3. A large software development initiative
Scaling Factor
Situation Faced
Team Size
120 total team members available for this
initiative
Geographic Distribution
Distributed team across four oces
within two time zones
Compliance
Internal compliance
Organizational Distribution
Stakeholders are willing to relocate near
the team
Domain Complexity
Complex
Technical Complexity
Medium complexity
Table 4. Process decision for each of the key goals
(large software development initiative)
DAD Goal
Explore Initial Scope
Strategy
Chief product owner to facilitate the creation of vision.
Product ownership team will meet with other stakeholders to obtain a common understanding of the initial
scope.
A program backlog of features and work item lists are
created for each team.
Architecture and product owners will meet to agree
upon system-wide non-functional requirements for all
delivered features.
Align with Enterprise
Direction
Architecture owners outline standard guidelines and
come with the mandatory guidelines.
A User Experience (UX) expert will collaborate with all the
teams to ensure consistency and optimize the user experience.
Enterprise Architecture (EA) and Product Management
teams to have regular meetings to ensure coherence and
manage dependencies across teams.
10
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
DAD Goal
Identify Initial
Technical Strategy
Strategy
Architecture owners design the architecture at a high
level.
Technology diagrams will be created using a few UML
diagram, and UI prototypes will be hand-drawn.
All models will be built and evolved in informal modeling
sessions. An existing reference architecture will be used,
if applicable.
Attempt will be made to reuse services from existing
systems.
Move Closer to
Deployable Release
Team to follow two weeks Sprint. The work would be integrated and published externally to stakeholders via a
transition phase.
The product owner to come up with user documentation.
The architecture owner to update the architectural
handbook.
Those teams that are not yet ready to adopt test-driven
development would follow test-after programming
approach.
Build-processes and regression-test-execution to be
automated.
Informal code reviews are done as needed.
Coordinate Activities
Information sharing to be primarily via direct conversations.
Team to have time blocked for the coordination meetings.
All artifacts will be visible across teams.
All teams to deliver work in two-week iterations, with a
common start and end dates.
Architecture owners and product owners to have regular
scheduled meetings to share information about work
details, priorities, dependencies, and issues.
After every four iterations one week of transition would
be planned to deploy the combined work of all the
teams.
Teams gather at a common location for two days of
release planning at the beginning of each release.
11
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
The requirements of the
application should be
captured via a collection
of epics and user stories
in JIRA. Stories have to
be prioritized by the PO
with advice from the
Architecture Owner
about technical risk
considerations.
Scenario B: Geographically and Organizationally Distributed Team
Consider an organization with geographically and organizationally
distributed team with considerable time-zone dierence.
Table 5. Geographically and
organizationally distributed team
Scaling Factor
Situation Faced
Team Size
12 total team members available for
this initiative
Geographic Distribution
Team members are distributed having
considerable time-zone dierence
Compliance
Internal compliance only
Organizational Distribution
Business stakeholders are not willing
to relocate to the team work areas
Domain Complexity
Complex
Technical Complexity
Complex
Table 6. Process decision for each of the key goals
(geographically and organizationally distributed team)
DAD Goal
Explore initial scope
Strategy
Chief product owner to facilitate the creation of vision.
Proxy PO, the team lead, and two developers y to
clients location for a two-week workshop. This workshop
would be performed in a large dedicated modeling
room.
The requirements of the application captured via a
collection of epics and user stories in JIRA.
Stories to be prioritized by the PO with advice from the
Architecture Owner about technical risk considerations.
12
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
DAD Goal
Align with Enterprise
Direction
Strategy
Architecture Owners outline standard guidelines and
agree on mandatory guidelines.
For the collaboration, the Enterprise Architecture (EA)
and Product Management teams decide to formalize
regular coordination meetings.
Identify Initial
Technical Strategy
Architectural owners and developers to work closely.
Most of the modeling are performed via whiteboards
and Visio.
Move Closer to
Deployable Release
The team can take a developer-level test-driven
development (TDD) approach to programming.
The continuous integration (CI) strategy includes code
analysis tools that provide metrics.
Deployment planning is discussed and agreed by the
team leads. The application is deployed at the end of
iteration into a testing environment where it can get
tested.
Create deliverable documentation and deliver it to testers so that testers can start their testing.
Coordinate Activities
Each team to hold its daily coordination meetings .
Project dashboard can display quality and progress metrics.
The team can have sixty-minute teleconference every
day with the proxy PO rst thing in the morning to
answer any requirement related questions.
Every four months the PO and Team Leads meet for a
week to do long range release planning and general
coordination between the locations.
13
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
Requirements are
captured with
informal modeling
sessions in their
team room and
interviews.
Scenario C: Medium-Sized Team, Domain
Complexity, and Regulatory
This is a software development team of eighteen people working
out of a single location. Each person has their cubicle, and there
is also a permanently reserved team room where theyve
installed whiteboards and a corkboard.
Table 7. Medium-sized team
Scaling Factor
Situation Faced
Team Size
18 total team members available
for this initiative
Geographic Distribution
Team working from single location
Compliance
Internal compliance only
Domain Complexity
Medium complex
Technical Complexity
Medium complex
Table 8. Process decision for each of the key goals (medium-sized team)
DAD Goal
Explore Initial Scope
Strategy
They team to create use-cases and screen mockups for
the primary screens and whiteboard sketches of the
overall business process.
Requirements are captured with informal modeling
sessions in their team room and interviews.
The requirements are captured in JIRA.
The team chose a lean work item pool strategy to
manage work items using a JIRA virtual Kanban board.
14
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
DAD Goal
Align with Enterprise
Direction
Strategy
Architecture owners outline standard guidelines and
agree on mandatory guidelines.
For the collaboration, the Enterprise Architecture (EA)
and Product Management teams decide to formalize
regular coordination meetings.
Identify Initial
Technical Strategy
The team takes an informal approach to modeling, as
they did with their scoping eorts.
Initial requirements and architecture modeling takes
about one month for the rst.
Team to come up with the analysis if we have scope to
reuse the existing system or build from scratch.
The architectural decisions are captured using a Wiki
with the reasoning.
Move Closer to
Deployable Release
The software development team to adopt a deployment
cadence that reects the deployment schedules of the
devices.
Team to embrace a strict conguration management
(CM) strategy.
Informal code reviews done as needed.
The technical writer works with developers to help them
write the supporting documentation for the software.
Coordinate Activities
The team meets for ten minutes on a daily basis around
their JIRA Kanban board.
Everyone is expected to update JIRA before the coordination meeting.
Architecture owner to meet with the architects and the
teams on a weekly basis to coordinate technical issues.
Team leads meet once weekly to discuss any issues.
The PO meets with her counterparts on a daily basis to
coordinate requirements-related issues.
15
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
Scaling across
your organization
requires you to help
individuals, teams,
and departments to
adopt an active
mindset and agile
ways of working
together.
Parting Thoughts
This paper started by describing lines of thought when it comes
to agility at scale: rst, how to scale agile delivery, challenges,
comparison of various frameworks and recommendation - the
focus of this paper, and the use case scenarios. Scaling across
your organization requires you to help individuals, teams, and
departments to adopt an active mindset and agile ways of
working together. The suggestion is rst to scale agile delivery
before you can think about scaling Agile across the organization.
Only then can your organization operate as an agile enterprise.
References
Ambler, S.W. and Lines, M. (2012). Full Agile Delivery Lifecycles. http://disciplinedagiledelivery.com/
lifecycle
Ambler, S.W. and Lines, M. (2013). Coordinating Activities on Agile Delivery Teams. http://
disciplinedagiledelivery.com/2013/07/12/coordinating-actitivies/
Ambler, S.W. (2013). The Software Development Context Framework. http://disciplinedagiledelivery.
com/2013/03/15/sdcf/
Ambler, S.W. & Lines, M. (2013). Going Beyond Scrum: Disciplined Agile Delivery. http://
disciplinedagileconsortium.org/Resources/ Documents/BeyondScrum.pdf
Ambler, S.W. & Lines, M. (2014). Scaling Agile Software development.
http://disciplinedagileconsortium.org/Resources/Documents/ScalingAgileSoftwareDevelopment.pdf
Scaled Agile Framework (SAFe) home page. http:// scaledagileframework.com/
16
tavant.com/media
2016 Tavant Technologies. All Rights Reserved.
About the Author
Akhila Pant is working as a Project Manager at Tavant Technologies. She has been
working on Agile project management for over six years. This white paper has evolved
based on her extensive experience executing scaled Agile projects across various
companies.
About Tavant Technologies
Headquartered in Santa Clara, California, Tavant Technologies is a specialized
software solutions & services provider that delivers impactful results to its customers
across North America, Europe, and Asia-Pacic. Founded in 2000, the company
employs over 1500 people and is a recognized top employer.
3965 Freedom Circle, Suite 750, Santa Clara CA 95054, United States
Tel: +1-866-9-TAVANT | Fax: +1-408-519-5401 | bizdev@tavant.com
Santa Clara | New York | Indianapolis | Toronto | London | Bengaluru | Noida
2016 Tavant Technologies. All Rights Reserved.
