SlideShare a Scribd company logo
1 of 54
Download to read offline
Copyright Reaktor 2013 Luottamuksellinen
Case Against Scaling 
Back to basics with your enterprise 
transformation 
Sami Lilja 
Reaktor 
Twitter: @samililja 
Copyright Reaktor 2014
How big is big? 
Pick a piece of paper and a pen. 
Think about software / IT projects you 
have been working on. 
Based on your experience fill in the 
blank: 
A project is a big project when it has 
more than ___ people working on it. 
Copyright Reaktor 2014
Copyright Reaktor 2014 
The Beef
Solving the wrong problem 
Source: http://www.medscape.com/viewarticle/806573 
Copyright Reaktor 2014
Finding the right question 
The way we formulate the problem, 
limits our space of potential solutions 
Meetings take too much time 
People lack motivation 
Work environment, the system, 
Copyright Reaktor 2014 
vs. 
We have too many meetings 
vs. 
decreases motivation 
Coordinating between parallel projects 
is not effective 
vs. 
We have too many parallel projects
Scaling Agile? 
The problem is not that we lack ways 
to scale Agile. 
The problem is not that we fail with 
Agile in large organizations. 
The problem is that we are large. 
Size does matter. 
Copyright Reaktor 2014
Copyright Reaktor 2014 
Economy of Scale 
Scalability 
Size 
Cost of 
overhead 
Sublinear = Scales well 
Highly repeatable 
“How many?”
Labor-intensive work 
Copyright Reaktor 2014
Knowledge work? 
Copyright Reaktor 2014
When doing knowledge work in 
Large Scale, the key question is 
not “How?” – it is “Why?” 
Copyright Reaktor 2014
Copyright Reaktor 2014
Organizations getting bigger 
Copyright Reaktor 2014
Pear-shape organizations 
Copyright Reaktor 2014
But, hey.. 
• Do you say companies should not grow? 
– No, I am not saying that 
• Do you say companies should only do 
small things? 
– No, I am not saying that 
– But.. small batches are better than large batches 
• Are you against the frameworks that 
promise Agility in large-scale? 
– No, I am against doing large-scale development 
– However, the frameworks take “large scale” as given 
and do very little to reduce that 
Copyright Reaktor 2014
What makes us Big? 
Large organization or 
project 
Fear of 
transparency 
Copyright Reaktor 2014 
“We need lot of 
different competences” 
“Relative overhead is 
smaller” 
Complex 
systems 
Separating action, 
feedback, knowledge and 
decision making 
“Adding more people 
will speed us up” 
Big projects need lot 
of people need big 
projects need … 
Silos in 
organization 
(Conways’s Law) 
Lot of unfinished 
work (WIP) 
Belief in Economies 
of Scale 
Failure 
Demand 
Short-term 
(Project) thinking
The root of all Evil I 
Work-in-Progress 
Copyright Reaktor 2014
Work-in-Progress 
• How many things your organization is 
currently working on? 
• How easy it is to get dedicated people / 
team to deliver customer value? 
Copyright Reaktor 2014
Hey, but.. 
• Work-in-Progress and Little’s Law are 
about time through system 
• What does this have to do with project 
size? 
• Large amount of WIP helps to create 
unnecessarily large projects 
– When time-through-system gets long, some 
organizations add more people to gain speed 
– People are split to work on many parallel 
projects. Getting X people worth of work 
takes 10x more people 
Copyright Reaktor 2014
Work in Progress 
• Most organizations have too many 
things going on at one time, because 
– People are costly: Fear of <100% resource 
utilization 
– It is easier to start things than complete 
things 
– Large projects require lot of people 
require large projects require lot of 
people.. 
Copyright Reaktor 2014
Work in Progress 
• We underestimate the overhead that 
Work-in-Progress causes 
• In reality, large WIP causes huge and 
costly problems 
Copyright Reaktor 2014 
– Delays 
• time-through-system = Work-In-Progress / Velocity 
– Queues and synchronization problems 
– Internal Failure Demand 
• Meetings, coordination effort, waiting, re-work, …
Sami’s Test #1 
• Think about predictable demand that 
comes to your organization 
– Support request, creating a new service, 
ramp-up of a project, fixing a bug, … 
• What would be the fastest completion 
time for such work in your system, if 
you could do anything to make it 
happen? 
• If your current performance is lower, 
why is that? What causes delays? 
Copyright Reaktor 2014
Quick review 
• Pick a person near you, form pairs or 
triplets 
• In your small group, have a 2 minutes 
discussion about 
– What topics have been covered so far? 
– How do you feel about these topics? 
– What concepts have been significant to you? 
– How could you use these in your work? 
Copyright Reaktor 2014
The root of all Evil II 
Failure Demand 
Copyright Reaktor 2014
Value demand 
Adds value from customer 
point of view. 
Something customers are 
willing to pay for. 
This type of demand we want. 
Copyright Reaktor 2014 
Failure 
demand 
Failure to do what customer 
needs 
Bad quality, wrong product or 
service, delay. 
No product or service. 
Missing either what or how 
customer wants 
Can account up to 80% of work
All demand is considered work 
Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/ 
Copyright Reaktor 2014
Failure demand: Not only bugs 
NEW IT SYSTEM! 
Copyright Reaktor 2014 
Value 
for 
user 
Fail 
CU 
ST 
O 
M 
E 
R 
S 
UP 
P 
O 
R 
T 
“PRESS 1 IF YOU 
CALL ABOUT..” 
“PRESS 2 IF YOU 
CALL ABOUT..” 
“PRESS 3 IF YOU 
CALL ABOUT..”
Internal Failure demand 
Do we need this 
process? 
What thinking 
created this? 
Copyright Reaktor 2014
Hidden Failure demand 
Copyright Reaktor 2014 
Value Demand 
(Project work) 
Failure Demand 
(Bug fixes etc) 
Other 
The Plan 
Value Demand 
(Project work) 
Failure Demand 
(Bug fixes, 
meetings, 
waiting, 
coordination) 
Other 
The reality
Copyright Reaktor 2014 
Dysfunction 
Something in the design and 
management of work that is 
causing problems.
Institutionalized Dysfunction 
Problem that is resolved by adding 
processes or management actions 
and then focusing on actions 
rather than the original problem. 
Copyright Reaktor 2014
Institutionalized Dysfunction 
and Agile Manifesto 
We are uncovering better ways of developing 
software by doing it and helping others do it. 
Through this work we have come to value: 
Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan 
That is, while there is value in the items on 
the right, we value the items on the left more. 
Copyright Reaktor 2014 
Slippery slope to 
institutionalized 
dysfunction
Sami’s Test #2 
• Assume you could freely choose the 
smallest possible number of people to 
implement the product or service. 
• How large would that group be? 
• If such group is significantly smaller 
than your current development 
project, why is that? 
Copyright Reaktor 2014
Quick review 
• Pick a person near you, form pairs or 
triplets 
• In your small group, have a 2 minutes 
discussion about 
– What topics and issues have been covered so 
far? 
– How do you feel about these topics? 
– What topics or concepts have been 
significant to you? 
– How could you use new learning in your 
work? 
Copyright Reaktor 2014
THE WAY OUT? 
Copyright Reaktor 2014
What makes us Big? 
Large organization or 
project 
None of these are Laws of Nature. 
None of these are imposed on you. 
Fear of 
transparency 
Copyright Reaktor 2014 
“We need lot of 
different competences” 
“Relative overhead is 
smaller” 
Complex 
systems 
Separating action, 
feedback, knowledge and 
decision making 
“Adding more people 
will speed us up” 
Big projects need lot 
of people need big 
projects need … 
Silos in 
organization 
(Conways’s Law) 
Lot of unfinished 
work (WIP) 
Belief in Economies 
of Scale 
Failure 
Demand 
Short-term 
(Project) thinking 
These are the results of thinking. 
And we can get rid of these if we 
want.
Putting things in perspective 
• Up to 80% of work in organization is Failure 
Demand 
– What if you could reduce it, just a little bit? 
• Significant amount of work in project is 
caused by large amount of WIP 
– What if that improves as well? 
• Keep in mind the pear-shape organization and 
super-linear cost of scaling… 
Copyright Reaktor 2014
Copyright Reaktor 2014 
Size 
Cost of 
overhead 
Sublinear = Scales well 
Reducing project size by 
X% decreases costs by a 
lot more than X% 
X%
Copyright Reaktor 2014 
But hey, … 
• “You are overreacting. We all know 
large scale may not be the best 
solution. But it is usually 
unavoidable. And it works”
It is not perfect but it works 
If it works, don’t fix it 
- American Car manufacturers, 1970s 
Copyright Reaktor 2014
Sami’s Test #3 
• OK, let’s assume you’ve done everything to 
limit WIP, remove failure demand and reduce 
complexity 
• Still your project is Large(-ish) .. At least 3x 
bigger than “by-the-book” Agile project 
• Doing things in large scale is the only option. 
And you want to do it Agile. 
• Have you done a very successful small end-to-end 
Agile project before attempting a large 
scale Agile project? 
Copyright Reaktor 2014
SCRUM AT LARGE SCALE 
Copyright Reaktor 2014
What is missing from 
this picture? 
I can not see the 
customer here.. 
Copyright Reaktor 2014
What is missing from 
this statement? 
What if the demand 
comes from end user? 
What if we are 
creating a service? 
Copyright Reaktor 2014
Asking the right question 
• “How can I make Scrum work in my 
organization and my projects” 
– Coaching, Teaching, Inspect and Adapt 
• “How can I fulfill value demand from 
customer using Scrum” 
– Coaching, Teaching, Inspect & Adapt, … 
– Study and understand demand 
– Design and manage work against Value 
Demand! 
Copyright Reaktor 2014
Forgetting customer 
• Forgetting customer may lead to tunnel 
vision 
– Creating backlogs for teams rather than for 
customer need 
– Having unnecessary dependencies between 
teams (and product owners) 
– Internal failure demand: synchronization, 
prioritization, waiting 
– Lack of purpose: Backlog represent “work” 
instead of “Customer need” 
Copyright Reaktor 2014
Copyright Reaktor 2014 
Customers, 
users 
Customers, 
users 
Demand 
Demand 
Value for 
customers 
and users 
Value for 
customers 
and users
BEYOND SCRUM: " 
SOLID FRAMEWORK" 
" 
HTTP://SOLID.REAKTOR.FI 
Copyright Reaktor 2014
• Three different levels and 
frames for thinking 
– Note: These boxes are not 
separate organizations 
• Purpose of Solid: Help 
organizations design and 
manage work so that 
value demand from 
customer is fulfilled 
• Solid helps organizations 
to find the right 
questions 
Copyright Reaktor 2014
Operational Level looks at value delivery 
flow in order to maximize the Return on 
Investment. 
Thinking frames 
• True Agility 
• Kanban, Scrum, XP 
Tactical Level aims to find the right products 
and services. It also provides tools to manage 
investment (project) portfolio. 
Thinking frames 
• Customer development & Lean startup 
• Data science 
Strategic Level provides understanding 
about markets and customer needs. It helps 
to design workflow and value delivery 
system. 
Thinking frames 
• Systems Thinking 
• Outside-in perspective 
Copyright Reaktor 2014
Summary 
• Attempts to do knowledge work in large 
scale are likely to fail 
– …or at least suboptimal way to create products 
and services 
• Main reasons for being large 
– Lot of parallel work-in-progress 
– Inability to see and remove failure demand 
– Fear of fast feedback and transparency 
• Large Scale is a System Condition 
• In order to change System Conditions, we 
need new thinking 
– We need to find better questions, not just good 
answers 
Copyright Reaktor 2014
solving the right problem? 
We are engineers. 
We are trained to 
solve problems. 
Copyright Reaktor 2014
Ways to deal with a problem 
Dissolution: redesign the system or its environment 
in such a way that it eliminates the problem or the 
conditions that caused it 
solution: discover or create behavior that yields the 
best, or approximately the best, possible outcome, one 
that "optimizes" the situation. 
Resolution: employ behavior previously used in 
similar situations, adapted if necessary, so as to obtain 
an outcome that is good enough. 
Absolution: ignore a problem and hope it will solve 
itself or go away of its own accord. 
http://results2match.com/ackoff-again-4-different-ways-of-solving-a-problem 
Copyright Reaktor 2014
Dissolution: redesign the system or its environment 
in such a way that it eliminates the problem or the 
conditions that caused it 
Copyright Reaktor 2014

