alternatives to scaling your agile process: valuing outcomes over output

Alternatives to scaling your agile process:valuing outcomes over output

Edwin DandoAssurity

Your pic

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,

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

Agile has made a major contribution to this

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

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/

http://blog.scrum.org/maximizing-scrum/


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?

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?

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

So lets test this hypothesis: 1 + 2 + 3 + … + n = ½n(n+1)

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?

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.

Feed and water them regularlyHelp remove things that stop them succeedingAnd our garden grows and rewards us

But does the same thinking apply on a large scale?

Value is very, very different from volume

Outcomes are very different to output

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/



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

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

Why would you want to scale this? Fix these first

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.”

Focus on getting more out of what you already have

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

Why would you want to scale this?

Used with permission – Scrum.org

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-creatorMaybe we would want to

fix this before we scale?

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

Incremental scaling with evidence

Single team starts doing ScrumThey identify things that need improvement and capture these in an organisational improvement backlog

Review

Retrospective

Organisational Agility Groupselects items

and implements transparently

Evidence based

planning

Measurebusiness 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 collect-ively,

using evidence

Change Increment

Is revenue improving?

OAG makes next round of decisions on evidence:

Is staff morale better?Are we innovating faster?Are customers happier? Is quality improving?

Are we more agile?

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?

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 timesThe Economist Intelligence Unit

Evidence of business outcomes (not agile outputs)

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

There are many ways to “scale” before you “scale Scrum”

*Source: Forrester, October 2010 “2011 IT Budget Planning Guide For

CIOs”)

• 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.



CIOs”)

• 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.



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

Scaling is a people problem, not a process problem

.

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 Programshttp://bit.ly/1l7EcjZ

http://bit.ly/1l7EcjZ


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.




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




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.




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

If the definition of insanity is “doing the same thing and expecting different results”,

then what is the definition of insanity at scale?

Thanks for listening…Edwin DandoAssurity

@edwindando

agileforeveryone.com

[email protected]

linkedin.com/in/edwindando/

alternatives to scaling your agile process: valuing outcomes over output

Business

agile process

changeyet agile

business contexts agile

scaling dilemma

scale approach

new values

large scale

core values