Survey and Analysis of Scaled Agile Frameworks for an Agile … · ... Product Owner, Scrum Master, Development team, Area Product Owner Events Iteration ... Inspect and Adapt, Iteration

Chair of Software Engineering for Business Information Systems (sebis)

Faculty of Informatics

Technische Universität München

wwwmatthes.in.tum.de

Survey and Analysis of Scaling Agile Practices

for an Agile IT Organization Binnur Karabacak, Bachelor Thesis Final Presentation, 31.07.2017, Munich

Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table

Scaled agile framework vs. Large scale scrum

Limitation and outlook

Agenda

© sebis Binnur Karabacak - BT Final Presentation 2

Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table



Agenda


Motivation

Compared to traditional software, organizations have to deliver software much

faster and better tolerate changing requirements

agile software development as an alternative to traditional methods

94% are practicing agile software development

98% realized success from agile projects

Benefits of agile software development:

• ability to manage changing priorities

• better project visibility

• improved team productivity

Organizations face their next challenge in scaling agile

practices across the IT organization


Several scaling agile practices emerged to meet this challenge

Source: based on VersionOne 2017

Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table



Agenda


Overview of relevant research questions


Research question 1 (RQ1):

Which scaling agile practices exist?


How can scaling agile practices be compared?


What are the commonalities and differences between the

Scaled Agile Framework and Large Scale Scrum?

Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table



Agenda


Research Approach


RQ1

RQ2

RQ3

Scaled Agile

Frame-work

Agile Organi-zation

Scaled Agile

Scaled Agile

Organi-zation

Agile Frame-

work

Agile Software Enginee-

ring

1. SCOPE OF RESEARCH

Research questions on scaling agile practices

2. TOPIC CONZEPTUALIZATION

Concept map with relevant search terms

3. LITERATURE SEARCH

List of relevant sources

4. LITERATURE ANALYSIS

Analysis of comparisons of scaling agile practices

Source: based on Brocke 2009

5. RESEARCH OUTCOME

Differences and commonalities of SAFe and LeSS

Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table



Agenda


Related Work

Alqudah et al. (2106): Comparison of scaling agile practices

SAFe, LeSS, DA 2.0, RAGE, Nexus, and Spotify were considered to be

scaling agile methods at large organizations

roles and practices of each is described

practices are compared based on some criteria

results are summarized, and the advantages of each practice are shown

Uludağ et al. (2017): Roles of architects in scaling agile practices

Identified 20 scaling agile practices and described the three most popular

scaling agile practices, namely the Scaled Agile Framework (SAFe), Large

Scale Scrum (LeSS), and Disciplined Agile 2.0 (DA 2.0)

the roles of enterprise, software, solution, business, information, and

integration architects, as identified in six different scaling agile practices, are

characterized


Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table



Agenda


Comparison criteria of different sources


Dolman et al. (2014) compares SoS, LeSS, SAFe, DAD, Spotify, DSDM, RAGE, Nexus and Scrum at Scale based on:

• Description

• Web Link

• Popularity/Adoption

• Portfolio

• Program structure

• Inter-team coordination

• Team level

• Tech practices

• Completeness of coverage

• Availability of Details & Support

• What Team level frameworks are supported

• Emphasizes more Central control or distributed, Scale / Target size,

• Used typically by what Organization Types

• Focal point

• Software centric

• how often used outside of SW or IT

• Big Positives / Key Differentiatiators

• Key Risks / Concerns

• Training

Kapadia (2014) compares SAFe, LeSS and DAD based on:

• Style

• Building block

• Distinctive events

• Books

• Websites

• Distinctive roles

• Certifications

• Foundation

Pant (2016) compares SAFe, LeSS and DAD based on:

• Description

• Portfolio

• Program structure

• Inter-team coordination

• Team level

• Tech practices

Alqudah (2016) compares SAFe, LeSS ,DAD, Spotify, Nexus and RAGE based on:

• Team size

• Trainings and certificates

• Technical Practices required

• Roles

• Organization type

• Methods and practices adopted

West (2016) compares AgilePath, Continuous Agile, DSDM, SAFe, LeSS ,DAD, Spotify, Nexus, Fast Agile, ScALeD, Scrum at Scale, XSCALE and RAGE based on:

• Enterprise-Targeted

• Web-Scale-Targeted

• Source of Practices

• Published Case Studies

Comparison Template


Characteristic Scaled Agile Framework Large Scale Scrum

Descriptive Information

Abbreviation

Short description

Methodologist

Organization

Publication date

Category

Website

Adoption

Number of

academic

contribution

Number of stated

cases

Documentation

Availability of

training courses and

certifications

Availability of a

community/blog/