More Related Content

What's hot

Is there a best practice for an agile transformation? - No! - So what now?
Is there a best practice for an agile transformation? - No! - So what now?Is there a best practice for an agile transformation? - No! - So what now?
Is there a best practice for an agile transformation? - No! - So what now?
Hendrik Esser
 
Doing Architecture with Agile Teams IASA UK Summit 2013
Doing Architecture with Agile Teams IASA UK Summit 2013Doing Architecture with Agile Teams IASA UK Summit 2013
Doing Architecture with Agile Teams IASA UK Summit 2013
Chris F Carroll
 
Enterprise Architecture: Part II - Actualizing the Practice
Enterprise Architecture: Part II - Actualizing the PracticeEnterprise Architecture: Part II - Actualizing the Practice
Enterprise Architecture: Part II - Actualizing the Practice
Fru Louis
 

What's hot (20)

Artificial Intelligence (AI) & The Future of Employee Service
Artificial Intelligence (AI) & The Future of Employee ServiceArtificial Intelligence (AI) & The Future of Employee Service
Artificial Intelligence (AI) & The Future of Employee Service
 
Is there a best practice for an agile transformation? - No! - So what now?
Is there a best practice for an agile transformation? - No! - So what now?Is there a best practice for an agile transformation? - No! - So what now?
Is there a best practice for an agile transformation? - No! - So what now?
 
