Luottamuksellinen Copyright Reaktor 2013
Copyright Reaktor 2014
Case Against Scaling
Back to basics with your enterprise transformation
Sami Lilja Reaktor
Twitter: @samililja
Copyright Reaktor 2014
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.
How big is big?
Copyright Reaktor 2014
The Beef
Copyright Reaktor 2014
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
vs.
We have too many meetings
Coordinating between parallel projects is not effective
vs.
We have too many parallel projects
People lack motivation
vs.
Work environment, the system, decreases motivation
Copyright Reaktor 2014
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.
Scaling Agile?
Copyright Reaktor 2014
Economy of Scale
Scalability
Size
Co
st
of
over
head
Sublinear = Scales well
Highly repeatable “How many?”
Copyright Reaktor 2014
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
“We need lot of different competences”
“Relative overhead is smaller”
Complex systems
Separating action, feedback, knowledge and
decision making
Big projects need lot of people need big
projects need …
“Adding more people will speed us up”
Lot of unfinished work (WIP)
Silos in organization
(Conways’s Law)
Belief in Economies of Scale
Failure Demand
Short-term (Project) thinking
Copyright Reaktor 2014
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 – Delays
• time-through-system = Work-In-Progress / Velocity
– Queues and synchronization problems
– Internal Failure Demand • Meetings, coordination effort, waiting, re-work, …
Copyright Reaktor 2014
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.
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
Copyright Reaktor 2014
All demand is considered work
Source: http://www.limebridge.com.au/page/Learning_Centre/Cartoons/
Copyright Reaktor 2014
NE
W IT
SY
ST
EM
!
Failure demand: Not only bugs
Value for user
Fail
CUSTOMER SUPPORT
“PRESS 1 IF YOU CALL ABOUT..”
“PRESS 2 IF YOU CALL ABOUT..”
“PRESS 3 IF YOU CALL ABOUT..”
Copyright Reaktor 2014
Internal Failure demand
Do we need this process?
What thinking created this?
Copyright Reaktor 2014
Hidden Failure demand
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.
Copyright Reaktor 2014
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.
Slippery slope to institutionalized dysfunction
Copyright Reaktor 2014
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
Fear of transparency
“We need lot of different competences”
“Relative overhead is smaller”
Complex systems
Separating action, feedback, knowledge and
decision making
Big projects need lot of people need big
projects need …
“Adding more people will speed us up”
Lot of unfinished work (WIP)
Silos in organization
(Conways’s Law)
Belief in Economies of Scale
Failure Demand
Short-term (Project) thinking
None of these are Laws of Nature. None of these are imposed on you.
These are the results of thinking.
And we can get rid of these if we
want.
Copyright Reaktor 2014
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
Size
Co
st
of
over
head
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”
Copyright Reaktor 2014
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
Customers, users
Customers, users
Demand
Demand
Value for customers and users
Value for customers and users
Copyright Reaktor 2014
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
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
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
Operational Level looks at value delivery flow in order to maximize the Return on Investment.
Thinking frames
• True Agility
• Kanban, Scrum, XP
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
Absolution: ignore a problem and hope it will solve itself or go away of its own accord.
Resolution: employ behavior previously used in similar situations, adapted if necessary, so as to obtain an outcome that is good enough.
solution: discover or create behavior that yields the best, or approximately the best, possible outcome, one that "optimizes" the situation.
Dissolution: redesign the system or its environment in such a way that it eliminates the problem or the conditions that caused it
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
Dissolution: redesign the system or its environment in such a way that it eliminates the problem or the conditions that caused it
Top Related