AGILE VALUES & PRINCIPLES

Who am I?
Andreea Visanoiu

• Scrum Master, Agile Coach

• Originally from Romania

• Lives in Kuala Lumpur

• Works for Mindvalley

• Former Product Manager / Product Owner

• Working with Agile for 7 years

• CSM, CSPO, Certified LeSS Practitioner

• Co-founder of Girls Who Code Romania

CYNEFIN
FRAMEWORK
 Complexity theory - Cynefin
framework

• Good leadership is not a one-size-

fits-all proposition => we need a new
perspective based on complexity
science => Cynefin framework

• The framework sorts the issues facing

leaders into five contexts defined by
the nature of the relationship between
cause and effect

• It’s a decision / analytical framework

• You should manage in the Complex

and Complicated spaces and only
move a small amount to Simple, as it
is highly vulnerable to rapid and
accelerated change
Source: https://hbr.org/2007/11/a-leaders-framework-for-decision-making
 UNORDERED ORDERED

Complexity theory - COMPLEX COMPLICATED

Scrum & Lean are here

Cynefin framework
• Cause and effect are only • Cause and effect are
coherent in retrospect
separated over time and
Examples:

• Probe - Sense - Respond space

• Sense - Analyse - Respond

• Simple: heavily process-oriented situations -
loan payment; complacency, falling in chaos
CE C---->E
• Complicated: call the experts; you know EMERGENT PRACTICE GOOD PRACTICE
something is wrong with you car, but you Disorder
need an expert to solve it; the expert might
overlook non-experts thus miss opportunities
CHAOTIC SIMPLE

• Complex: battlefield commanders, politicians • No cause - effect • Cause - effect relations

relationship perceivable
repeatable, perceivable &
in emergency they gather a team together • Act - Sense - Respond predictable

(different domains, backgrounds, etc.) • Sense - Categorise -

desperately hoping some will come up with Respond
an answer; “Huston, we got a problem”

C#E C=E
• Chaotic: September 11; the “legend” issue NOVEL PRACTICE BEST PRACTICE
Cynefin framework and software development

Examples:

• Simple: just do it

• Complicated: web shop; solution

not evident

• Complex: empirical process

(Scrum, Lean)

• Chaotic: outage in a hosting

environment; “Triage” - solve the
most urgent problem and go
down towards less urgent
(stabilise situation first)

Source: https://blog.agilistic.nl/on-complexity-why-your-software-project-needs-scrum/
WATERFALL
Conception
Waterfall Model
Idea is generated, business case created,
requirements are built, analysed, and
User requirements written down in a specification document
which is the basis for ALL future
development.

System analysis Analysis

Technical design requirements Design

Coding - building the app Development

QA, all testing Testing

Release complete
application as per agreed Deployment Client
requirements
 Waterfall pros and cons
Advantages Disadvantages

Suitable for simple systems (simple apps, that solve Creates big issues for complex to complicated systems and
one problem) completely fails in chaos

Adapts to shifting teams: as the scope is not

The application is built based on specification that can be obsolete
changed from the beginning of the project and work
or not reflect the client’s needs anymore
is done entirely based on documentation (in theory)
Ignores client feedback (mid to end project). Changes required by
Forces a structured organisation
client after the design phase are costly and time-consuming

=> lack of adaptability across all stages of development life cycle

Allows early design changes (e.g. testing coming up with essential issues that affects the entire
system design can lead to complete project fail)

Suited for milestone-focused development Not adaptable or flexible to continuously changing customer needs

Delayed testing period; testing is a fundamental and always-present

process throughout development.
AGILE
 The birth of Agile movement
• 1930s: W. Edwards Deming used the Plan-Do-Study-Act (PDSA, created by physician and
statistician Walter Steward of Bell Labs) as a consultant for Toyota

• 1948-1975: The Toyota Production System was born => lean thinking (Taichi Ohno, Eiji Toyoda)

• 1950s: Iterative and incremental development methods - contributed to successful creation of

X-15 hypersonic jet

• 1986: The New New Product Development Game, by Hirotaka Takeuchi & Ikujiro Nonaka:
“rugby approach” at Fuji Xerox, Honda, and Cannon

• 1993: Jeff Sutherland (Scrum father) started to apply agile principles in software development
and called it Scrum (see “rugby approach”); 1995 it was made public

• 2001: 17 developers - “organisational anarchists” - created the Agile movement after an

intense few days at Snowbird, Utah; the Agile Manifesto was born

• 2000s on: lean and kanban software development systems emerged (formal)
An Agile approach to software development
An Agile approach to software development
Conception
User
requirements

Client feedback
Analysis

Deployment

Design

Testing

Development
http://agilemanifesto.org/
 You don’t “do” agile, you ARE agile
CUSTOMER PEOPLE PROCESS & TOOLS

• Highest priority: satisfy the customer • Build projects around motivated individuals. • Embraced continuous change, in all
through early and continuous Give them the environment and support they development cycle