Crafting digital experiences with agile and design by James Hayes
Crafting digital experiences with agile and design by James HayesCrafting digital experiences with agile and design by James Hayes
Crafting digital experiences with agile and design by James Hayes
 
From SLAs to XLAs | Shift to pro-active service delivery
From SLAs to XLAs | Shift to pro-active service deliveryFrom SLAs to XLAs | Shift to pro-active service delivery
From SLAs to XLAs | Shift to pro-active service delivery
 
How to improve Customer and Employee Experience with IT Service Management
How to improve Customer and Employee Experience with IT Service ManagementHow to improve Customer and Employee Experience with IT Service Management
How to improve Customer and Employee Experience with IT Service Management
 
Mapping Your Journey to ITIL Island
Mapping Your Journey to ITIL IslandMapping Your Journey to ITIL Island
Mapping Your Journey to ITIL Island
 
Continuous Delivery and Continuous Agile by Andy Singleton - Agile Maine Day...
Continuous Delivery and Continuous Agile by Andy Singleton - Agile Maine Day...Continuous Delivery and Continuous Agile by Andy Singleton - Agile Maine Day...
Continuous Delivery and Continuous Agile by Andy Singleton - Agile Maine Day...
 
Agile Maine Meeting - Challenges and options in guiding agile adoptions
Agile Maine Meeting - Challenges and options in guiding agile adoptions Agile Maine Meeting - Challenges and options in guiding agile adoptions
Agile Maine Meeting - Challenges and options in guiding agile adoptions
 
