module 6 scaling agile - designaspractice.com€¦ · module 6 scaling agile ... defined codebases...

© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved

Module 6 Scaling Agile

Table of Contents

Module 6 Scaling Agile ........................................................................................................... 1 Study Guide ...................................................................................................................................2

Reading.................................................................................................................................................. 2 Assignment ............................................................................................................................................ 2

Module Overview ..........................................................................................................................2 Outline ................................................................................................................................................... 2 Learning Outcomes ............................................................................................................................... 2

Continuous Integration, Delivery & Deployment .............................................................................3 Configuration Management .................................................................................................................. 3 Continuous Integration ......................................................................................................................... 3 Continuous Delivery .............................................................................................................................. 4 Continuous Deployment ....................................................................................................................... 4 DevOps .................................................................................................................................................. 5

Scaling Agile...................................................................................................................................6 Team Structures .................................................................................................................................... 6 Scaled Agile Frameworks ...................................................................................................................... 9 Scaled Agile Case Study ....................................................................................................................... 11

Summary ..................................................................................................................................... 14 Resources .................................................................................................................................... 15


Study Guide

Reading

Course module content

Assignment

Team Assignment: Sprint 2

Module Overview

In this module, we evaluate some of the more advanced practices in agile, including automated methods for integrating and deploying software solutions. Capabilities such as continuous integration (CI) and continuous delivery / deployment (CDD) create predictable development workflows that can be executed on demand. Creating a DevOps environment that utilizes CI/CDD practices removes the friction between developers and teams responsible for releasing software by integrating the two functions into a seamless process.

For larger projects or programs, organizations may need to scale their agile practices through distributed team structures or through one of the emerging scaled agile frameworks. SAFe, or Scaled Agile Framework, is the most prevalent methodology, but options such as LeSS, Scrum at Scale, and Disciplined Agile Delivery (DAD) are also gaining traction.

Outline

• Introduction to automated build and deployment capabilities, including continuous integration, continuous delivery, and deployment

• Evaluation of different team structures for large, distributed agile projects • An overview of popular scaled agile methodologies, such as SAFe, LeSS, Scrum at Scale, and DAD

Learning Outcomes

The expected learning outcomes for this section of the course are:

• Understand how teams increase their ability to rapidly deploy software using automated CI/CDD

capabilities

• Evaluate the ways that organizations can structure distributed agile teams and take advantage

of third-party partnerships

• Assess the different scaled agile frameworks and gain a high-level understanding of their

advantages / disadvantages


Continuous Integration, Delivery & Deployment

Configuration Management

At the base of continuous delivery strategies sits configuration management (often referred to as version

control), which determines how you manage all of the changes in your software. A solid configuration

management strategy includes the following elements:

• Reproducibility: Can the environment – including operating system, network configuration, software

and applications – be reproduced?

• Changeability: Can incremental changes to any part of the environment be deployed?

• Transparency: Can each change to the environment be tracked?

• Auditability: Can we manage and monitor regulatory compliance (if needed)?

• Accessibility: Can team members easily access information needed to make changes?

Part of the configuration management strategy is enabled with version control systems (VCS). The VCS may

also be referred to as source control or source code management. The VCS keeps all the versions of your

code changes and files and facilitate collaboration across teams. With the VCS, teams archive all of the

project development artifacts, including source code, test scripts, database scripts, documentation,

configuration files, etc. – anything that you would need to recreate or recover an environment. The benefit of

configuration management is that you have access to stable, defined codebases that can be checked in or

out, and changes to code can be easily deployed and rolled back.

Continuous Integration

Many software applications go for a long period of time in development where the software is not in a

working state. Changes may be checked in after automated unit testing, but until it is ready for

deployment, no one is interested in using the application in a production-like state. The result is that

many projects have lengthy integration cycles after development to get the application working for

acceptance-testing. The danger with leaving integration at the end of the project is that it becomes

difficult to predict how long it will take.

As part of the Extreme Programming (XP) methodology, Kent Beck (1999) began to socialize the concept

of continuous integration. Continuous integration is a readiness approach where all code is integrated

and technologically deployable in near real-time. Humble and Farley (2011), “Without continuous

integration, your software is broken until somebody proves it works, usually during a testing or

integration stage. With continuous integration, your software is proven to work with every new change

– and you know the moment it breaks and can fix it immediately.”

