This document discusses alternatives to simply scaling up agile processes. It argues that organizations should focus on continuously improving outcomes rather than just increasing output or volume. Some key points made include: - Agile is about mindset and values, not processes, and scaling up risks losing those. Organizations should fix weaknesses before scaling. - True scaling happens incrementally based on measuring business impacts, not just adopting more processes. Teams should regularly inspect and adapt. - There are many ways to improve value, quality and productivity within existing teams, like improving technical practices and skills, before considering larger scale changes. - Scaling is primarily a "people problem" - organizations should focus on building networks between self-organ

1. Alternatives to scaling your agile process:
valuing outcomes over output
Edwin Dando
Assurity
Your pic

3. There is a management revolution underway
“Tomorrow’s business imperatives
lie outside the performance
envelope of today’s bureaucracy-infused
management practices…
Equipping organizations to tackle
the future would require a
management revolution no less
momentous than the one that
spawned modern industry.”
Gary Hamel - the landmark HBR
article Moon Shots For Management,

4. What is changing?
To focusing on customer value
To exploiting variability for competitive advantage
To providing a vision to a self-organised, cross-functional
team and getting out of the way.
To measuring results on outcomes
To regular delivery of customer value via
economies of flow
To focus on building wonderful workplaces
and strong employee engagement
To a strategy that is about deep customer
engagement, rapid manoeuvrability, fast
feedback and regular pivots
From focusing on maximizing shareholder $
From avoiding variability
From telling employees what to do
From controlling performance through rules,
roles, plans and reports
From efficiency through economies of scale
From focus on lowering costs through offshoring
From a “coping with competition” strategy
through regulation and monopoly behaviour

5. Agile has made a major contribution to this

6. Large scale and agile – a clash of cultures?
• Agile is a mind-set and set of values, not a process
• Agility is earned, not installed
• For a long time many people have worked hard to help shift
thinking, adopt new values and change…
Yet…
• Agile is now mainstream
• Markets forcing businesses to become more responsive
• Insatiable demand to “be agile” – especially from large
companies, often who have come to the game late
And so,
• Market responded with “buy and install” agile @ scale
• Approach viewed as disrespectful to core values

7. The scaling dilemma
• The desire ‘to scale’ is a reflection of the demand to develop more
software, faster (rather than better outcomes with same/less effort).
• Existing internal structures make it difficult to increase capacity
• So we add new structures to manage this and increase our efforts.
• But investment to achieve more goes mostly to the additional
structures, and is often much higher than the gains expected.
• We enter a vicious cycle.
Gunther Verheyen - Maximizing Scrum, http://blog.scrum.org/maximizing-scrum/

8. In an organisation near you…
• An organization starts adopting Scrum
• Soon they ask ‘how do we scale?’
• Very few stop and investigate this desire
prior to exploring scaling.
• What do we hope to obtain from scaling?
• How does this fit with our strategy?
• What are the risks?
• How will we know scaling is helping us?
• How will we measure this?

9. Humans love simple assumptions
The logic of induction teaches us that
• If n is true (it works for one)
• and n+1 is true (it works for the next)
• then n must always be true….. Right?
So lets test this hypothesis: 1 + 2 + 3 + … + n = ½n(n+1)
1 + 2 + 3 = ½ x 3 x 4 = 6
1 + 2 + 3 + 4 = ½ x 4 x 5 = 10
1 + 2 + 3 + 4 + 5 + 6 + …. + 7823
= ½ x 7823 x 7824
= 30603576

10. And we carry that logic into business contexts
• Agile works for one team and gives us
great benefits
• and it works for two teams and gives
us more great benefits
• Therefore it must work for many
teams and make us world beaters,
right?

11. Add to this the fact that knowledge work is highly creative
• Good Agile managers create environments where
people can flourish and grow.
• Much like the role of the gardener…
Get your hands dirty and
create an environment where
people can flourish.
FHeeelpd And our raenmd garden owvaet ethr itnhgesm grows th raetg and
sutloaprl y
rewards them succeeding
us