forum

Scope

Scope level

Foundational

practices

and methods

Approach for

Software

Development

Iteration time period

Team size

Roles

Events

Artifacts

Concepts

Introduction

Motivation

Research questions

Research approach

Large scale agile

Related work

Comparison table



Agenda


Scaled Agile Framework (SAFe)

© sebis Binnur Karabacak - BT Final Presentation 15 Source: based on SAFe 2016

Large Scale Scrum (LeSS)


Source: based on LeSS

Comparison of SAFe and LeSS



Descriptive

Information

Abbreviation SAFe LeSS

Short description

SAFe is a knowledge base of

proven patterns for implementing

lean and agile software

development and system

development at enterprise scale

LeSS is one-team Scrum applied

to many teams who are working

together on one product

Methodologist Dean Leffingwell Craig Larman,

Bass Vodde

Organization Scaled Agile Inc. LeSS Company B.V.

Publication date 2011 2008

Category Framework Framework

Website www.scaledagileframework.com www.less.works

Adoption

Scope

Source: based on SAFe 2016, LeSS




Abbreviation

Short description

Creator

Organization

Publication date

Category

Category Website

Presence in

academic

contributions

Number of

academic

contribution

Presence in

stated cases

Number of stated

cases

Documentation

Training courses

and

Certifications

Community/Blog/

Forum

Scope level

Foundational

practices

and methods

Roles

Events

Team size

Approach for

Software

Development


Artifacts

Concepts


Adoption

Scope



Adoption

Number of

academic

contribution

35 29

Number of stated

cases 38 23

Documentation Homepage, Books, Whitepaper Homepage, Books

Availability of

training courses and

certifications

yes yes

Availability of a

community/blog/

forum

yes yes

Scope

Source: based on Uludağ, SAFe 2016, LeSS




Abbreviation

Short description

Creator

Organization

Publication date

Category

Category Website

Presence in

academic

contributions

Number of

academic

contribution

Presence in

stated cases

Number of stated

cases

Documentation

Training courses

and

Certifications

Community/Blog/

Forum

Scope level

Foundational

practices

and methods

Roles

Events

Team size

Approach for

Software

Development


Artifacts

Concepts


Adoption

Scope


Descriptive

Information

Adoption

Scope

Scope level All levels All levels

Foundational practices

and methods

practices: lean product

development and flow, system

thinking, agile development

methods: Scrum, XP, Kanban

practices: lean thinking, system

thinking, agile development

methods: Scrum

Approach for Software

Development iterative iterative

Iteration time period recommended as 2 weeks, but

can last from one to four weeks 2-4 weeks

team size

Release Train: 5-12 agile teams

Agile Team: 5-9 agile team

members

Small LeSS: 2-8 team, with up to

8 team members

LeSS Huge: more than 8 teams

with up to a few thousand people





Abbreviation

Short description

Creator

Organization

Publication date

Category

Category Website

Presence in

academic

contributions

Number of

academic

contribution

Presence in

stated cases

Number of stated

cases

Documentation

Training courses

and

Certifications

Community/Blog/

Forum

Scope level

Foundational

practices

and methods

Roles

Events

Team size

Approach for

Software

Development


Artifacts

Concepts


Adoption

Scope

Scope

Roles

Team level: Product Owner,

Scrum Master, Agile Team

members

Program level: Product

Manager, Release Train

Engineer, System architect,

Business Owner, Stakeholder

Value Stream level: Value

Stream Engineer, Solution

manager, Solution architect

Portfolio level: Epic Owner,

Enterprise Architect

Small LeSS: Product Owner,

Scrum Master, Development

team

LeSS Huge: Product Owner,

Scrum Master, Development

team, Area Product Owner

Events

Iteration Planning, Program

Increment (PI) Planning, daily

Stand-Up, Iteration

Retrospective, System Demo,

Inspect and Adapt, Iteration

Review, Pre- and Post-PI

Planning, Solution Demo

Sprint, Sprint Planning (One and

Two), Daily Scrum, Sprint

Review, Sprint Retrospective,

overall retrospective meeting

Artifacts

Team Backlog, Portfolio Backlog,

Program and Value Stream

Backlog

Small LeSS: product increment,

Product Backlog, Sprint Backlog,

LeSS Huge: Area Product

Backlog

Concepts

Program Increment, Agile

Release Train, Value Streams,

Architecture Runway, Spanning

Palette

Requirement Area


Main findings

Both frameworks try to address practices beyond the team level

SAFe offers a more governance oriented and prescriptive framework with clear

roles and responsibilities than LeSS

Small LeSS and the 3-level-view of SAFe are both designed for small agile

