Illuminating the potential of Scrum by comparing LeSS with SAFe

Illuminating the potential of Scrum by comparing

LeSS with SAFe

with Rowan Bunning, CST and CLP

© 2016 Scrum WithStyle scrumwithstyle.com @rowanb

Please note• Goal of this session:

awareness of the potential of ‘deep’ Scrum adoption at any scale.

• More about that than an comparison between SAFe and LeSS.

• There is lots to learn about Scrum by understanding the differences.

• This is not an introduction to Scaled Agile Framework (SAFe) and Large-Scale Scrum (LeSS).

• Appreciating the importance of some concepts may require deeper exploration than we have time for.

http://scrumwithstyle.com


Session outline• Unrealised potential

• Key things to know about SAFe and LeSS

• Business - Development relationship

• Team structure and batching

• Organisational control

• Co-ordination

• Where Scrum’s potential can be found


Unrealised potential

@rowanb© 2016 Scrum WithStyle scrumwithstyle.com

Payoff vs Extent of Scrum Adoption

Overall Payoff

Extent of Scrum Adoption

Deep Scrum including implications of Scrum and Lean principles

Implementation as per what is explicit Scrum Guide only

Superficial Scrum as typically implemented



Scrum adoption icebergScrum as typically adoptedWhat is Explicit in Scrum Guide

The implications of Scrum that are implicit Explicit in LeSS

The endless potential of continuous improvement

Shallow adoption

Deep adoption



Single-function job titles No job titles or sub-teams

Individuals accountable outside of team Team is accountable as a whole

Content and timing of releases decided by committee

Content and timing of releases decided by Product Owner

Sprint Review involves inspection Sprint Review involves collaborative

adaptation

Shallow Scrum as typically adopted

Wha

t is Explicit

in th

e Sc

rum

Gui

deThe Tip of the Adoption Iceberg…



by committee Content and timing of releases

decided by Product Owner


adaptation

Pseudo / Potential Team Real / Exceptional Team

Undone work each Sprint Potentially Shippable

Product IncrementTeam work focus

Whole Product focus

Managers decide what, how and do tracking

Managers support and build capability

Co-ordination mostly centralised Co-ordination mostly

decentralised

Contract Game Co-operative Game

Single-function specialists People with T-Shaped skills

Temporary Projects Long-lived Product

Development

Component teams Feature Teams

Bureaucratic control Market + Clan control

Steep hierarchy Minimum viable hierarchy

Team membership changes to fill skills gaps Stable teamsCentralised specifier roles

Decentralised specification

Multiple localised process improvement efforts

Whole of organisational system process improvement

ScrumMaster focussed on team ScrumMaster focussed on

organisational system

Wha

t is Explicit

in th

e Sc

rum

Gui

deD

eep

Scru

m -

Impl

icit

in S

crum

Organisation as Factory Learning Organisation

Deep Adoption…


Key things to know about SAFe and LeSS


150 peopleApplicability Thousands of

people

>8 teamsLeSS

LeSS Huge

SAFe - single ART

V

alue Stream of ARTs

2 teams

12 people

50 people

ART sweet spot: “100 or so”

Who is working with a group of between 12 and 50?



Different framings of the problem

Customer-centric LearningProgram Execution


© 2014 Scrum WithStyle scrumwithstyle.com

Not agile

Thanks to: Joseph Pelrine


Becoming agile…



Not like this though…



Scrum Space for context-specific elements to emerge

PrescriptivenessHow detailed, complicated and

fully-defined a framework is

High

• Not contextual enough • Over-specification makes it

difficult for org. learning • In practice, leads to

method bloat

Example: Learning Organisations (Peter Senge, Chris Argyris etc.)

Low

• Just a few principles • Not enough that is concrete

to know what to do • Easy to ‘fake-it’

Intent: • Sufficient enabling structure • Plenty of freedom for Empirical

Process Control & learning

Thanks to: Craig Larman



SAFe contains Scrum

Scrum ScrumTeam

Program

Value Stream

Portfolio



LeSS is Scrum

Team

Program

Value Stream

Portfolio

⬆

Scrum⬇



LeSS takes a different approach

Rather than having Scrum as a building block for a scaled framework, we need to look at Scrum and for each element ask “Why is it there?” followed by “If we have more than one team, how can we achieve the same purpose on a larger scale?”

- Craig Larman


💡Insight…


Scrum need not be limited to the ‘team level’. It scales vertically.


Business-Development relationship


External contracts spawn internal contracts

Business

External customers

