Agenda: Agile Definition Agile Adoption How To Scale Enterprise Agile Frameworks Scrum@Scale LeSS Nexus

1. Mahmoud Ghoz | Agile Coach | SWVL
Enterprise Agile Frameworks
AUG Cairo

2. Agenda
Agile Definition
Agile Adoption
How To Scale
Enterprise Agile Frameworks

3. Introductions
Mahmoud Ghoz
SWVL
Agile Coach

4. Agility

6. “Do Agile Right” and “Agile for
Dummies” are just two of the
innumerable attacks on the English
language featuring the word. They are
meaningless. Agile is not a noun, it’s an
adjective, and it must qualify
something else. “Do Agile Right” is like
saying “Do Orange Right.”
What is Agile?
Dave Thomas
Source: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html

7. What is Agility?
Agility is
delivering
the right
work at the
right time.

8. What is Agile Software Development?
Agile Software Development is an
umbrella term for a set of values,
principles, methods and frameworks,
all of which adhere to the Manifesto
for Agile Software Development.

9. Is this an Agile Software Development?

10. Agenda
Agile Definition
Agile Adoption
How To Scale
Enterprise Agile Frameworks

11. Adopting Agile methodology

12. Adopting Agile methodology

13. Agenda
Agile Definition
Agile Adoption
How To Scale
Enterprise Agile Frameworks

14. How to Scale?

15. Factors to consider while scaling
Executive leadership support
It is the most fundamental factor in transformation.
Successful transformations have leadership that is deeply engaged
Knowledge acquisition
Inadequate knowledge or guidance creates chaos and poor implementation
A systematic training and coaching program on agile values and processes is required.
Integrating non software team
Include more teams and functions in the transformation journey
The acceptance to a new way of working will led to the stability and quality of releases

16. SCREENSHOT SLIDE
Tools and infrastructure
Invest in modern tools and infrastructure to support fast and frequent deliveries
Engineering excellence
A strong engineering culture is very important when scaling agile
Agile champions and change agents
You!
Any successful change requires someone who can translate an organization's vision into reality.

17. Agenda
Agile Definition
Agile Adoption
How To Scale
Enterprise Agile Frameworks

18. What is Framework?

19. Enterprise Frameworks

20. Enterprise
Frameworks
Scrum@Scale
LeSS
Nexus

22. Scrum@Scale
History
The What
The Why
The How
• Jeff Sutherland Co-founded Scrum 1995
• Jeff Sutherland co-create the Scrum Guide
• The first rollout of Scrum@Scale in 2014
• In 2017 Scrum Alliance leadership asked Scrum Inc. to work
with them on a formalized scrum scaling framework.
• Jeff Sutherland Stepped down as a CEO from scrum Inc. in
Jan 2018 to focus on Scrum@Scale

23. Scrum@Scale
History
The What
The Why
The How
• Scrum Inc. with Scrum Alliance leadership, early at 2018
created the joint-venture Scrum@Scale
• The purpose was creating a framework that would be as
useful to the business and executives as to the people on
the scrum teams.
• In May 2018 the 1st iteration of the guide has been released
• Previously know as Scrum of Scrums

24. Scrum@Scale
History
The What
The Why
The How
• Lightweight: The minimum viable bureaucracy
• Simple to understand: Consists of only Scrum Teams
• Difficult to master: Requires implementing a new operating
model
• Framework that is radically simplifies scaling by using Scrum
to scale Scrum.
• The Scrum@Scale Guide defines and describes the
framework.

25. Scrum@Scale
History
The What
The Why
The How
• Most organizations are hierarchical, with authority centered
at the top.
• Having many levels resulting in long decision cycles and
frequent status updates to keep leadership informed.
• This structure reduces agility and responsiveness
• This also reduce the autonomy of the workforce and the
engagement of the teams delivering value.
• Scrum@Scale organizes via networks of teams
• Each team is full autonomous within their scope
• They are interacting with each other as needed to deliver
value quickly.

26. Scrum@Scale
History
The What
The Why
The How
• Authority is distributed via the Scrum guidelines.
• Product Owners at all levels have the authority over the
content of their area aligned through the Product Owner
Cycle.
• Scrum Masters are the owners of the process and work
together to improve flow and effectiveness of the
organization.
• The Development teams have authority over delivery.
• This authority distribution model enables agility and
engagement.
• It also allows the growth of agility to expand organically
based on the needs and desires of the people in the
organization.