teams, whereas LeSS Huge and the 4-level-view in SAFe support building large

solutions that typically require hundreds or more people to build and maintain

SAFe assumes an intentional and emergent architecture and covers the roles of

architects;

LeSS assumes an emergent architecture, but does not cover the roles of

architects


Main findings

SAFe and LeSS have partially the same artifacts, events, and roles, but may

have different names


Source: based on Kaczmarek 2016

SAFe LeSS

artifacts

working software increment product increment

team backlog program backlog value stream backlog portfolio backlog

product backlog

events

iteration sprint

iteration planning sprint planning

team demo sprint review

roles agile team member feature team

agile team scrum team

Limitations and Outlook

Only two scaling agile practices were compared

Comparison of other scaling agile practices in future

Recently, SAFe 4.5 was released, but SAFe 4.0 is described and compared with

LeSS

Interviews with organizations about how they use scaling agile practices


Discussion

24

Thank you for your attention!

Do you have any questions?

Binnur Karabacak - BT Final Presentation © sebis

Sources

[1] VersionOne Inc. (2017). the 11th annual State of Agile Report. accessed: 2017-07-27.

[2] J. Vom Brocke, A. Simons, B. Niehaves, K. Riemer, R. Plattfaut, and A. Cleven. (2009), “Reconstructing the giant: On the importance of rigour in documenting the literature search process,” in ECIS, vol. 9, pp.

2206–2217.

[3] Alqudah, M.; Razali, R. (2016). A Review of Scaling Agile Methods in Large Software Development. International Journal on Advanced Science Engineering Information Technology, 6 (6), 828-837.

[4] Dolman, R.; Spearman, S. (2014). Links. Retrieved from Agile Scaling: http://www.agilescaling.org/links.html. accessed: 2017-07-27.

[5] A. Pant, “Agile methodology: Implementing the best scaled agile framework for faster and better business results,” Tavant Technologies, Tech. Rep., 2016.

[6] S. V. D. Z. Mike West, Nathan Wilson, “Market guide for enterprise agile frameworks,” Gartner, Tech. Rep., 06 2016.

[7] Kapadia, M.: Introduction to Enterprise Agile Frameworks, Salt Lake City, Utah 2014.

[8] Uludağ, Ö.; Kleehaus, M.; Xu, X.; Matthes, F.: Investigating the Role of Architects in Scaled Agile Frameworks, 21th Conference on Enterprise Distributed Object Computing (EDOC), Québec City, Canada 2017.

[9] “Safe® 4.0 for lean software and systems engineering”, http://scaledagileframework.com/, accessed: 2017-07-27.

[10] LeSS Framework, https://less.works/ , accessed: 2017-07-27.

[11] Kaczmarek, C. (2016). Organisation in einer Digitalen Zeit: Ein Buch für die Gestaltung von reaktionsfähigen und schlanken Organisationen mit Hilfe von skalierten Agile & Lean Mustern. Darmstadt: Wibas GmbH


http://www.agilescaling.org/links.html

http://scaledagileframework.com/

https://less.works/

Backup: The evolution of scaled agile frameworks


Framework Type Publication year

Crystal Family Set of methods 1992

Dynamic Systems Development Method

Agile Project Framework for Scrum Framework 1994

Scrum-of-Scrums Mechanism 2001

Enterprise Scrum Framework 2002

Agile Software Solution Framework Framework 2007

Large Scale Scrum Framework 2008

Scaled Agile Framework Framework 2011

Disciplined Agile 2.0 Framework 2012

Spotify Model Model 2012

Mega Framework Framework 2012

Enterprise Agile Delivery and

Agile Governance Practice Set of practices 2012

Recipes for Agile Governance in the Enterprise Framework 2013

Continuous Agile Framework Framework 2014

Scrum at Scale Framework 2014

Enterprise Transition Framework Framework 2014

ScALeD Agile Lean Development Set of principles 2014

eXponential Simple Continuous

Autonomous Learning Ecosystem Set of principles 2014

Lean Enterprise Agile Framework Framework 2015

Nexus Framework 2015

FAST Agile Set of methods 2015

Comparison

Template

Backup: Creation of the comparison table

Gathering of existing

comparison criteria

Elimination of duplicates and

subjective crtieria

Categorization of the final

criteria


Literature

Research

Backup: Definition of artifacts, events and roles of LeSS


Artifact

Product Increment output of every sprint

Product Backlog defines all of the work to be done on the product

Sprint Backlog work that the team will need to do for completing the selected Product Backlog Items

Event

Sprint in each sprint, a potentially shippable product increment results; duration: 2-4 weeks

Sprint Planning one all of the teams come together and decide which team will work on which items