Development / I.T.

External contract

Internal contract



We want a solution. How much is it going to cost? How long is it going to take?

Product

Management

R&Dstart end

(release)

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde

All rights reserved.

Business Development



Product

Management

R&Dstart end

(release)content freeze

(release contract agreed)

more,

more,

more!

1

The Milestone point

is arbitrary

The Contract

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde


Business

Date & Scope

Development



Product

Management

R&Dstart end



The Milestone point

is arbitrary

more,

more,

more!

less,

less,

less!

1 2

The Contract

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde



The date and scope contract point represents the time that

both parties have maximised the ability to shift blame when

something goes wrong.

Date & Scope



Product

Management

R&Dstart end



The Milestone point is arbitrary

The Contract

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde



Date & Scope



Product

Management

R&Dstart end




The Contract

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde

All rights reserved.Date & Scope

Responsibility

low controllow flexibility

low transparencybig batches

cannot release earlynot “done” until the end

Businesshave

completed date and

scope move

Development

shifts



Who has seen something like this going on?

Who is working to an scope & date agreement now?

Show of hands "



Product

Management

R&Dstart end



* Development Phase for The Contract is controlled by R&D.

* The order of work is decided by R&D.

* Product Management does not have control, and there is low

visibility into the status of true progress.

The Contract

ineffective bonus schemes and "tracking

to plan" behaviors are injected, since

there is no real control or visibility

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde


Business

• Development Phase for The Contract is controlled by the development group

• The order of work is decided by the development group• The Business does not have control, and there is low

visibility into the status of true progress.

Development



Shifting blame

Product

Management

R&Dstart end




The Contract

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde


DevelopmentBusiness

There’s been a surprise!

But you committed!

Date & Scopesign-off



We have a two party competitive game

your faultyour fault

Product

Management

R&Dstart end

(release)

your fault your fault

The Contractwww.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde





Now development pulls out the ‘Secret Toolbox’ including…

• Stopping testing

• Crappy code

• No longer thinking about the design

• No longer taking time to learn

• Not fixing weakness in organisation

• Overtime leading to attrition of the best people



On the SAFe PI Planning game“This planning process has history with Nokia Phones, where the upper management decided the schedule and content for the next model. Even when at the talk level this is assumed to communicate realism upwards, the process is really commitment game. Even, if the management culture accepts the spirit of realism, the process itself assumes that you are able to commit locally for the common good.

The teams are "staying in the room" until they vote yes or no for the plan. They quickly learn to vote yes, because no means re-planning :)”

- Ari Tikka (formerly at Nokia Mobile where SAFe began)




Business stakeholders

External customers

Agile Release Train

PI scope and date commitment

External demand




Business stakeholders

External customers

Teams

External demand

✘ No Scope and Date contract✔ Business steers directly☸PO

📖


Scrum has the potential…


To eliminate the win-lose contract game between Business and Development and

shift to a win-win co-operative game. To end the blame game. To begin rebuilding trust.



What does the Agile Manifesto have to say about this?



Two simple but critical questions…

Who is the customer to focus on? What is the product to focus on?



Insurance company

What is our Product really?

Insurance Sales

Underwriting Solution

Premium Billing

Claims System

Quoting engine

Leads and Opportunities

Policy provider application

Rules engine

Premium system

Insurance booking system

Premium payment system

Claim checker

Pay back engine

Underwriting workflow manager

Thanks to: Viktor Grgić for the example

The Market I see a Get Insurance system

…and a Handle Claim system

‘System of systems’ (SAFe) or

‘Product’ (LeSS)Insured Customer

Head of Department

No, This is a product

Architect

No, This is a product

Project Manager

This is a product



Whole Product Focus

- Bas Vodde

“It is really really hard to get teams to always consider the whole product instead of just “their tasks”. And in the LeSS Framework we do everything we can to avoid sandboxing, such as not preselecting items to teams, not having separate backlogs, not having separate POs, etc.”

Lean Principle: Optimise the Whole




to help the organisation focus on the end customer by defining your product in terms

of what creates value for the customer.


Team structure and batching


Component teams lead to planning complexity

Item 1

Item 2

Item 3

...

Item 20

…

Item 42

current release:

need more people

next release:

need more people

System

next release

current release

Comp A

Team

Comp B

Team

Comp C

Team

Component

A

Component

B

Component

C

www.craiglarman.com

www.odd-e.com

Copyright © 2009

C.Larman & B. Vodde


How to manage these dependencies?



Planning around component teams

Image credit: boost.co.nz