12. But does the same thinking apply on a large scale?
Value is very, very different from volume
Outcomes are very different to output

13. Shoe-horning agile
• Over time, many organizations have grown very
complicated with interdependent internal structures.
• The implementation of Scrum is expected to fit into
these existing structures.
• Within these structures, ‘scaling’ is synonymous to
increasing volume and quantity, to larger numbers.
• The expectation is that Scrum must be expanded with
additional processes, roles, phases, etc.
• At which point we have missed the point
• The entire point of Scrum is to highlight your
weaknesses – so you can fix them
Gunther Verheyen - Maximizing Scrum, http://blog.scrum.org/maximizing-scrum/

14. What sort of weaknesses?
On the whole, [our survey results are] not exactly a
reassuring picture for those who depend on the software they build.
Develop Landscape - Forrester Research 2013

15. Some clear areas for attention
• Basics of Agile – we’ve only adopted the basics
“Organizations claim that they’ve ‘gone Agile,’ but when one probes on specific Agile practices,
the reality is that they’ve only adopted a few basic ones and stalled out in the scaling process.“
• Quality software development
“Only 12% of the developers we surveyed spend more than an hour a day writing test cases.
Developers spend more time on email than writing tests”
Develop Landscape - Forrester Research 2013

16. Why would you want
to scale this? Fix
these first

17. Some clear areas for attention
• Small Teams
“Developers who work in small, collocated teams understand the applications they build fare
better. Most development teams are not collocated. Our takeaway: Organizations are trading
understanding and efficiency for an efficient cost structure”.
“We see the inverse relationship between development team size and the level of project
understanding/transparency. Our recommendation? Lose the industrial metaphor forever and
think more along the lines of a talent management from or a Broadway production.”

18. Focus on getting more out of what you already have
Why would you want to
scale this?
Fix these first.

19. Why would you want to scale this?
Used with permission – Scrum.org

20. No evidence
“What is the business impact of agile?
The reality is, we have no idea. We have no real evidence.
If we start measuring by evidentiary outcomes, then we will have firm grounding when we assess its
value to the organization, and the value of our investments and initiatives.”
Ken Schwaber, Scrum co-creator
Maybe we would want to fix
this before we scale?

21. Scaling, finally
So, lets assume we get good at developing software and get to the
point of “scaling up”, how do we scale?
1. Start with reality – there is no recipe, only patterns
2. Start small and iterate.
a) Try some of the known scaling patterns
b) Inspect how it has worked in your context. Hint – you
should find a way to measure the business impact.
c) Adapt as required.
d) Repeat

22. Incremental scaling
with evidence
Single team starts doing Scrum
They identify things that need improvement
and capture these in an organisational
improvement backlog
Review
Retrospective
OAG makes next round of
decisions on evidence:
Are customers happier? Is quality improving?
Are we innovating faster?
Is staff morale better?
Are we more agile?
Organisational
Agility Group
selects items and
implements
transparently
Evidence
based
planning
Measure
business
impact
Organisational learning
Organisational
Improvement
backlog
How can we improve quality?
Should we start another team? Are we working
well together?
Do we have interdependency problems?
What does the evidence tell us?
How’s our culture?
Teams inspect and adapt collectively,
using evidence
Change
Increment
Is revenue improving?
May decide to add
another team…
Change
Owner
What is true for us?
Meets regularly
to track progress
and re-plan
Are we getting to done every iteration?

23. Evidence
• Over 85% of senior international executives* say organisational agility is critical to success.
• Yet few can demonstrate tangible business benefits to their boards
• This is a tragedy, given the investment involved in agile.
Even more important, how do we
• know the risk and disruption involved in this agile transformation is working?
• continually tweak the approach to our organisation’s unique needs?
Unfortunately, most organisations don't. They measure output, not outcomes.
And then they want to scale...
*Organisational agility: How business can survive and thrive
in turbulent times
The Economist Intelligence Unit

24. Evidence of business outcomes (not agile outputs)