Continuous integration practices require a version control repository, automated build capabilities, and

organizational consensus. Developers typically check in code at least twice a day: The benefit is that

small changes are being checked in, which are less likely to break the build. Continuous integration also

requires an automated testing suite that encompasses automated unit, component and acceptance

tests. Without automation, the team won’t be able to quickly build and test the system at each code

check-in. Automated feedback loops help ensure that the process is fast, stable and repeatable. Once

the organization establishes this development to deploy-ready cadence, software can be released more

frequently.


Continuous integration ensures that the software is in a state of readiness to be released, but that the

actual release itself is coordinated through a series of approval stage-gates as part of the organization’s

release strategy and deployment planning processes. This practice is known as continuous delivery.

How does continuous integration and delivery work? Check out this video from GitHub:

https://www.youtube.com/watch?v=xSv_m3KhUO8

Continuous Delivery Continuous delivery is defined as:

• The ability to deploy software throughout its lifecycle

• A focus on ensuring deployable software over development of new features

• The ability to quickly get automated feedback on the state of production readiness

• The capability to perform on-demand push-button deployments of any software version to any

environment

The first companies to leverage continuous delivery practices were not surprisingly large technology

companies and software providers. But as the practices have matured, companies in other industries

have taken advantage of the capabilities to reduce cycle time in their release processes.

Listen to Martin Fowler discuss continuous delivery: https://www.youtube.com/watch?v=aoMfbgF2D_4

Continuous Deployment

The next set of practices is continuous deployment. The difference between continuous delivery and

deployment is that continuous deployment removes the manual approval stage-gates and automates

software deployment into the hands of customers. Basically, if all check-ins pass, code is immediately

deployed into production. However, unless you’re a big technology provider (Facebook, Amazon,

Google, etc.) you probably won’t be continuously deploying (or even need to consider it).

Many organizations using continuous deployment combine the practice with what’s called a “canary

release” – a small production release to a subset of users. Facebook, for example, rolls out new changes

into production internally, then releases to small groups of users, and then rolls out to the entire user

population. In their release cadence, they are pushing small, incremental changes out daily with larger

releases on a weekly basis.

Chuck Rossi, who leads release engineering at Facebook says of their developers,

“[The developers] shepherd their changes out to the world. We used to write code up and throw it

over the wall to project managers, quality assurance teams and then finally it would get to our

users. It’s not like that anymore: We throw it all over the wall to users. [Developers] have an

operational duty to take stuff out to the world – it’s on them to make sure it goes out correctly.

There is no quality assurance group at Facebook (there is a test engineering group). You have to

know when and how we push, and no matter what type of engineer you are, you use the same

concepts. We ship early and ship twice as often with two daily pushes and two deployments per

release plan. These include smaller bits of code with more frequent, incremental change – the

changes are quite small…it’s not 3000 lines of code.” (Rossi, 2012)

https://www.youtube.com/watch?v=aoMfbgF2D_4


DevOps

One of the often-overlooked aspects of teaching project delivery techniques is what happens after the

project is deployed. Beyond the development of the software (or whatever it is that you’re producing),

someone has to be responsible for the ongoing operational and maintenance aspects of the product.

The reason behind this is that most organizations separate out development from operations. However,

in a world where software is continuously ready for deployment, the integration of development and

operational teams becomes increasingly important. Unfortunately, in many organizations, these teams

have lived in their own silos and are often incented differently (i.e. get software out quickly vs. deploy

stable releases). But if we circle back to the goal of agility in software development, the entire

organization has a stake in de-risking deployments so that we can get high-quality, working software in

the hands of customers quickly.

If you happen to work in a smaller organization, chances are your development team also has

responsibility for operations. As the organization increases in size, the teams become more

compartmentalized. Each team may have a different goal: Operations teams need to ensure that all

changes within environments are documented and controlled (some of which may be governed by

regulations, such as Sarbanes-Oxley or HIPAA security compliance in the United States). Changes to the

environment are governed by detailed change control processes. Specific operational requirements

should be incorporated into the product’s release plan.

For companies moving towards continuous delivery/deployment, it’s essential to break down the silos

between development, operations and quality assurance teams. The simplest way to think about it is

that DevOps represents the organizational aspects (beyond the tools and techniques) of continuous

delivery/deployment, including the structure and skills of the team members involved in the process.