27. Scrum@Scale
History
The What
The Why
The How

28. Scrum@Scale
History
The What
The Why
The How
• A set of Scrum Teams that need to coordinate in order to
deliver value to customers comprise a Scrum of Scrums
(SoS).
• This team is responsible for a fully integrated set of
potentially shippable increments of product at the end of
every Sprint from all participating teams.
• A SoS functions as a Release Team and must be able to
directly deliver value to customers.
• A Scrum of Scrums operates as a Scrum Team with scaled
versions of the Scrum roles, events and artifacts.

29. Scrum@Scale
History
The What
The Why
The How

30. Scrum@Scale
History
The What
The Why
The How
• Product Owner Team: Aligns the teams’ priorities along a
single enterprise backlog so that they can coordinate their
Scrum Team’s backlogs and build alignment with
stakeholders.
• Chief Product Owner (CPO): Coordinates priorities among
Product Owners who work with individual teams.

31. Scrum@Scale
History
The What
The Why
The How

32. Scrum@Scale
History
The What
The Why
The How
• Scrum of Scrums Master (SoSM): The SoSM is accountable
for the release of the joint teams’ effort.

33. Scrum@Scale
History
The What
The Why
The How
• Executive Action Team (EAT): Fulfills the Scrum Master role
for the entire agile organization.

34. Scrum@Scale
History
The What
The Why
The How
• Executive MetaScrum Team (EMS): The EMS owns the
organizational vision and sets the strategic priorities, aligning
all the teams around common goals.

35. Scrum@Scale
History
The What
The Why
The How

36. Scrum@Scale
History
The What
The Why
The How

37. LeSS

38. LeSS
History
The What
The Why
The How
• Bas Vodde and Craig Larman evolved the LeSS framework
• Both are scrum alliance trainers (CST)
• They are working with clients since 2005 to scale up Scrum.

39. LeSS
History
The What
The Why
The How
• Published two book in 2008 and 2010 to help people learn
based on their experiences with clients on scaling agile
development with the LeSS frameworks.

40. LeSS
History
The What
The Why
The How
• LeSS is Scrum applied to many teams working together on
one product.
• LeSS is Scrum: Large-Scale Scrum (LeSS)
• LeSS isn’t new or improved Scrum.
• It’s not Scrum at the bottom for each team, and something
different layered on top.
• It’s about figuring out how to apply the Scrum principles in a
large-scale context.

41. LeSS – The Why

42. LeSS
History
The What
The Why
The How
• Large-Scale Scrum is Scrum: LeSS is about figuring out how
to apply Scrum in a large-scale context
• Transparency: Based on tangible “done” items, short cycles,
working together, common definitions, and driving out fear in
the workplace.
• More with less: We don’t want more roles, more
artifacts, more process. We want more responsible,
customer-focused, ownership, and meaningful work.

43. LeSS
History
The What
The Why
The How
• Whole-product focus: One Product Backlog, one Product
Owner, one shippable product, one Sprint—regardless if 3 or
33 teams.
• Continuous improvement towards perfection
• Lean thinking: Create an organizational system whose
foundation is managers-as-teachers who apply and teach
lean thinking.

44. LeSS
History
The What
The Why
The How
• Systems thinking: See, understand, and optimize the whole
system (not parts).
• Empirical process control—Continually inspect and adapt
everything.
• Queuing theory: Understand how systems with queues
behave and apply those insights to manage queue sizes,
work-in-progress limits, multitasking, work packages, and
variability.

45. LeSS
History
The What
The Why
The How
• Large-Scale Scrum has two frameworks:
• LeSS. 2–8 Teams
• LeSS Huge. 8+ Teams
• The word LeSS is overloaded to mean both Large-Scale
Scrum in general and the smaller LeSS framework.
• LeSS is a scaled up version of one-team Scrum, and it
maintains many of the practices and ideas of one-team
Scrum.

46. LeSS
History
The What
The Why
The How
• A single Product Backlog
• One Product Owner
• One Potentially Shippable Product Increment
• One Definition of Done for all teams
• Many complete, cross-functional teams
• One Sprint

47. LeSS
History
The What
The Why
The How
• Sprint Planning Part 1: In addition to the one Product
Owner, it includes people from all teams. Let team members
self-manage to decide their division of Product Backlog
Items. Team members also discuss opportunities to find
shared work and cooperate, especially for related items.