LeSS emphasises Feature-teams that are multi-component

Item 1

Item 2

Item 3

Item 4

…

…

Comp A

Team

Comp B

Team

Comp C

Team

Component

A

Component

B

Component

C

Product

Owner

Feature

Team

Red

tasks for A

tasks for B

tasks for A

tasks for B

tasks for A

tasks for C

contains ex-members

from component

teams A, B, and C,

and from analysis,

architecture, and

testing groups

system

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde




Dependencies are pushed from planning to integration

Item 1

Item 2

Item 3

Item 4

...

…

system

comp

C

Team

comp

A

Work from multiple teams is required to finish a customer-centric feature. These dependencies cause waste such as additional planning and coordination work, hand-offs between teams, and delivery oflow-value items. Work scope is narrow.

Product

Owner

comp

B

Team

comp

A

Team

comp

B

comp

C

Item 1

Item 2

Item 3

Item 4

...

…Team

Wu

Product

Owner

Team

Shu

Team

Wei

system

comp

A

comp

B

comp

C

Every team completes customer-centric items. The dependencies between teams are related to shared code. This simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning.Work scope is broad.

Component teams Feature teams

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde




Co-ordination is in shared code

Item 1

Item 2

Item 3

...

Item 8

…

Item 12

Team

Wei

Team

Shu

Team

Wu

Component

A

Component

B

Component

C

With feature teams, teams can always work on the highest-value features, there is less delay for

delivering value, and coordination issues shift toward the shared code rather than coordination

through upfront planning, delayed work, and handoff. In the 1960s and 70s this code coordination

was awkward due to weak tools and practices. Modern open-source tools and practices such as

TDD and continuous integration make this coordination relatively simple.

system

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde




Feature teams are customer-centric

Team has the necessary knowledge and skills to complete

an end-to-end customer-centric feature. If not, the team is

expected to learn or acquire the needed knowledge and skill.

Feature team:

- stable and long-lived

- cross-functional

- cross-component

customer-

centric

feature

potentially

shippable

product

increment

Product

Backlog

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde




SAFe Batch Size

Thanks to: Ran Nyman and Ari Tikka, Xp2015 Scaling Agility explored - LeSS SAFe comparison

Development System

Work pre-allocated to Sprints for 8-12 weeks

Large batches to reduce cost due to component teams

Program Increment

Backlog



The trade-off

Pre-allocating items to Sprints ahead of time closes off options and diminishes

Sprint-to-Sprint agility.



LeSS Batch Size

Thanks to Ran Nyman and Ari Tikka, Xp2015 Scaling Agility explored - LeSS SAFe comparison

Development System

2 weeks

Small batches that enable fast feedback

BacklogPotentially Shippable Product Increment

SPRINTREVIEW

RETROSPECTIVE

OVERALLRETROSPECTIVE

SPRINTPLANNING1PREVIOUS

SPRINTNEXTSPRINT

PRODUCTBACKLOG

PRODUCTOWNER

SPRINTBACKLOG

SCRUMMASTER&FEATURETEAM

PRODUCTBACKLOG

REFINEMENT

DAILYSCRUMCOORDINATION

POTENTIALLYSHIPPABLEPRODUCT INCREMENT

SPRINTPLANNING2




to produce a Potentially Shippable Product Increment every fortnight…

no matter how many teams… as long as they are feature teams integrating continuously.

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5


Organisational Control


Program

Value Stream

Program control abstraction

Value Stream control abstraction

SAFe introduces control abstractions

Teams

Customer focused Product

Customer



Control systems in organisations

Market system

Bureaucratic system

Clan system

• Prices drive very efficient decision making • Measure Input and Output

• Formal rules, roles, processes, compliance • Supervision, direction and hierarchy • Specialisations enable clearer comparison with

like workers

• Informal value based rules • Allows innovation and collaboration • Most suitable for unique, interdependent or

ambiguous work e.g. software development Reference: A Conceptual Framework for the Design of Organizational Control Mechanisms, William G. Ouchi, Management Science, Vol. 25, No. 9. 1979.



Control mechanisms in SAFeMarket control

Bureaucratic control

many roles, processes, written rules to

manage execution within PI

Scope & Date contract

Clan control



Who would like less Bureaucratic control?Market control


Clan control

You Ain’t Gonna Need It (YAGNI)

Try… direct business - development collaboration using the simplicity of Scrum patterns

for Minimum Viable Bureaucracy (MVB)



Control mechanisms in LeSSMarket system


Clan control