Early DevOps model adopters are in the big technology space, but organizations with heavy digital

presence are fast-followers.

DevOps: In Simple English: https://www.youtube.com/watch?v=_I94-tJlovg

https://www.youtube.com/watch?v=_I94-tJlovg


Scaling Agile

Team Structures So far, we’ve been discussing the practices of single Scrum teams working on single products. What happens

when the Scrum team is part of an organization that wants to grow its Scrum capabilities, or takes on large,

distributed projects that require the coordination of multiple teams? This section looks at structures and

techniques for coordinating across multiple and/or distributed teams.

There are three common organizations of agile teams:

• Multisite (or distributed) development: One product group at two or more sites

• Dispersed team: One team with team members across sites (also known as a distributed team);

different sites could mean that the team is in the same building, but on different floors

• Co-located team: Team is located in the same physical space

Even in a multisite environment, Scrum practices still apply, but the team has to work a lot harder to achieve

the same collaboration benefits that a co-located team will experience. If a team is multisite, the organization

should strive to keep the number of sites to a minimum. Even short distances between team members

contribute to communication problems: “Chair inertia is a strong force!” (Larman and Vodde, 2010).

If you’re working with an offshore partner, make sure that the on- and offshore teams have a consistent set

of agile values and principles. In fact, it might be the partner that’s encouraging an agile approach. Feedback

loops between the two teams are essential. One way to get this started is to hold a kickoff agile workshop.

Use this opportunity to educate both parties in agile values. Additionally, teams may be distributed by the

type of work that they do.

Scrum scales not by increasing the size of the development team, but coordinating the work across multiple

development teams. There are a variety of ways to structure teams within the organization, and there is no

single model. Here are some common structures:

Component Teams

Component teams focus on developing only a component or subsystem that comprises part of an end-

customer feature. The makeup of the team is specialized – that is, team members will have a specialty skill

that is leveraged across multiple projects. The organizational thought-process behind this structure is that

only experts should be making changes to a particular area of code.

Let’s say that your organization is developing a product where the features cut across three component

areas. A feature is selected from the top of the product backlog and divided into component-level pieces.

Those pieces are placed in the respective product backlog of each team, who uses the Scrum process against

their own backlog. Component-specific features are completed by each team, but not the full feature.

Components are integrated during Scrum of Scrum sessions (a meeting of multiple Scrum teams across a

single project) to integrate components across teams.

Complexity increases when the components are reused across multiple products. In this case, the team has

to manage competing requests and priorities from those products, and coordinating integration across

multiple component-level teams. The dependencies inherent in this structure can make it almost impossible

to manage and increases the likelihood of delaying the project. One option for solving this dilemma is to use

feature teams.

Feature Teams


Feature teams are cross-functional, cross-component teams that are responsible for completing end-to-end

customer features. The team has the necessary knowledge and skills to complete the work on their own.

Scrum is well suited to feature team work. However, the reason many organizations use component teams is

because of their particular skill and expertise – if that work was done by a different set of people, it may not

be done correctly. To mitigate that, feature teams could be comprised of the appropriately skilled resources.

Hybrid Feature-Component Teams

If specialty componentization is still required or the feature teams need to build up competencies to fully

take over the work, the organization can use a hybrid approach. The feature team pulls end-customer

features from the product backlog. The feature team owns responsibility for defining the logistics of

completing the work and ensures that it is done. The component teams are still within the organization to

maintain the integrity of specific components. They still have their own product backlogs of technical work

within each component area. What’s different in this model is that a member of the component team is

assigned to the feature team. Component team members provide feature teams with component-level

expertise to promote shared code-ownership at the feature team level.

This hybrid team structure may not work well in organizations with a large number of component teams. For

example, it wouldn’t make sense to have 30 people on a team. It can be mitigated through creating feature

teams clustered around high-interaction component areas.

Cross-Organizational Interactions

Many offshore development projects rely on intermediate resources, often a project manager, as the single

or primary contact between the onshore and offshore team. This increases the likelihood that information

between the teams will be misinterpreted, and creates a communication bottleneck. Teams should avoid

interaction models between teams that depend on a single point of contact. Instead, create a facilitator role

– someone who can help people come together. Rather than being an intermediary, the facilitator

encourages face-to-face interactions through video or web conferencing or in-person meetings where