delivery of valuable software

need and trust them to do the work

• Working software is the primary measure of • Short iterations (maximum 30 days)

• Welcome changing requirements, progress

even late in development. Agile • Deliver frequently

processes harness change for the • Sustainable development - maintain a

constant pace indefinitely (work - life
customer's competitive advantage.

balance)

• Continuous attention to technical

excellence and good design
• Constant customer feedback • Cross-functional teams
enhances agility

through the development lifecycle

• The best architectures, requirements, and • Maximize the work not done -
• Work directly with customers and designs emerge from self-organising teams
simplicity is essential (just in time and
business people (no intermediaries)
just enough)

• Face-to-face conversation as much as

possible

• Continuous learning & adaptation: • Continuous learning & adaptation: the

the teams reflect on how they • Continuous learning & adaptation: the teams teams reflect on how they become
become more effective, tunes and reflect on how they become more effective, more effective, tunes and adjust
adjust behaviour accordingly tunes and adjust behaviour accordingly behaviour accordingly
Source: http://agilemanifesto.org/principles
 Agile pros and cons
PROs (all of the above and…) CONs

Lack of understanding agility (it needs training and management support

Creates value from the get go
to be successful)

Fast response to change Requires cultural change - it’s not only about adopting a framework =>

Accepts and integrates uncertainty Becoming truly agile is timely (1-3 years)

Interpreting the manifesto ad literam can create issues (people blame

Greater flexibility in releasing features
Agile for their own bad behaviour)

Promotes caring about employees and creating a

Integrate diverse skills-set into teams (cross-functional teams)
highly motivating environment

Lack of predictability. Waterfall creates a (false) sense of security with

Less up-front work steady deadlines and estimation, in Agile environments these are
continuously changing, constantly considering feedback).

Constant integration of customer feedback,

Challenges at scale
among the entire development cycle
 Why short iterations?
• 2-4 weeks sprints

• Why:

• Rapid response to changes

• Continuous client feedback - as early as starting up

• Easier tracking of progress and planning (with real data)

• Detect problems (from architecture, design, process, etc.) as early as possible

• Shorter iterations = smaller items to be built => easier reprioritisation

• Easiest approach to go “iterationless” :)

• Releasable increment / MVP / MMF

What is an MVP?
Building MVPs (or MMFs)
 Building MVPs (or MMFs)
Client needs: to go from A-B (let’s say 50 km), in under one hour, every day, back and
fort; she also needs deposit space in case she does any shopping and space for friends
in case he wants to take someone or bring someone along.

Breakdown of client needs:

• The client needs to go from A-B (let’s say 50 km)

• In under one hour, Every day, back and forth

• She also needs deposit space in case she does any shopping

• She needs extra space for friends in case he wants to take someone or bring someone along.
PLAY TIME
Waterfall vs Agile Software Development
 Traditional vs Agile - game
Rules
• Each egg must have at least two different colors

• Two separate people must complete each coloring

activity

• Each egg should be minimum 90% filled with color

• White space doesn’t count as colour

• Cutting must be around oval edges of the egg

• Eggs with major distractions in cutting will be

disqualified

Method 1: Plan driven approach with waterfall team structure

Method 2: Multiple iterations with cross-functional team

Plan Execution Learning Plan Execution Retro Plan Execution Retro Plan Execution Retro

3 min 6 min 3 min 1 min 2 min 1 min 1 min 2 min 1 min 1 min 2 min 1 min
AGILE TOOLS
Toyota leadership
model
Toyota management principles
Go and see is a management technique
A technique with four dimensions:

1. Develop judgement by testing hypotheses: figure out if you’re right or you

have misconception

2. Build consensus by getting people to agree on the problem before

debating a solution; most conflicts involve people arguing on the solution
when they don’t agree on what the problem really is (=> one-person
solutions, people resist implementation)

3. Achieve goals at the desired speed by checking regularly where people

are in the implementation and helping them if they run into impediments

4. Empower people by involving them. “Take it to the team”.

Kaizen - continuous improvement
• The heart of agile

• Help the team figure out what’s their best performance and why

• Try to beat that

• The “standard” m.o. is the best the team can give at any time; now try to
beat it

• Continuous improvement - the basis for creating “learning organisations”

 WHY
THE
The vehicle will not start. (the problem)

5
1. Why?
– The battery is dead.

WHY 2. Why?
– The alternator is not functioning.

3. Why?

WHY – The alternator belt has broken.

4. Why?
– The alternator belt was well beyond its useful

WHY
service life and not replaced.

5. Why?
– The vehicle was not maintained according to
the recommended service schedule.

WHY’S => the fifth why, a root cause

NOTE: you should continue asking “why” until

you reach the root cause of the problem. Only
then you jump into finding a solution.
 Closing

• Expectations check

• Q&A
Andreea Visanoiu

[email protected]

+601 1226 8441