48. LeSS
History
The What
The Why
The How
• Sprint Planning Part 2: This is held independently (and
usually in parallel) by each Team, though sometimes for
simple coordination and learning two or more Teams may
hold it in the same room (in different areas).

49. LeSS
History
The What
The Why
The How
• Daily Scrum: This is also held independently by each Team,
though a member of Team A may observe Team B’s Daily
Scrum, to increase information sharing.
• Coordination: Just Talk, Communicate in Code, Travelers,
Open Space, and Communities.

50. LeSS
History
The What
The Why
The How
• Product Backlog Refinement: The only requirement in
LeSS is single-team PBR, the same as in one-team Scrum.
But a common and useful variation is multi-team PBR, where
two or more Teams are in the same room together, to
increase learning and coordination.

51. LeSS
History
The What
The Why
The How
• Sprint Review: In addition to the one Product Owner, it
includes people from all teams, and relevant
customers/users and other stakeholders. For the phase of
inspecting the product increment and new items.

52. LeSS
History
The What
The Why
The How
• Overall Retrospective: This is a new meeting not found in
one-team Scrum, and its purpose is to explore improving the
overall system, rather than focusing on one Team. The
maximum duration is 45 minutes per week of Sprint. It
includes the Product Owner, Scrum Masters, and rotating
representatives from each Team.

53. LeSS

54. Nexus

55. Nexus
History
The What
The Why
The How
• The Nexus framework was created by Ken Schwaber
• Ken Schwaber is the Co-founder of Scrum
• He Co-create the scrum guide.
• The Nexus Guide released in 2015

56. Nexus
History
The What
The Why
The How
• Nexus is a framework that drives to the heart of scaling by
minimizing cross-team dependencies and integration issues.
• The Nexus framework is a foundation to plan, launch, scale
and manage large product and software development
initiatives.
• Nexus is for organizations to use when multiple Scrum
Teams are working on one product as it allows the teams to
unify as one larger unit, a Nexus.
• As an “exoskeleton,” a Nexus protects and strengthens the
teams by creating connections between them and by
maintaining bottom-up intelligence.
• The foundation of a Nexus is to encourage transparency and
keep scaling as uniform as possible.

57. Nexus
History
The What
The Why
The How
• Scrum is a simple framework for delivering software products
• It using an empirical approach in which teams deliver value
in small increments, inspect the results, and adapt their
approach as needed based on feedback.
• It consists of a small set of events, roles, and artifacts, bound
together by practices, and enlivened by values that are the
key to making it work.
• Nexus extends Scrum to guide multiple Scrum Teams on
how they work together to deliver working software in every
Sprint.
• It shows the journey these teams take as they come
together, how they share work between teams, and how they
manage and minimize dependencies.

58. Nexus
History
The What
The Why
The How
• A Nexus consists of 3-9 Scrum Teams working on a single
Product Backlog to build an Integrated Increment that meets
a goal.
• The framework is especially beneficial for organizations who
have had positive results using Scrum with one or two teams
working on a single product and who want to scale more
broadly.
• On the flip side, it is also extremely useful for those
struggling with a scaled initiative as the framework focuses
rigorously on two core scaling matters, cross-team
dependencies and integration issues.

59. Nexus
History
The What
The Why
The How
• The Nexus framework introduces one new role, the Nexus
Integration Team (NIT).
• The NIT is responsible for ensuring that an Integrated
Increment (the combined work completed by a Nexus) is
produced at least every Sprint.
• It is ultimately accountable for the successful integration of
all work created by all the Scrum Teams in a Nexus.
• Common activities may include identifying cross-team
issues, raising awareness of dependencies early, and
ensuring integration tools and practices are understood and
used.
• In emergency situations, the NIT may actually do the work in
order to fulfil their accountability.

60. Nexus

62. Shuhari
• shu (守) "protect", "obey"—traditional wisdom—learning fundamentals,
techniques, heuristics, proverbs
• ha (破) "detach", "digress"—breaking with tradition—detachment from the
illusions of self
• ri (離) "leave", "separate"—transcendence—there are no techniques or
proverbs, all moves are natural, becoming one with spirit alone without
clinging to forms; transcending the physical

64. Thank you!
Mahmoud Ghoz | Agile Coach | SWVL