possible. Ideally, the teams meet in person at several points during the development process. This helps the

team to build relationships and rapport.

Fowler (2006) calls the facilitator role the “ambassador.” In his example, two people (business and technical)

from the US-based team are present at their offshore site in India to facilitate communication. They also send

India resources to the US, noting that the “plane fares soon repay themselves in improved communication.”

Ambassadors are rotated every few months.

Another benefit of this approach is that it helps build competency and understanding around the business

domain. As much as possible, try and democratize this knowledge across the team to avoid subject-matter

expert bottlenecks. In addition, use Wikis to collect and disseminate knowledge.

Communication and Collaboration

Communication complexity and channels increase rapidly as the number of people on the project increases

and as those resources are spread across different locations. While telepresence and communication

technologies help bridge the distance between multisite teams, they are not a panacea. Time zone

differentials exacerbate the problem as teams lose the ability to synchronously communicate. Team

dispersion will have a higher negative impact when there are (1) significant cultural and language differences,

(2) the team has never met in person resulting in low trust, and (3) only communicate asynchronously (i.e.

through e-mail).


At a minimum, ensure the team has access to a wiki, instant messaging capabilities, and good telephone

connections. Fowler (2006) recommends recording video presentations. Team members create a short

lecture that is sent to the remote team that explains a key concept or message they’d like to communicate.

This can be helpful if the teams are in disparate time zones with little overlap.

Common Language

Multisite teams need to define a common language with a shared vocabulary. This can include the language

of the business or the project, or specific process training on Scrum/agile methods. Making team members go

through a common training class or program before joining the team will help ensure that team members

have the same baseline knowledge. Agile coaches can also facilitate this process. Common coding practices

and a consistent multisite “definition of done” are key as well. Use acceptance test-driven development

techniques to expose miscommunication and reduce ambiguity. Avoid creating an “us versus them”

mentality when communicating. Hold meetings at alternate times so as not to always inconvenience one

location. Be cognizant of local holidays.

Agile Tooling

Agile teams, including co-located, distributed and virtual teams, leverage a collection of tools, technologies

and practices known as “agile tooling.” Agile tools help the team share ideas, information, practices and

content. Remembering that agile values people and interactions over tools, agile tools serve to increase and

facilitate collaboration. Your distributed team doesn’t need expensive tools to communicate across

geographies. The most important thing is that the teams are visually connected.

Since teams don’t have a physical shared space, creating a virtual shared space is essential for team

collaboration. The virtual space is defined by the team using a variety of technologies or capabilities to create

a share environment. There is no shortage of agile software development applications that encompass a

variety of capabilities. This section will list some of the common functionality found in those applications.

However, it should be noted that the team can use these tools outside of an agile application toolset.

Many agile teams use a wiki to capture requirements and share information. As requirements are drafted,

distributed teams can immediately see and provide feedback. Discussion is consolidated and clarified in a

way that encourages participation. The wiki serves as the team’s knowledge base and can include project

documentation, troubleshooting information, coding practices, and “how-to’s.”


Scaled Agile Frameworks Because large scale projects are so complex, with many organizations and teams needed to complete

the work, a need arose to adapt and scale the Scrum framework to fit those types of projects. A number

of scaled agile frameworks emerged in support of the need, some more lightweight than others. The

current prevailing scaled agile methodology is called Scaled Agile Framework (SAFe) founded by Dean

Leffingwell. While SAFe is popular, it has a heavier process framework, and other scaled agile methods

defined by notable agile experts, such as LESS (Large Scale Scrum, Craig Larman and Bas Vodde), Scrum

at Scale (Jeff Sutherland) and DAD (Disciplined Agile Delivery, Scott Ambler) have worked to simplify

agile at scale.

SAFe SAFe is a Lean-Agile methodology created by Dean Leffingwell that provides a roadmap for coordinating

agile programs at the enterprise level. SAFe is defined at four levels and addresses many of the

operational gaps in traditional agile methodologies (portfolio management, architecture, budgeting):

• Team: Teams use Scrum or Team Kanban with XP engineering practices, delivering working, fully

tested software every two weeks.

• Program: At the program level, between 5-12 teams work together, synchronizing their iteration

and release cadences. Work is coordinated through an Agile Release Train (ART). The program

delivers a value stream for the organization.