self-managing teams

self co-ordination decisions at level of richest information

PO

≪component≫ Publishing

≪component≫ Scheduling

≪component≫ Expenses

≪component≫ KPI Dashboards

Direct co-ordination

Communities for knowledge sharing and agreements Architecture, UX, Testing etc.

💡 $😀 ☸



LeSS is about Descaling…

• Descaling roles and organisational hierarchy

• Descaling organisational structures, policies, etc.

• Descaling architectural complexity

LeSS is More!




to decrease bureaucracy and increase business-development

collaboration

For more on this see:



The heart of Scrum

Thanks to: Simon Bennett.

Vision Product

Inspect & Adapt

People Capability

Inspect & Adapt



Frequency of Demos vs Sprint Reviews


Sprint Reviews - Inspect & Adapt Whole Product (2hrs max)

Team Demos

Solution Demo (After all PI System demos, 1-2 hour)

System Demos



Frequency of overall reflection


Value Stream Retrospective and Problem-solving workshop

PI Retrospective and Problem-solving workshop

Overall Retrospectives - Inspect & Adapt Organisational System



Demos vs Sprint ReviewsSprint ReviewPurpose: “inspect the Increment and adapt the Product Backlog”

Intent: “optimise value”

Solution DemoPurpose: “stakeholder and customer feedback” “celebrate the accomplishments” “harbinger of near-term… decisions”

Mostly Value Stream and senior ART people

PI System DemoPurpose: “to test and evaluate the full system”

Intent: “stay on course or take corrective action”

Mostly PMs, POs and senior people One or more team members there to stage demo

Team DemoPurpose: “closure” “to show” “feedback” “measure the team’s progress”

Mostly teams and POs Senior people likely not interested

“The Sprint Review is an opportunity for everyone to collaborate about the product.” - less.works

😃$




Business and development collaborate face-to-face on the direction of the product…

every Sprint. To focus everyone on the Whole Product.

To “turn on a time, for a time”📖



Product Owner: Team or Product focused?

Team

Business Owner

Customer

Product Manager

2..4

Product Owner

1..2

TheProductOwnerTheProductOwnerisresponsibleformaximizingthevalueoftheproduct

The person with the external (market) contract problem steers directly

PO☸



Product Owner can work with up to 8 teams when clarification is delegated

PO

Requesters Users Market / domain experts

DecisionsContent and order of Product Backlog

DetailClarification - splitting, acceptance criteria etc.

💡 $😀

“Yes” “No” “A little now, rest later” “Sooner” “Later”

☸


💡Insight…


Scrum facilitates direct interaction between business people and development teams…

…and not just with the Product Owner.



1Scientific RepoRts | 5:18634 | DOI: 10.1038/srep18634

www.nature.com/scientificreports

Hierarchy is Detrimental for Human CooperationKatherine A. Cronin1,2, Daniel J. Acheson3, Penélope Hernández4 & Angel Sánchez5,6

Studies of animal behavior consistently demonstrate that the social environment impacts cooperation, yet the effect of social dynamics has been largely excluded from studies of human cooperation. Here, we introduce a novel approach inspired by nonhuman primate research to address how social hierarchies impact human cooperation. Participants competed to earn hierarchy positions and then could cooperate with another individual in the hierarchy by investing in a common effort. Cooperation was achieved if the combined investments exceeded a threshold, and the higher ranked individual distributed the spoils unless control was contested by the partner. Compared to a condition lacking hierarchy, cooperation declined in the presence of a hierarchy due to a decrease in investment by lower ranked individuals. Furthermore, hierarchy was detrimental to cooperation regardless of whether it was earned or arbitrary. These findings mirror results from nonhuman primates and demonstrate that hierarchies are detrimental to cooperation. However, these results deviate from nonhuman primate findings by demonstrating that human behavior is responsive to changing hierarchical structures and suggests partnership dynamics that may improve cooperation. This work introduces a controlled way to investigate the social influences on human behavior, and demonstrates the evolutionary continuity of human behavior with other primate species.

Determining the conditions that facilitate cooperation in humans has been a challenge embraced by many disci-plines; evolutionary biologists, psychologists, and social scientists have been attempting to tackle this question for decades1–3. Understanding when cooperation flourishes is of both theoretical and practical interest as our species faces environmental and societal challenges that may only be solved by working together4,5. Cooperation has been defined in many ways6; here we are referring to cases in which two or more individuals work together to achieve a common goal7. While this form of cooperation is not altruistic (nobody necessarily incurs a cost for cooperating), choosing with whom to cooperate and under what conditions to invest limited resources into cooperation poses a significant challenge for our species and others8–10.