25. Focus on evidence based business decision making
• How has the ability to release fortnightly helped?
• Are our staff happier doing agile?
• Are we seeing value from our technical debt repayment?
• Has our investment in test automation improved quality and
customer satisfaction?
• Maybe, if we are getting these right, then we should consider
scaling

26. There are many ways to “scale” before you “scale Scrum”
• Quality software development
– a good developer can be 20 times more productive than an average one. Grow them.
– pair programming - instant feedback loops, higher quality.
– continuous delivery – regular delivery of value and regular product learning cycles
• Technical debt
– prevents agility and is extremely expensive. Slow down, write good code, write less code - only on
features customers value.
– only 29% developers time spent working on value. 53% spent on complexity/technical debt*. Your
teams want to fix this. Given them the opportunity and double/triple productivity.
*Source: Forrester, October 2010 “2011 IT
Budget Planning Guide For CIOs”)

27. There are many ways to “scale” before you “scale Scrum”
• Value
– ~ 65% of features aren’t valued by customers. Use validated learning to find out what they don’t
value and stop delivering it.
– Deliver products that make a market impact, not just ship more features… Impact Mapping
• Team
– Developers are intrinsically motivated & creative*. Create environments in which they can flourish.
– #1 reason for software project failure is a lack of shared understanding. Specification by Example
helps resolve this.
– Agile isn’t just about Scrum Masters and Product Owners. Testers, developers and analysts need
training too.
*Source: Forrester, October 2010 “2011 IT
Budget Planning Guide For CIOs”)

28. There are many ways to “scale” before you “scale Scrum”
*Source: Forrester, October 2010 “2011 IT
Budget Planning Guide For CIOs”)
• Evidence
– Measure and track the business impact of agile.
– Make evidence based decisions.
– If the evidence shows something isn't working, change it.
• Test automation
• Product Ownership
• Team behaviours & collaboration
• …
In other words, walk before you run

29. Scaling is a people problem, not a process problem
.

30. Thinking about the people – networks versus hierarchies
• Hierarchies can be an effective way to
organise, but they don’t tend to be an
effective way to communicate
• Typically, coordination responsibility likes
with individuals
• But when people are busy, they pass their
problems to the coordinator to pass to
someone who can fix it.
• Why? Because people are busy getting their
features to done. It’s human nature. We
push problems up a hierarchy for someone
else to remove if that’s how it’s supposed to
be.
Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs
http://bit.ly/1l7EcjZ

31. Networks
• Don’t have to have everyone interconnected
with everyone else – just some connected
individuals.
• Don’t need the Scrum Masters to do it.
• E.g. Bob and Alice have a question, they ask
each other. If that doesn’t resolve it they ask
someone else who might know (not
necessarily a manager).
• The question doesn’t go up the hierarchy.
It goes across the network.
Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs
http://bit.ly/1l7EcjZ

32. Communities of Practice help build networks and coordinate work
• Testers talking to other testers
• Developers talking to other developers
• Ability to solve common problems and
coordinate common activities
• Ability to inspect and adapt our common
work and approach
Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs
http://bit.ly/1l7EcjZ

33. Benefits of a network model
• Communication flows quickly through networks.
Puts the inherent rumour mill to work for you.
• Networks are connected by humans who are
more prone to connecting/communicating
• A network engages people in a way that
hierarchy does not
• A network decreases the transaction cost of just
about everything.
• No waiting on meetings to address problems,
issues, or risks. People on teams solve problems
when they have the problem.
• No need for a “master” or a “chief” to
intervene.
Joanna Rothman, Organizing an Agile Program: Networks for Managing Agile Programs
http://bit.ly/1l7EcjZ

34. In summary
• Use Scrum to highlight your weaknesses
• Systematically fix them
• Then consider scaling, if it makes sense
• If so, start small and iterate
• Measure the business impact of each change

35. If the definition of insanity is
“doing the same thing and expecting different results”,
then what is the definition of insanity at scale?

36. Thanks for listening…
Edwin Dando
Assurity
@edwindando
agileforeveryone.com
edwin.dando@assurity.co.nz
linkedin.com/in/edwindando/