Doing Architecture with Agile Teams IASA UK Summit 2013
Doing Architecture with Agile Teams IASA UK Summit 2013Doing Architecture with Agile Teams IASA UK Summit 2013
Doing Architecture with Agile Teams IASA UK Summit 2013
 
Agile-DevOps-Business-agility
Agile-DevOps-Business-agilityAgile-DevOps-Business-agility
Agile-DevOps-Business-agility
 
Agile Adoption in IT Services - Evolution over Revolution
Agile Adoption in IT Services - Evolution over RevolutionAgile Adoption in IT Services - Evolution over Revolution
Agile Adoption in IT Services - Evolution over Revolution
 
Lean Business Analysis and UX Runway - Natalie Warnert
Lean Business Analysis and UX Runway - Natalie WarnertLean Business Analysis and UX Runway - Natalie Warnert
Lean Business Analysis and UX Runway - Natalie Warnert
 
Who needs EA… when we have DevOps?
Who needs EA… when we have DevOps?Who needs EA… when we have DevOps?
Who needs EA… when we have DevOps?
 
Enterprise Architecture: Part II - Actualizing the Practice
Enterprise Architecture: Part II - Actualizing the PracticeEnterprise Architecture: Part II - Actualizing the Practice
Enterprise Architecture: Part II - Actualizing the Practice
 
Richard Oliver: Tested, Ready, and Able
Richard Oliver: Tested, Ready, and AbleRichard Oliver: Tested, Ready, and Able
Richard Oliver: Tested, Ready, and Able
 
Rethinking Site Reliability Engineering for ITSM - SDI virtual event "New Way...
Rethinking Site Reliability Engineering for ITSM - SDI virtual event "New Way...Rethinking Site Reliability Engineering for ITSM - SDI virtual event "New Way...
Rethinking Site Reliability Engineering for ITSM - SDI virtual event "New Way...
 
ITIL® 4 HVIT - High Velocity IT
ITIL® 4 HVIT - High Velocity ITITIL® 4 HVIT - High Velocity IT
ITIL® 4 HVIT - High Velocity IT
 
Scrum Bangalore 16th Meetup - March 5, 2016 - Replicating Architectural Scali...
Scrum Bangalore 16th Meetup - March 5, 2016 - Replicating Architectural Scali...Scrum Bangalore 16th Meetup - March 5, 2016 - Replicating Architectural Scali...
Scrum Bangalore 16th Meetup - March 5, 2016 - Replicating Architectural Scali...
 
Understanding Metrics – What to Measure, and Why - John Custy
Understanding Metrics – What to Measure, and Why - John CustyUnderstanding Metrics – What to Measure, and Why - John Custy
Understanding Metrics – What to Measure, and Why - John Custy
 
Adding Value with Change Management
Adding Value with Change ManagementAdding Value with Change Management
Adding Value with Change Management
 

Similar to Case Against Scaling (Scrum Gathering Berlin)