The effect of the social environment on cooperation has received attention in studies of nonhuman animal behavior but has been largely overlooked in human research. Research with animals in the wild and under con-trolled conditions in captivity has consistently shown that social dynamics, and specifically the nature of the dominance hierarchy, has a large impact on cooperative outcomes9,11–19. Although variable in form, every animal society has some form of dominance hierarchy20,21. Hierarchy is defined as priority of access to resources and probability of winning competitive encounters22, and reflects underlying assymetries in power. A hierarchy can be characterized in terms of linearity and steepness22, with the former providing information about the degree of transitivity between individuals and the latter indicating the extent to which individuals differ from each other in winning encounters or accessing resources. Among nonhuman primates, it has been demonsrated repeatedly that the characteristics of dominance hierarchies impact cooperative outcomes, with steep and linear hierarchies being associated with decreased cooperation. For example, experiments have shown that cooperation is impeded among chimpanzees living in steep and linear hierarchies16,23, whereas it emerges more easily among species with more relaxed hierarchies such as cottontop tamarins15–17.

1 inco n ar oo ester . is er enter for t e tu an onser ation of reat pes ica o I 60614 . a anc Institute for s c o in uistics omparati e o niti e nt ropo o roup 65 5 D i me en e

et er an s. 3Don ers Institute for rain o nition an e a iour i me en e et er an s. 4 ni ersitat e a ncia I Departamento e n isis con mico pain. 5 ni ersi a ar os III e a ri rupo

Inter iscip inar e istemas omp e os I Departamento e atem ticas an Institute 3 of inancia i Data 8 11 e an s a ri pain. 6 ni ersi a e ara o a Instituto e iocomputaci n sica e istemas omp e os I I 50018 ara o a pain. orrespon ence an re uests for materia s s ou e a resse to . . .

emai : cronin p oo.or

recei e : 30 a 015

accepte : 0 o em er 015

Pu is e : Decem er 015

OPEN


@rowanb© 2016 Scrum WithStyle scrumwithstyle.comCPJ inspired by Jeff Bezos' most recent annual letter. https://medium.com/21st-century-organizational-development/type-2-organizations-df3f1f53c66c

Which is Scrum enabling?



The responsive organisation“The future of work is...

an organisation — a decision system — built to break down big decisions and jobs into smaller pieces that can be processed much more rapidly, replacing the illusion of top-down control over the future with realtime, active control over the present. It’s an organisation where very few decisions are made for others, but many more decisions are being made in the open.”

From CPJ inspired by Jeff Bezos' most recent annual letter. https://medium.com/21st-century-organizational-development/type-2-organizations-df3f1f53c66c

Who would prefer something like this?


Co-ordination


Scrum of Scrums: ScrumMaster vs Team representative

“The ScrumMaster is typically the representative in the Scrum of Scrums meeting, and he passes information from that meeting back to the team.”

“ScrumMasters… meet to update their progress toward Milestones, program

PI objectives and internal dependencies…”

“A healthy Scrum of Scrums meeting is attended by team members who do

actual development work and not ScrumMasters or the Product Owner.”

Intermediation Point-to-point connection



Co-ordination overheads can be reduced

Source: less.works/resources/graphics.html



Co-ordination mechanismsCentralised mechanisms

Scheduled meetings

Disadvantages: • bottlenecks • handoffs • delays • inhibit emergent behaviour • teams owning these processes • inhibit empirical process control

Decentralised mechanismsNetworks of people interacting

Disadvantages: • more difficult to get an overview • less broad and consistent info



Co-ordination: Centralised vs Decentralised

• Just talk

• Communicate in Code

• Integration Continuously

• Communities

• Cross-Team Meetings

• Multi-Team Design Workshops

• Current-Architecture Workshops

• Component Mentors

• Open Space

• Travellers

• Scouts

• Maybe don’t do Scrum of Scrums

• Leading Team

• PI Planning

• Pre-PI Planning

• Post-PI Planning

• Scrum of Scrums

• Weekly Release Management meetings

Mostly Centralised mechanisms Mostly Decentralised mechanisms




to radically simplify organisational structure without the overheads of unnecessary

specification, co-ordination and reporting roles.



ScrumMaster: Part-time vs Full-time

“SAFe takes a pragmatic approach and assumes, in general, that the ScrumMaster is a part-time role”