Sprint Planning two separate meeting per team where each team creates the plan for getting the items to ‘done’ during the Sprint

Daily Scrum

daily meeting per team, during which each team member tells, what he did yesterday, what he will work on today, and possible impediments

Sprint Review

inspect-adapt point at the end of the Sprint; customers and stakeholders examine what the teams built during the Sprint and discuss changes and new ideas

Sprint Retrospective

at the end of the sprint; each team has ist own retrospective; create a plan for improvements to be enacted during the next Sprint

Overall retrospective discussion of cross-team, organizational, and systemic problems within the organization

Roles

Scrum master responsible for one up to three teams

product owner

one product owner for all teams; responsible for maximizing the value of the product and the work of the Development Team; at scale the focus is rather on keeping an overview and ensuring the maximum return on investment (ROI) in the product

development team Source: based on LeSS

Backup: Definition of artifacts, events and roles of SAFe


Role

Team Level

Scrum Master

servant leaders and coaches for an Agile team; help educate the team in Scrum, eXtreme Programming, Kanban and SAFe, ensuring that the agreed Agile process is being followed

Product Owner

content authority for the team level; responsible for the team backlog, prioritizing and accepting stories, and representing the customer to the Agile team

Agile Team member

Program level

Release Train Engineer

coach for the ART; facilitate the major events and processes, and assist the teams in delivering value

System architect/engineer

represents an individual or small team that defines a common technical and architectural vision for the Solution under development

Product Management

authority for the Program Backlog; responsible for identifying customer needs, prioritizing features and developing the program Vision and Roadmap

Business Owner

small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and Return on Investment for a Solution developed by an Agile Release Train

Source: based on SAFe 2016



Role

Value stream level

Value stream engineer similar role as RTE; facilitatin and guiding the work of all ARTs and suppliers

Solution management

content authority for the Solution Backlog; work with Customers to understand their needs, create the Solution vision and Roadmap, define requirements, and guide work through the Solution Kanban

Solution architect/engineer help align the Solution Train and the Agile Release Train to a common technological and architectural vision

Portfolio level

Program Portfolio Management highest decision making responsibility;

Enterprise architect fosters adaptive design and engineering practices, and drives strategic architectural initiatives for a SAFe Portfolio

Epic owner responsible for coordinating portfolio epics through the Portfolio Kanban system


Event

Team level

Iteration

Iteration Planning

all team members determine how much of the team backlog they can commit to delivering during an upcoming iteration

Iteration execution

Team demo team reviews the increment that results from the iteration

Iteration retrospective team member discuss their practices and identify ways to improve

Program level

Innovation and planning iteration

estimating buffer for meeting PI objectives, as well as providing dedicated time for innovation, continuing education, and PI planning and Inspect and Adapt (I&A) events

System Demo

demonstration of the subject system being built by the ART; test and evaluate the full system that the Agile Release Train is working on and to get feedback from the primary stakeholders

Inspect and adapt

held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated

Program Increment Planning

a routine, face-to-face event with a standardized agenda that includes presentation of business context and Vision, followed by team planning breakouts wherein the teams create the plans for the upcoming Program Increment

Value stream level

Solution demo

results of development efforts from the Solution Train are made visible to customers and other stakeholders

Pre- and post- PI Planning

for multiple ART; supports and coordinates the ARTs involved in the value stream; build a plan for the next PI




Artifact

Team level Team Backlog

contains user and enabler stories that originate from the program backlog, as well as stories that arise locally from the team’s specific context

Program level & Value Stream level

Program Backlog and Value stream backlog

prioritized list of Features that have been analyzed and are intended to address user needs and deliver business benefits for a single Agile Release Train

Portfolio level Portfolio backlog

highest-level backlog in SAFe; provides a holding mechanism for the upcoming Business and Enabler Epics intended to create a comprehensive portfolio solution set

Architectural runway

consists of the existing code, components and technical infrastructure necessary to support implementation of prioritized, near-term features, without excessive redesign and delay

Solution Context

identifies critical aspects of the operational environment of a solution; essential understanding of requirements

Solution intent

critical knowledge; basic understanding of the current and evolving requirements

Backup: further related work

Turetken (2016): Development of a maturity model

lack of a well-structured gradual approach for establishing SAFe

before and during SAFe adoption, organizations can benefit from a uniform

model for assessing the current progress and create a roadmap for the

initiative

To address this need, a maturity model that provides guidance for software

development organizations in defining a roadmap for adopting SAFe is

developed


Documents

Survey and Analysis of Scaled Agile Frameworks for an Agile … · ... Product Owner, Scrum Master, Development team, Area Product Owner Events Iteration ... Inspect and Adapt, Iteration