Galorath - IT Data Collection, Analysis and Benchmarking: From Processes and...
Galorath -  IT Data Collection, Analysis and Benchmarking: From Processes and...Galorath -  IT Data Collection, Analysis and Benchmarking: From Processes and...
Galorath - IT Data Collection, Analysis and Benchmarking: From Processes and...
International Software Benchmarking Standards Group (ISBSG)
 
Innovation Tools applied to Problem Solving.pptx
Innovation Tools applied to Problem Solving.pptxInnovation Tools applied to Problem Solving.pptx
Innovation Tools applied to Problem Solving.pptx
techdirector1
 

Similar to Case Against Scaling (Scrum Gathering Berlin) (20)

Professional Project Manager Should Be Proficient in Agile
Professional Project Manager Should Be Proficient in AgileProfessional Project Manager Should Be Proficient in Agile
Professional Project Manager Should Be Proficient in Agile
 
Shariyaz Abdeen Software / Technical Project Management Presentation
Shariyaz Abdeen   Software / Technical Project Management PresentationShariyaz Abdeen   Software / Technical Project Management Presentation
Shariyaz Abdeen Software / Technical Project Management Presentation
 
The Lean Enterprise
The Lean EnterpriseThe Lean Enterprise
The Lean Enterprise
 
Alternatives to scaling your agile process: valuing outcomes over output
Alternatives to scaling your agile process: valuing outcomes over outputAlternatives to scaling your agile process: valuing outcomes over output
Alternatives to scaling your agile process: valuing outcomes over output
 
Alternatives to scaling your agile process: valuing outcomes over output
Alternatives to scaling your agile process: valuing outcomes over outputAlternatives to scaling your agile process: valuing outcomes over output
Alternatives to scaling your agile process: valuing outcomes over output
 
Galorath - IT Data Collection, Analysis and Benchmarking: From Processes and...
Galorath -  IT Data Collection, Analysis and Benchmarking: From Processes and...Galorath -  IT Data Collection, Analysis and Benchmarking: From Processes and...
Galorath - IT Data Collection, Analysis and Benchmarking: From Processes and...
 
Clarisoft Software Development Process (Lunch & Learn Presentation)
Clarisoft Software Development Process (Lunch & Learn Presentation)Clarisoft Software Development Process (Lunch & Learn Presentation)
Clarisoft Software Development Process (Lunch & Learn Presentation)
 
The 12 Agile Principles
The 12 Agile PrinciplesThe 12 Agile Principles
The 12 Agile Principles
 
Requirements
RequirementsRequirements
Requirements
 
Adopting innovation
Adopting innovationAdopting innovation
Adopting innovation
 
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
 
Leveraging Cloud Technologies to Boost Your Start Up
Leveraging Cloud Technologies to Boost Your Start UpLeveraging Cloud Technologies to Boost Your Start Up
Leveraging Cloud Technologies to Boost Your Start Up
 
A Holistic View of Complex Systems and Organizational Change
A Holistic View of Complex Systems and Organizational ChangeA Holistic View of Complex Systems and Organizational Change
A Holistic View of Complex Systems and Organizational Change
 
Agile And Your Business V2
Agile And Your Business V2Agile And Your Business V2
Agile And Your Business V2
 
Innovation Tools applied to Problem Solving.pptx
Innovation Tools applied to Problem Solving.pptxInnovation Tools applied to Problem Solving.pptx
Innovation Tools applied to Problem Solving.pptx
 
Introduction to Recipes for Agile Governance in the Enterprise (RAGE)
Introduction to Recipes for Agile Governance in the Enterprise (RAGE)Introduction to Recipes for Agile Governance in the Enterprise (RAGE)
Introduction to Recipes for Agile Governance in the Enterprise (RAGE)
 
Agile
AgileAgile
Agile
 
Rethinking Your DevOps Strategy
Rethinking Your DevOps StrategyRethinking Your DevOps Strategy
Rethinking Your DevOps Strategy
 
MX: Managing Experience | Day 2 - Designing Delivery: A Unified Approach to D...
MX: Managing Experience | Day 2 - Designing Delivery: A Unified Approach to D...MX: Managing Experience | Day 2 - Designing Delivery: A Unified Approach to D...
MX: Managing Experience | Day 2 - Designing Delivery: A Unified Approach to D...
 
#NoProjects - Beyond Projects
#NoProjects - Beyond Projects#NoProjects - Beyond Projects
#NoProjects - Beyond Projects
 

Recently uploaded

Recently uploaded (12)

Databricks Machine Learning Associate Exam Dumps 2024.pdf
Databricks Machine Learning Associate Exam Dumps 2024.pdfDatabricks Machine Learning Associate Exam Dumps 2024.pdf
Databricks Machine Learning Associate Exam Dumps 2024.pdf
 