• Value Stream: Coordinates work at the portfolio level and may include multiple ARTs. Value

stream programs may encompass projects of massive scope or complexity.

• Portfolio: At the portfolio level, business and architectural epics and visions are defined,

investment themes drive financial allocations, and intentional architecture supports enterprise

solution design concepts.

The SAFe methodology is built on the Lean process efficiency methodology and uses similar terminology.

A value stream is a long-lived series of steps used to deliver value from concept to delivery to the

customer, and includes:

• The people who do the work

• The systems they develop or use

• The flow of information and materials

The key metric of a value stream is lead time (the time from trigger to value delivery) – we focus on

optimizing lead time to shorten time to value. The value stream represents how value is understood,

organized and delivered within an organization, and could include operational value streams (business

processes), development value streams (technical solution development), or a customer experience.

At the program level, Agile teams are cross-functional, self-organizing; they define, build and test

features or components. They follow Agile Manifesto principles using SAFe, ScrumXP and XP Agile and

like regular Scrum practitioners, they leverage frequent, face-to-face planning sessions. Iteration (sprint)

and program increment (release) dates and quality are fixed, but scope is not. The teams work together

to determine the scope.

Across the teams, they use common iteration lengths and demonstrate working solutions at the ART

level through the system demo (sprint review). Infrastructure and enabler teams track ahead of the

feature development work. The ART includes 5-12 teams (50-125 people) that plan, commit, and

http://www.scaledagileframework.com/


execute together. The teams are aligned to a common missing via a single vision, roadmap, and product

backlog.

In SAFe, we have several new roles, the Release Train Engineer (chief ScrumMaster), who facilitates

program level processes and execution, and the Value Stream Engineer for large programs that span

multiple ARTs and suppliers. System and solution architects have technical responsibility for the overall

architectural and engineering design of the system and solution at the program and value stream level.

Scrum of Scrums

A Scrum of Scrums (SoS) is a periodic stand up meeting that includes representatives from each Scrum team.

The goal is to coordinate work across the teams. Delegates may include the team’s ScrumMaster and a

developer who can best speak to the inter-dependencies of the work. The Scrum of Scrums may also have its

own ScrumMaster. SoS meetings do not occur daily – the teams determine the appropriate frequency.

Similar to the teams’ daily stand up meetings, the SoS provides a roundtable for the following questions:

• What has my team done since we last met that could affect the other teams?

• What will my team do before we meet again that could affect other teams?

• What problems is my team having that it could use help from the other teams to resolve?

SoS meetings should use the same guidelines as a regular stand up meeting. They should be timeboxed, and

problem-solving should be deferred until after the meeting has adjourned. Follow ups to discuss outstanding

items should be self-organized by the team members that need to discuss the issues. Finally, there should be

continuity in the participants, who should commit to participating in at least two to three iterations.

Release Train

At the program level, release trains can be used as an approach to align vision, planning and team

interdependency. The release train provides cross-team synchronization to facilitate fast flow at the

program level. A published schedule of features is issued, and all development teams need to have their

work completed at the appointed time. In the event that a team misses the “train,” they can put their

“cargo” on the next departing train. As defined by Leffingwell (2007), the release train rules are:

• Solution release dates are fixed (scope is variable)

• Teams use the same iteration or sprint lengths

• Cross-team milestones are established

• Continuous system integration occurs at the top, or system, level in addition to feature and

component levels

• Release increments are scheduled at regular intervals

• System-level hardening iterations may be used to reduce technical debt

• Infrastructure level components track ahead

At the release train level, an enterprise product backlog exists with three additional levels of backlog:

portfolio, program and team. Each team performs its own sprint with work from their feature-area

backlog and coordinates across teams using a Scrum of Scrums.

Large Scale Scrum: LeSS The goal of LeSS is to provide a scaled agile framework that is a “scaled version of one-team Scrum.”

Similar to SAFe, the teams share a common vision and backlog, as well as the same sprint and release

https://less.works/


cadence. LeSS is designed to be simple, leveraging all of the capabilities within the standard one-team

Scrum methodology without adding complexity or process overhead.

Video: Intro to LeSS: https://youtu.be/cvz4364pC0g

Disciplined Agile Delivery: DAD DAD also seeks to simplify agile at scale. DAD has a strong focus on architecture and modeling. The

