why scaled agile frameworks exist and why you don't need them

neil_killickNeil Killick, 2017, All Rights Reserved

And why you don’t

need them

Why scaled agile frameworks exist


What are “scaled agile frameworks”?


Frameworks which enable the organisation and management of Agile Software Development

across multiple teams and/or products, programs, projects and technologies

— i.e. frameworks to enable Agile “at scale”


SAFe (Scaled Agile Framework)

Neil Killick, 2017, All Rights Reserved

LeSS (Large Scale Scrum) neil_killick


Nexus


Disciplined Agile Delivery


Scrum of Scrums neil_killick


Why do they exist?


They address three broad scenarios:

1. Business has one agile team, wants more

2. Business has many non-agile teams, wants “Agile”

3. Business has many agile teams, wants better results

Scenario 1

1 product (pipeline)

1 Agile team

Straightforward, works well

$$$$$$$$$$$$$$$$$$ neil_killick


Agile team

Business

Feature ideas

Customer


OK, now let’s SCALE!

$$$$$$$$$$$$$

$$$$$ neil_killick


Agile team 1

Business

Feature ideas

1 product (pipeline)

2 Agile teams

Much complexity added • decisions • team performance • coordination • prioritisation • autonomy/dependencies • technology

Customer

Agile team 2

neil_killick

Strategic project idea 3

$$$$$$$


$$$$$$$


$$$$$$$

Portfolio/PMO


$$$$$$$

$$$$$$$$$$$$$

$$$$$


Agile team 1Business

Feature ideas

Customer 1

Agile team 2

Customer 2

$$$$$$$$$$$$$

$$$$

Feature ideas

Agile team 3

Agile team 4


Why you don’t need them


1 You can experiment with good ideas from any framework

Neil Killick, 2017, All Rights Reservedneil_killick

“We are uncovering better ways of developing software…”


2 You don’t need to solve all problems Agile addresses in one go

Why might businesses want Agile? Beat competitors to market (reduce risk of disruption and/or losing first mover advantage)

Build right thing (reduce risk of over-investment in software which is not being used or realising value)

Build thing right (reduce risk of gaining a poor reputation for quality of product, and of spending time/$$ on failure demand and technical debt)

Happier customers (reduce risk of losing customers, or gaining a poor reputation for quality of service)


Why might businesses want Agile? Tax benefits (increased potential for earlier and more frequent capitalisation of released software as an asset)

Early revenue/cost reduction benefits/ROI

Operational efficiency (aka “get more done faster”; higher capacity, throughput and revenue per worker)

Happier shareholders (more products and features = more return)

Happier workers (reduce risk of attrition)


Example - “We want Agile because we want to beat our competitors to market”

OK

What currently stops you from beating competitors to market?


Projects take at least 6 months, usually longer - we don’t identify MVP’s or MMF’s - we define all scope up front, then add to it as we discover more

Deploying is hard, takes time and can only be done by one person, so we don’t do it often

We have lots of approval steps to release anything to production, so we don’t do it often

Releasing is coupled with deploying - we can’t hide unfinished features, so have to finish everything


OK, what can we do to improve the situation?



Pick a project, and identify MVP’s/MMF’s for Release 1


Make it easier to deploy by establishing environments, automating scripts where possible, cross-skilling team members, opening up permissions, etc.




Make it easier to deploy by establishing environments, automating scripts where possible, cross-skilling team members, opening up permissions, etc.



De-couple releasing (shipping) and deploying - enable frequent deployment of working product to a production-like environment which stakeholders can see/test but is not the “live” product



Image credit: http://agadaenergyhealing.com/wp-content/uploads/2017/02/focus2.jpeg

http://agadaenergyhealing.com/wp-content/uploads/2017/02/focus2.jpeg




3 They are based on established enablers for agility


• Customer-focus — in how we decide and describe what we build, and execute

• Autonomous, self-organising “feature” teams — e2e delivery

• Limit WIP, small batches — focus, deliver continuous value

• Transparency — visualise work, create shared definitions, understanding

• Continuous feedback and improvement — experiment, learn, remove wasteful steps to value creation, get better


What does “Agile at scale” look like?


What can I do TODAY to start enabling agile at scale?

Thank you!

Any questions?neil_killick


why scaled agile frameworks exist and why you don't need them

Technology