Microsoft Fabric Analytics Engineer (DP-600) Exam Dumps 2024.pdf
Microsoft Fabric Analytics Engineer (DP-600) Exam Dumps 2024.pdfMicrosoft Fabric Analytics Engineer (DP-600) Exam Dumps 2024.pdf
Microsoft Fabric Analytics Engineer (DP-600) Exam Dumps 2024.pdf
 
ACM CHT Best Inspection Practices Kinben Innovation MIC Slideshare.pdf
ACM CHT Best Inspection Practices Kinben Innovation MIC Slideshare.pdfACM CHT Best Inspection Practices Kinben Innovation MIC Slideshare.pdf
ACM CHT Best Inspection Practices Kinben Innovation MIC Slideshare.pdf
 
TSM unit 5 Toxicokinetics seminar by Ansari Aashif Raza.pptx
TSM unit 5 Toxicokinetics seminar by  Ansari Aashif Raza.pptxTSM unit 5 Toxicokinetics seminar by  Ansari Aashif Raza.pptx
TSM unit 5 Toxicokinetics seminar by Ansari Aashif Raza.pptx
 
"I hear you": Moving beyond empathy in UXR
"I hear you": Moving beyond empathy in UXR"I hear you": Moving beyond empathy in UXR
"I hear you": Moving beyond empathy in UXR
 
DAY 0 8 A Revelation 05-19-2024 PPT.pptx
DAY 0 8 A Revelation 05-19-2024 PPT.pptxDAY 0 8 A Revelation 05-19-2024 PPT.pptx
DAY 0 8 A Revelation 05-19-2024 PPT.pptx
 
The Concession of Asaba International Airport: Balancing Politics and Policy ...
The Concession of Asaba International Airport: Balancing Politics and Policy ...The Concession of Asaba International Airport: Balancing Politics and Policy ...
The Concession of Asaba International Airport: Balancing Politics and Policy ...
 
2024 mega trends for the digital workplace - FINAL.pdf
2024 mega trends for the digital workplace - FINAL.pdf2024 mega trends for the digital workplace - FINAL.pdf
2024 mega trends for the digital workplace - FINAL.pdf
 
2024-05-15-Surat Meetup-Hyperautomation.pptx
2024-05-15-Surat Meetup-Hyperautomation.pptx2024-05-15-Surat Meetup-Hyperautomation.pptx
2024-05-15-Surat Meetup-Hyperautomation.pptx
 
STM valmiusseminaari 26-04-2024 PUUMALAINEN Ajankohtaista kansainvälisestä yh...
STM valmiusseminaari 26-04-2024 PUUMALAINEN Ajankohtaista kansainvälisestä yh...STM valmiusseminaari 26-04-2024 PUUMALAINEN Ajankohtaista kansainvälisestä yh...
STM valmiusseminaari 26-04-2024 PUUMALAINEN Ajankohtaista kansainvälisestä yh...
 
SaaStr Workshop Wednesday with CEO of Guru
SaaStr Workshop Wednesday with CEO of GuruSaaStr Workshop Wednesday with CEO of Guru
SaaStr Workshop Wednesday with CEO of Guru
 
Using AI to boost productivity for developers
Using AI to boost productivity for developersUsing AI to boost productivity for developers
Using AI to boost productivity for developers
 