framework takes a best of breed approach in incorporating elements of Scrum, XP, agile modeling,

Unified Process, and Kanban. DAD includes three phases of work: Inception, construction, and

transition. A noted strength of DAD is the focus on architecture, design, and DevOps. DAD is designed to

flex for each organization that uses it, allowing for better right-sized practices.

Video: Intro to DAD: https://www.youtube.com/watch?v=qse17d_CtKU

Scrum at Scale: S@S Jeff Sutherland, one of the original founders of the Scrum methodology, created Scrum at Scale.

“Scrum was designed for a single team to be able to work at its optimal capacity while maintaining a sustainable pace. In the field, it was found that as the number of Scrum teams within an organization grew, the output (working product) and velocity of those teams began to fall (due to issues like cross-team dependencies and duplication of work). It became obvious that a framework for effectively coordinating those teams was needed in order to achieve linear scalability. Scrum@Scale is designed to accomplish this goal via its scale-free architecture.

By utilizing a scale-free architecture, the organization is not constrained to grow in a particular way determined by a set of arbitrary rules; rather it can grow organically based on its unique needs and at a sustainable pace of change that can be accepted by the groups of individuals that make up the organization. The simplicity of the Scrum@Scale model is essential to a scale-free architecture and carefully avoids introducing extra complexity that will cause productivity per team to decrease as more teams are created.

Scrum@Scale is designed to scale across the organization as a whole: all departments, products and services. It can be applied across multiple domains in all types of organizations in industry, government, or academia.” (Scrum@Scale, 2018)

Video: Scrum at Scale: https://youtu.be/k02ci923Po4

Scaled Agile Case Study SAS (www.sas.com) is one of the largest privately held software companies in the world and a long-time

leader in analytical software and business intelligence. SAS employs over 13,000 staff in 55 countries,

serving customers in 135 countries.

In 2007, the SAS Research and Development (R&D) organization launched a series of pilots to gauge if

Scrum could increase efficiency and time to value in the software development process. By 2013, the

organization had trained close to 2,000 global delivery resources in R&D in Scrum, providing ongoing

education, tooling and support. The implementation of Scrum allowed SAS to make systemic changes

within their core development processes, allowing the organization to increase the amount of time that

can be allocated to proactive research activities.

Taking into consideration the unique cultural values of the organization, SAS empowered the R&D teams

to adapt Scrum to meet each team’s distinct needs and preferences. Anecdotally, the organization

http://www.disciplinedagiledelivery.com/

https://www.scrumatscale.com/


believed that Scrum was helping them meet their desired goals, but R&D sponsors wanted to quantify

the relationships between delivered results and agile practices.

Background Historically, delivery teams responsible for platform development used a waterfall development

process, and the solution teams adopted a modified (or light) version of waterfall in their practices. By

the mid-2000s, the increased number of software solutions offered by SAS reached a tipping point.

Customers began to request product enhancements and more frequent releases at a faster pace. To

meet those needs, SAS realized they had to adapt their delivery processes.

Several teams began to experiment with methodologies such as Extreme Programming and the Rational

Unified Process, as well as creating their own methodologies based on the principles of the Agile

Manifesto. The organization centered on Scrum in 2007, based on work SAS initiated with several

external agile consultants. That work led to a series of Scrum pilots.

Even while centering on Scrum as the core methodology for software solution and platform delivery,

each team was encouraged to tailor their approach based not only on the team’s specific needs, but also

the product and market that they serve. As the pilots gained traction, the challenges of consistency at an

enterprise level became more apparent.

However, SAS still wanted to respect team autonomy. In order to better leverage and share best

practices across teams, social media hubs, knowledge portals and agile user groups were created.

Through the user group forum, the organizers identified several different agile practices (and different

results) across the delivery teams. The user group created an internal Agile Software Development Best

Practice document that outlines how agile is interpreted by SAS. To adhere to the agile concepts of

value and simplicity, the group kept the document to no more than nine pages.

The Survey In 2012, the user group launched an enterprise-wide survey to assess the effectiveness of Scrum within

the organization and determine Scrum’s contribution to successful delivery. One of SAS’s external agile

coaches observed that SAS was unique in their Scrum operating model, and encouraged R&D to explore

the successes and failures of the delivery teams. Also of note, SAS allows the development teams to

carve out a percentage of their time for innovation projects – the user group used their innovation time