Dedicated full-time roleIn LeSS, the ScrumMaster role is vital. We’ve seen many organizations try part-time ScrumMasters, which usually leads to no ScrumMasters at all. This then affects the LeSS adoption enormously. In LeSS the ScrumMaster is a dedicated, full-time role in the same way that being a Scrum Team member is a dedicated, full-time role. Having said that, it is possible for one full-time ScrumMaster fill the role for up to three teams, depending on any number of factors.


Where Scrum’s potential can be found


Single-function job titles No job titles or sub-teams

Individuals accountable outside of team Team is accountable as a whole


Content and timing of releases decided by Product Owner


adaptation


Tip

of th

e Ic

eber

g - E

xplic

it in

Scr

umWhat SAFe explicitly encourages (1)

(See items in black)



Pseudo / Potential Team Real / Exceptional Team

Undone work each Sprint Potentially Shippable


Whole Product focus


Managers support and build capability

Co-ordination mostly centralised Co-ordination mostly

decentralised

Contract Game Co-operative Game

Single-function specialists People with T-Shaped skills

Temporary Projects ✔ Long-lived Product

Development

Component teams Feature Teams

Bureaucratic control Market + Clan control

Steep hierarchy Minimum viable

hierarchy

Team membership changes to fill skills gaps ✔ Stable teamsCentralised specifier roles

Decentralised specification


Whole of organisational system process improvement

ScrumMaster focussed on team ScrumMaster focussed on


Dee

p Sc

rum

- Im

plic

it in

Scr

um

Organisation as Factory Learning Organisation

What SAFe explicitly encourages (2)(See items in black)



Single-function job titles ✔ No job titles or sub-teams

Individuals accountable outside of team ✔ Team is accountable as a whole


✔ Content and timing of releases decided by Product Owner

Sprint Review involves inspection ✔ Sprint Review involves collaborative

adaptation


Tip

of th

e Ic

eber

g - E

xplic

it in

Scr

umWhat LeSS explicitly encourages (1)

(See items in black)



Pseudo / Potential Team ✔ Real / Exceptional Team

Undone work each Sprint ✔ Potentially Shippable


✔ Whole Product focus


✔ Managers support and build capability

Co-ordination mostly centralised ✔ Co-ordination mostly

decentralised

Contract Game ✔ Co-operative Game

Single-function specialists ✔ People with T-Shaped skills

Temporary Projects ✔ Long-lived Product

Development

Component teams ✔ Feature Teams

Bureaucratic control ✔ Market + Clan control

Steep hierarchy ✔ Minimum viable

hierarchy

Team membership changes to fill skills gaps ✔ Stable teamsCentralised specifier roles

✔ Decentralised specification


✔ Whole of organisational system process improvement

ScrumMaster focussed on team ✔ ScrumMaster focussed on


Dee

p Sc

rum

- Im

plic

it in

Scr

um

Organisation as Factory ✔ Learning Organisation

What LeSS explicitly encourages (2)(See items in black)



Structure has a first-order impact on CultureExcerpt from Larman’s Laws of Organisational Behaviour…

4. Culture follows structure. Or, Culture/behavior/mindset follows system & organisational design. …systems such as Scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture — if the structural change implications of Scrum are actually realized.

Source: craiglarman.com


http://craiglarman.com

💡Insight…


Scrum is a catalyst for meaningful structural change.

Structure has a first-order impact on Culture.

Process is a lower order influencer.



Review1. Scale vertically, not just horizontally to help thousands pull together as one.

2. Reduce bureaucracy and increase business-development collaboration.

3. Transform the win-lose contract game between business and IT into a win-win collaboration game.

4. Focus everyone on the end-customer and re-structure around this.

5. Produce a potentially shippable product increment every fortnight.

6. Enable the organisation to "turn on a dime, for a dime".

7. Enable resilient self-adapting of both What customer value is created and How it is created.

8. Radically simplify organisational structure without the overheads of unnecessary specification, co-ordination and reporting roles.



Conclusions

• The implications of Scrum extend well beyond ‘team level’

• Few organisations have come close to realising the potential pay-offs from Scrum’s implications in the large

• LeSS provides more explicit guidance on Scrum’s implications in the bigger picture

• The biggest initial barriers to realising potential is understanding and buy-in





Where Scrum’s potential is articulatedless.works

Coming soon…



We’re @rowanb au.linkedin.com/in/rowanbunning

Rowan [email protected] scrumwithstyle.com


mailto:[email protected]

Leadership & Management

Illuminating the potential of Scrum by comparing LeSS with SAFe