Case Against Scaling (Scrum Gathering Berlin)

  • 1. Copyright Reaktor 2013 Luottamuksellinen
  • 2. Case Against Scaling Back to basics with your enterprise transformation Sami Lilja Reaktor Twitter: @samililja Copyright Reaktor 2014
  • 3. How big is big? Pick a piece of paper and a pen. Think about software / IT projects you have been working on. Based on your experience fill in the blank: A project is a big project when it has more than ___ people working on it. Copyright Reaktor 2014
  • 5. Solving the wrong problem Source: http://www.medscape.com/viewarticle/806573 Copyright Reaktor 2014
  • 6. Finding the right question The way we formulate the problem, limits our space of potential solutions Meetings take too much time People lack motivation Work environment, the system, Copyright Reaktor 2014 vs. We have too many meetings vs. decreases motivation Coordinating between parallel projects is not effective vs. We have too many parallel projects
  • 7. Scaling Agile? The problem is not that we lack ways to scale Agile. The problem is not that we fail with Agile in large organizations. The problem is that we are large. Size does matter. Copyright Reaktor 2014
  • 8. Copyright Reaktor 2014 Economy of Scale Scalability Size Cost of overhead Sublinear = Scales well Highly repeatable “How many?”
  • 11. When doing knowledge work in Large Scale, the key question is not “How?” – it is “Why?” Copyright Reaktor 2014
  • 13. Organizations getting bigger Copyright Reaktor 2014
  • 15. But, hey.. • Do you say companies should not grow? – No, I am not saying that • Do you say companies should only do small things? – No, I am not saying that – But.. small batches are better than large batches • Are you against the frameworks that promise Agility in large-scale? – No, I am against doing large-scale development – However, the frameworks take “large scale” as given and do very little to reduce that Copyright Reaktor 2014
  • 16. What makes us Big? Large organization or project Fear of transparency Copyright Reaktor 2014 “We need lot of different competences” “Relative overhead is smaller” Complex systems Separating action, feedback, knowledge and decision making “Adding more people will speed us up” Big projects need lot of people need big projects need … Silos in organization (Conways’s Law) Lot of unfinished work (WIP) Belief in Economies of Scale Failure Demand Short-term (Project) thinking
  • 17. The root of all Evil I Work-in-Progress Copyright Reaktor 2014
  • 18. Work-in-Progress • How many things your organization is currently working on? • How easy it is to get dedicated people / team to deliver customer value? Copyright Reaktor 2014
  • 19. Hey, but.. • Work-in-Progress and Little’s Law are about time through system • What does this have to do with project size? • Large amount of WIP helps to create unnecessarily large projects – When time-through-system gets long, some organizations add more people to gain speed – People are split to work on many parallel projects. Getting X people worth of work takes 10x more people Copyright Reaktor 2014
  • 20. Work in Progress • Most organizations have too many things going on at one time, because – People are costly: Fear of <100% resource utilization – It is easier to start things than complete things – Large projects require lot of people require large projects require lot of people.. Copyright Reaktor 2014
  • 21. Work in Progress • We underestimate the overhead that Work-in-Progress causes • In reality, large WIP causes huge and costly problems Copyright Reaktor 2014 – Delays • time-through-system = Work-In-Progress / Velocity – Queues and synchronization problems – Internal Failure Demand • Meetings, coordination effort, waiting, re-work, …
  • 22. Sami’s Test #1 • Think about predictable demand that comes to your organization – Support request, creating a new service, ramp-up of a project, fixing a bug, … • What would be the fastest completion time for such work in your system, if you could do anything to make it happen? • If your current performance is lower, why is that? What causes delays? Copyright Reaktor 2014
  • 23. Quick review • Pick a person near you, form pairs or triplets • In your small group, have a 2 minutes discussion about – What topics have been covered so far? – How do you feel about these topics? – What concepts have been significant to you? – How could you use these in your work? Copyright Reaktor 2014
  • 24. The root of all Evil II Failure Demand Copyright Reaktor 2014
  • 25. Value demand Adds value from customer point of view. Something customers are willing to pay for. This type of demand we want. Copyright Reaktor 2014 Failure demand Failure to do what customer needs Bad quality, wrong product or service, delay. No product or service. Missing either what or how customer wants Can account up to 80% of work
  • 26. All demand is considered work Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/ Copyright Reaktor 2014
  • 27. Failure demand: Not only bugs NEW IT SYSTEM! Copyright Reaktor 2014 Value for user Fail CU ST O M E R S UP P O R T “PRESS 1 IF YOU CALL ABOUT..” “PRESS 2 IF YOU CALL ABOUT..” “PRESS 3 IF YOU CALL ABOUT..”
  • 28. Internal Failure demand Do we need this process? What thinking created this? Copyright Reaktor 2014
  • 29. Hidden Failure demand Copyright Reaktor 2014 Value Demand (Project work) Failure Demand (Bug fixes etc) Other The Plan Value Demand (Project work) Failure Demand (Bug fixes, meetings, waiting, coordination) Other The reality
  • 30. Copyright Reaktor 2014 Dysfunction Something in the design and management of work that is causing problems.
  • 31. Institutionalized Dysfunction Problem that is resolved by adding processes or management actions and then focusing on actions rather than the original problem. Copyright Reaktor 2014
  • 32. Institutionalized Dysfunction and Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Copyright Reaktor 2014 Slippery slope to institutionalized dysfunction
  • 33. Sami’s Test #2 • Assume you could freely choose the smallest possible number of people to implement the product or service. • How large would that group be? • If such group is significantly smaller than your current development project, why is that? Copyright Reaktor 2014
  • 34. Quick review • Pick a person near you, form pairs or triplets • In your small group, have a 2 minutes discussion about – What topics and issues have been covered so far? – How do you feel about these topics? – What topics or concepts have been significant to you? – How could you use new learning in your work? Copyright Reaktor 2014
  • 35. THE WAY OUT? Copyright Reaktor 2014
  • 36. What makes us Big? Large organization or project None of these are Laws of Nature. None of these are imposed on you. Fear of transparency Copyright Reaktor 2014 “We need lot of different competences” “Relative overhead is smaller” Complex systems Separating action, feedback, knowledge and decision making “Adding more people will speed us up” Big projects need lot of people need big projects need … Silos in organization (Conways’s Law) Lot of unfinished work (WIP) Belief in Economies of Scale Failure Demand Short-term (Project) thinking These are the results of thinking. And we can get rid of these if we want.
  • 37. Putting things in perspective • Up to 80% of work in organization is Failure Demand – What if you could reduce it, just a little bit? • Significant amount of work in project is caused by large amount of WIP – What if that improves as well? • Keep in mind the pear-shape organization and super-linear cost of scaling… Copyright Reaktor 2014
  • 38. Copyright Reaktor 2014 Size Cost of overhead Sublinear = Scales well Reducing project size by X% decreases costs by a lot more than X% X%
  • 39. Copyright Reaktor 2014 But hey, … • “You are overreacting. We all know large scale may not be the best solution. But it is usually unavoidable. And it works”
  • 40. It is not perfect but it works If it works, don’t fix it - American Car manufacturers, 1970s Copyright Reaktor 2014
  • 41. Sami’s Test #3 • OK, let’s assume you’ve done everything to limit WIP, remove failure demand and reduce complexity • Still your project is Large(-ish) .. At least 3x bigger than “by-the-book” Agile project • Doing things in large scale is the only option. And you want to do it Agile. • Have you done a very successful small end-to-end Agile project before attempting a large scale Agile project? Copyright Reaktor 2014
  • 42. SCRUM AT LARGE SCALE Copyright Reaktor 2014
  • 43. What is missing from this picture? I can not see the customer here.. Copyright Reaktor 2014
  • 44. What is missing from this statement? What if the demand comes from end user? What if we are creating a service? Copyright Reaktor 2014
  • 45. Asking the right question • “How can I make Scrum work in my organization and my projects” – Coaching, Teaching, Inspect and Adapt • “How can I fulfill value demand from customer using Scrum” – Coaching, Teaching, Inspect & Adapt, … – Study and understand demand – Design and manage work against Value Demand! Copyright Reaktor 2014
  • 46. Forgetting customer • Forgetting customer may lead to tunnel vision – Creating backlogs for teams rather than for customer need – Having unnecessary dependencies between teams (and product owners) – Internal failure demand: synchronization, prioritization, waiting – Lack of purpose: Backlog represent “work” instead of “Customer need” Copyright Reaktor 2014
  • 47. Copyright Reaktor 2014 Customers, users Customers, users Demand Demand Value for customers and users Value for customers and users
  • 48. BEYOND SCRUM: " SOLID FRAMEWORK" " HTTP://SOLID.REAKTOR.FI Copyright Reaktor 2014
  • 49. • Three different levels and frames for thinking – Note: These boxes are not separate organizations • Purpose of Solid: Help organizations design and manage work so that value demand from customer is fulfilled • Solid helps organizations to find the right questions Copyright Reaktor 2014
  • 50. Operational Level looks at value delivery flow in order to maximize the Return on Investment. Thinking frames • True Agility • Kanban, Scrum, XP Tactical Level aims to find the right products and services. It also provides tools to manage investment (project) portfolio. Thinking frames • Customer development & Lean startup • Data science Strategic Level provides understanding about markets and customer needs. It helps to design workflow and value delivery system. Thinking frames • Systems Thinking • Outside-in perspective Copyright Reaktor 2014
  • 51. Summary • Attempts to do knowledge work in large scale are likely to fail – …or at least suboptimal way to create products and services • Main reasons for being large – Lot of parallel work-in-progress – Inability to see and remove failure demand – Fear of fast feedback and transparency • Large Scale is a System Condition • In order to change System Conditions, we need new thinking – We need to find better questions, not just good answers Copyright Reaktor 2014
  • 52. solving the right problem? We are engineers. We are trained to solve problems. Copyright Reaktor 2014
  • 53. Ways to deal with a problem Dissolution: redesign the system or its environment in such a way that it eliminates the problem or the conditions that caused it solution: discover or create behavior that yields the best, or approximately the best, possible outcome, one that "optimizes" the situation. Resolution: employ behavior previously used in similar situations, adapted if necessary, so as to obtain an outcome that is good enough. Absolution: ignore a problem and hope it will solve itself or go away of its own accord. http://results2match.com/ackoff-again-4-different-ways-of-solving-a-problem Copyright Reaktor 2014
  • 54. Dissolution: redesign the system or its environment in such a way that it eliminates the problem or the conditions that caused it Copyright Reaktor 2014