to work on the agile survey. The goals of the survey were to:

• Determine the level of agile adoption and consistency

• Gauge the level of results from agile practices

• Measure the correlation between practices and results

• Create a baseline for measuring progress

• Provide input for future team retrospectives

Results The results of the survey noted the following benefits of their agile approach:

• The team has a higher sense of engagement in both planning and execution

• The team is more productive

• Team communication / collaboration has improved

• The team is producing higher quality products


• The team has higher morale

• The team is delivering functionality more quickly

• Agile gives us a greater flexibility and freedom for innovation

• Customers are more satisfied with the functionality of our products

• Team responds swiftly to change

• Barriers are resolved quickly

• Architectural design is better understood

• Team members are available

• Retrospective action items are followed through

• Team members help each other during an iteration

• Management sets goals but gives development teams freedom

• Iterations are appropriately sized

• Developers and testers work closely on story implementation and acceptance criteria

• Coaching is leveraged to help the team perform better

• Each team records tasks

• Pair programming

• Potentially shippable product complete at end of iteration

• Improved consistency of retrospectives

In their analysis of the relationship between practices and results, SAS found that teams who have

higher adherence to agile practices have better results. These higher performing teams stated that they

would be more likely to recommend agile, were more engaged and felt more productive. In addition, in

a correlation analysis between practices and results, agile coaching had the most significant impact of all

the practices. “The definition of done,” “acceptance criteria met” and “iterations are planned” closely

followed.

The Framework Evolution SAS notes that their scaled Scrum framework naturally evolved over time: “Since each component was

built upon the SAS work culture, it was not necessary to promote the SAS Agile Framework as a separate

initiative.” The practices rely on “grass-roots buy-in. SAS has enjoyed a viral-like adoption of agile at all

levels without any need of special directives.”

SAS identified five key areas within their agile framework:

• Engaged leadership support

• Agile training and education (agile boot-camps, self-study and coaching)

• Continuous learning and improvement from agile coaching

• Community, collaboration and socialization of agile best practices

• Consistency in adoption through the pursuit and sharing of best practices

At SAS, agile teams and practices are right-sized to the type of project that they are working on. SAS

plans to continue investing in their framework through leveraging the ongoing best practices of the

delivery teams. “Cultivating the agile mindset will continue to be an important factor in ongoing

success.” (Arthur, 2013)


Summary Continuous integration (CI) and continuous delivery / deployment (CDD) practices are modern

development techniques that software engineering teams use to improve software quality while

enabling their ability to release on demand. In CI, developers merge their code back to a main branch as

soon as they’ve written it, validating their work through automated testing that runs through a build of

the software. CDD extends CI so that software changes can be released as soon as code changes pass

the build. In continuous deployment, changes can be released automatically into production. Often,

teams using CDD will be structured as a DevOps team, where development and release management

operate as one team.

For larger, more complex agile programs with multiple partners and suppliers, organizations may use

distributed agile team structures that compartmentalize work by feature or component. In these more

complex programs, agile practices are scaled, often using frameworks such as SAFe, DAD, LeSS, and

S@S. Each method has its pros and cons, and selecting one of the frameworks requires careful

assessment of the project landscape and organization. Through continuous “inspect and adapt”

practices, the organization should self-evaluate and improve agile practices at scale.


Resources Arthur, T. (2013). Agile Adoption: Measuring its Worth. Retrieved online from:

http://support.sas.com/rnd/papers/2013/AgileAdoptionPaper.pdf

Fowler, M. (2006, July 18). Using an Agile Software Process with Offshore Development. Retrieved online from:

https://martinfowler.com/articles/agileOffshore.html

Larman, C. & Vodde, B. (2010). Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore

Product Development with Large-Scale Scrum. Upper Saddle River, NJ: Addison-Wesley

Rossi, C. (2012, April 5). Release Engineering and Push Karma. Retrived online from:

https://www.facebook.com/notes/facebook-engineering/release-engineering-and-push-karma-chuck-

rossi/10150660826788920/

Scrum@Scale Guide. Retrieved online at: https://www.scrumatscale.com/scrum-at-scale-guide-read-online/

http://support.sas.com/rnd/papers/2013/AgileAdoptionPaper.pdf

module 6 scaling agile - designaspractice.com€¦ · module 6 scaling agile ... defined codebases...

Documents