Agile Fundamentals: The basics you need to know

1. Accredited training provider

2. Agility is the ability to both create and respond to change in
order to profit in a turbulent business environment.”
Jim Highsmith
“Agility is the ability of an organization to react and adapt to
changes in its environment faster than the rate of these
changes.”
Philippe Kruchten

3. An evolution in the making
over the last 50 years
XP
Scrum
Toyota
Production
System
Agile
As a way of thinking
& working
RUP
Lean/
Kanban
Agile
For software
RAD
Waterfall
Six
Sigma
Prince 2
Complexity
Theories
Radical
Management
Management
3.0
Learning
Organisations
Customer
Delight
Holacracy
Business
Agility
EVO
Joyful
work
DSDM
3

4. 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 we value the items on the right, we value the items on the left more.
* Or “Demonstratable Functionality”
4

5. Individuals and Interactions
Working Software
Customer Collaboration
Responding to Change
Processes and Tools
Comprehensive Documentation
Contract Negotiation
Following a plan
Current level of Agility
Desired Future State of Agility within context
5

6. We follow the following principles:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers work together daily throughout the project.

7. 5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers
and users should be able to maintain a constant pace indefinitely.

8. 9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,
Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agilealliance.org / www.agilemanifesto.org
© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

9. Source: Ahmed Sidky, used with permission
Agile is a
mindset
Established through
4 values
Grounded by
12 principles
Manifested through
many different practices
SCRUM
XP
CUSTOM
Agile as a Mindset and Culture Being Agile
Internalizing the Agile mindset, values and principles, and then mastering how to
apply the right practices and tailor them to work situations as they arise over time.
Being Agile starts a virtuous cycle of joy in work and customer delight. It will set your
organisation on a journey of cultural transformation, creating an environment of
creativity, productivity and increased profitability.
Agile as a Process and set of Practices Doing Agile
Learning practices and applying them by rote, without taking into
account the Agile mindset, values and principles runs the risk of
mistakes in tailoring and practicing the most effective techniques. Doing
Agile will improve some of your practices and result in better products.

10. A set of completely subjective scales (Version 0.1)
People are…
People are good at their jobs because…
Decisions are taken…
You build the right product by…
Human beings with intrinsic motivation Resources that need extrinsic motivation
They put in effort and always learn They’re just more intelligent
Implicitly. We
muddle through.
Usually by consensus among the people
that are impacted
By management after conferring by the
people that are impacted
By management
Cogs
Where I work no one
else is good
By someone up the
hierarchy and we
never get informed
Frequently showing it to the customer and
prospective users
Rigorously analysing requirements
And writing detailed specs
Chaos
Labelled as “Agile”
More Agile Traditional Just bad
CC-BY http://www.finding-marbles.com, @findingmarbles

11. OutdatedExtensive and hard to maintain
11
There’s none. Haven’t
you read the
manifesto?
Do nothing
We never try to
improve
Only done after a project
Retrospectives are…
When trying to improve…
Something needs clarification, you…
A way to find improvements
and implement them
A place to rant about the same
problems every sprint
How would I know
what’s undesirable
Give feedback, but also check whether the system
inadvertently rewards said behaviour
Give feedback so they might change
What’s that?
Do nothing
Talk to them in person
Chaos
Labelled as “Agile”
More Agile Traditional Just bad
The documentation is…
Just enough. When you discover something’s
missing, you add that particular part.
Not necessary
anymore
When people show undesirable behaviour, you…
What is the smallest change that might help?
What can we start right now? Can we use something physical
Obviously we need a tool / framework / processNot only do we
change, we oscillate.
Call them Email
CC-BY http://www.finding-marbles.com, @findingmarbles
A set of completely subjective scales (Version 0.1)

12. For more information, see: http://modernagile.org/
MAKE PEOPLE AWESOME
Steve Jobs used to ask his colleagues, “What incredible benefits
can we give to the customer? Where can we take the customer?”
In modern agile we ask how we can make people in our
ecosystem awesome. This includes the people who use, make,
buy, sell or fund our products or services. We learn their context
and pain points, what holds them back and what they aspire to
achieve. How can we make them awesome?
EXPERIMENT & LEARN RAPIDLY
You can’t make people awesome or make safety a
prerequisite if you aren’t learning. We learn rapidly by
experimenting frequently. We make our experiments
“safe to fail” so we are not afraid to conduct more
experiments. When we get stuck or aren’t learning
enough, we take it as a sign that we need to learn more
by running more experiments.
MAKE SAFETY A PREREQUISITE
Safety is both a basic human need and a key to unlocking high
performance. We actively make safety a prerequisite by
establishing safety before engaging in any hazardous work. We
protect people’s time, information, reputation, money, health and
relationships. And we endeavour to make our collaborations,
products and services resilient and safe.
DELIVER VALUE CONTINUOUSLY
Anything that isn’t delivered isn’t helping anyone become more
awesome or safe. In modern agile we ask ourselves, “How could
valuable work be delivered faster?” Delivering value continuously
requires us to divide larger amounts of value into smaller pieces
that may be delivered safely now rather than later.

13. Image Adapted from Henrik Kniberg
Not like this…
Bad Agile Many traditional projectsGood Agile
No plan
No
architecture
Rough,
adaptive plan
Rough, adaptive
architecture
Big up
front plan
Big up
front architecture
Don’t go overboard with Agile!
Like this!
1
1
2 3 4
2 3 4 5

14. 14
• Cynefin Framework
• Management 3.0
• Radical Management
• Stoos Network
• WikiSpeed
• Motivation 3.0
• Management Information Exchange
• Lean Start-up
• Beyond Budgeting
• Kanban
By Mandy Simpson, CC-BY-SA-3.0
Marketing
Human
Resources
Legal
Products Services
Learning and
Development…
Finance
14

15. 15
Focus of effort
People
80-85%
Adopt new tools, adopt new
ways to use some existing
tools,
Process
10-15%
Adopt new practices
and techniques at the
Team, department, and
organisational levels
Individuals and
interactions: People
evolve to an Agile
mindset, learn new skills,
and adopt improved
collaboration strategies
Tools
5-10%
Scott W. Ambler: Senior Consulting Partner at Scott Ambler + Associates

16. A model for learning skills:
Shu — Learn the rules and follow them
Ha — Know when to break the rules
Ri — Make new rules
16

17. CommunicationEffectiveness
2 people at
whiteboard
2 people
on phone
2 people
on email
Recorded
Video
Paper
Richness of communication channel
2 people
on video
conference
Graph source: Alistair Cockburn

18. Affected Stakeholders IT Development Analysis Testing
Domain
Experts
GovernanceUsers /
Customers
Value
Focused
Delivery
Focused
Value Team Facilitator
[Product Owner / Value Manager]
Delivery Team Facilitator
[ScrumMaster / Iteration Manager]
Key:
- Disciplined
- Self Organising
- Shared Leadership
- Require an Agile friendly
environment

19. At a software services firm, a 50% increase in team
familiarity was followed by a 19% decrease in defects
and a 30% decrease in deviations from budget.
On audit and consulting teams, high familiarity yielded a
10% improvement in performance, as judged by clients.
https://hbr.org/2013/12/the-hidden-benefits-of-keeping-teams-intact

20. “The goal of many leaders is to get people to think more highly of the leader.
The goal of a great leader is to help people to think more highly of themselves.”
J. Carla Nortcutt
• Creating an environment of trust
• Demonstrating and expecting accountability
• Sharing power with the group
Agile leadership
is…
• Always being the nice guy
• Watching the team crash and burn
• Hold a committee meeting to discuss every
decision
Agile leadership
is not…
20

21. Alignment
Purpose
Context
Vision
Mission
Mission Tests
Boundaries
Project Community
Interactions
Committed People & Assets
Prospective Analysis
Values and Principles
Core Team
Working Agreements
Source: Liftoff: Launching Agile Projects & Teams, by Ainsley Nies and Diana Larsen, ISBN-13: 978-0977920167

22. 22
Waterfall
Low uncertainty
Low novelty
We’ve done it before
Requirements are stable
Agile
High uncertainty
High novelty
Changing requirements

23. 23https://www.versionone.com/agile-101/agile-software-development-benefits/

24. Product Vision
Long-term
guiding vision for
the product
Strategy,
boundaries and
goals
Product Roadmap
Rough timeline
for high-level
capabilities
Release Plan *
Features to be
delivered in the
current release
Time-box
increment made
up of multiple
Iterations
Iteration Plan *
Work plan to
deliver the stories
for this iteration
Iteration between
1 and 4 weeks
Daily Commitment
Daily work to
deliver against
the iteration plan
* For teams and/or organisations using Kanban flow, these
two levels will be continuous as opposed to time-boxed 24

25. Deliver
(Iteratively build
and deploy)
New problem or opportunity
Concept
(Identify and
validate an idea)
Initiate
(Clarify, estimate
and plan)
Clear on the idea –
investigate further
Changed our mind –
revisit goals
Clear on what to do Done enough Close
(Ready for new
adventure)
AKA Discover
Bad idea kill project
Need to stop & think
25

26. Ideate
Discovery Delivery
Close
Goals have
shifted
Goals Clear &
Understood Clear on what to do
Need to stop & think
Out of use
Lean/Iterative

27. • Discovery
• Desired Outcomes
• Identify Stakeholder Goals
• High Level Capabilities
• Invention
• High Level Design
• High Level Estimates
• High Level Plan and Proposal
GOAL:
Is this idea worth pursuing?
What does the cost-benefit analysis say?
Does it make business sense to proceed to the next phase?
Should we do this at all?
Idea
Desired
Outcomes
Project
Charter
Capability
List
27

28. SMART
Goals
Initial
Backlog
Release
Plan
Project
Charter
Definition
of DONE
The Initiate phase is about:
• Understanding the quality goals
• Defining the key features that
will be built first
• Drafting a release plan
• Agreeing how the product
development work will be run
• Hear the voice of
the customer
• Story Identification
• Story Prioritisation
• Story Estimation
• High Level
Solution Design
• Release Planning
• Initiate wrap-up
GOAL:
To confirm the feasibility of the product and carry out
more in-depth design and planning for development.
Desired
Outcomes
Project
Charter
Capability
List
28

29. Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story Story
Story
Story
Story
MVP 1
MVP 2
Feature Feature Feature
Epic Epic Epic Epic Epic Epic Epic Epic Epic Epic
Story
Story
Story
Story
Story

30. GOAL:
To iteratively develop the product in small increments,
learning and adapting as we deploy frequently and
get rapid feedback from real customers.
Release
Plan
Set-up
Deliver
Planning
& Kick-off
Project
Charter
Prioritised
Backlog
Deploy to
Production
Test
Cases
Working
Solution
Updated
Documentation
Production
Handover
Retrospective
Showcase
Done
Enough?
YesNo
Daily
Cycle
30

31. Social Practices and Ceremonies Technical Practices*
*Substitute appropriate practices for business focused projects and products
Social Practices and Ceremonies Technical Practices*
Stand-Up
Release
Planning
Stories
Iteration
Planning
Showcase
Retrospectives
Project
Wall
Relative
Estimation
Co-Location
Burn-Up
Progress
Definitions of
Ready and Done
Success
Sliders
Pair
Work
Test-Driven
Development
Refactoring
Collective
Code Ownership
Technical and
Functional Spikes
Incremental
Design
Automated
Deployment
Continuous
Integration
Social Practices and Ceremonies Technical Practices*Social Practices and Ceremonies Technical Practices*

32. • Stories describe the functionality that will be delivered
by the project
• A story is a promise to have one or more conversations
later —deferring the detail closer to the time when we’ll
act on it, keeping it fresh in mind
As a [role]
I want to [do something]
So that [achieve valuable outcome]
As a frequent flyer
I want to be able to see my points balance
So that it’s clear if I can use it to pay my
ticket
32

33. Confirmation
criteria to determine when
implementation complete
Card
written description
Conversation
between team and
customer representatives
33

34. Independent Fewer dependencies simplify planning
Negotiable The details are worked out in conversation
Valuable Must provide clear business value to the customer
Estimable Know enough to estimate with good confidence
Small Keep it as small and simple as possible
Testable Know clearly how we’ll tell that the story is successful
34

35. Dependencies
Done
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Iteration 0
• Setup Envs.
• Prep stories
• Update
Design
Iteration 1
• Account
List
• Login
• Transfer
Iteration 2
• Scheduled
Transfer
• BPay
• Export
Deploy
Iteration 3
• Email
alerts
• SMS alerts
Iteration 4
• Mobile
interface
Deploy
Iteration 5
• Statements
• International
transfers
Iteration 6
• Scheduled
bill payment
• Cross selling
Deploy Warranty
Week
Defining iterations, teams, velocity,
dependencies, dates, RAIDS
Release freeze
begins
Mobile banking
expo
35

36. • Iterations give a steady rhythm of delivery
• Every iteration, the team picks a sub-set of stories
from the Product Backlog
• Every iteration, most of them get ‘Done’
• Kanban improves and smoothes the flow of work
• Every day, work items flow through the work process
• Work-in-process limits reduce task-switching waste
and shorten cycle time
• Time-in-process limits highlight blockages
• It’s not one or the other, it can be both
• DevOps—delivery at the speed of the internet Test (2) Deploy (2)
In
progress
Done
Dev (3)Queue (7) Analysis(4)
In
progress
DoneIn
progress
DoneIn
progress
Done
Prioritisation by
business value
Project
Charter
Deploy to
Production
Test
Cases
Retrospective
Showcase
Done
Enough?
Yes
No
Daily
Cycle
Working
Solution
Updated
Documentation
Production
Handover
Release
Plan
Set-up
Deliver
Planning
& Kick-off
Prioritised
Backlog

37. As a xxx I want yyy so that zzz
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Story 7
Story 8
Story 9
Epic 1
Epic 2
Epic 3
Backlog
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Iteration Tasks
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
Iteration
Planning
Task Work Task Work Task Work Task Work Task Work Task Work Task Work Task Work Showcase
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Daily
Stand-up
Task Work Task Work Task Work Task Work Task Work Task Work Task Work Task Work Retrospect
Story 3
Iteration
Planning
Story 1
Story 2
Iteration Backlog
Uncompleted Story 3
✗
✓
✗
✓
✓
✓
✓
✓
✓
✓
✗
37

38. Kanban is a system of workflow visualisation:
• Inspired by Toyota’s “just-in-time” delivery methods
• Work is progressed based on demand (“pull” vs. “push”)
• Does not focus on iterations—work flows continuously through the “production line”
• Starts with existing processes, and drives incremental, evolutionary change
• Relies on a foundation of respect for people, focus on value, courage, collaboration and a systemic
approach to improvement
Kanban has five core practices:
1. Visualise the workflow—you can’t improve what you can’t perceive
2. Lead using a team approach—self-organising teams are the fastest way to improve
3. Reduce the Batch Size of your Efforts (BASE) —or limit Work In Progress (WIP). When the batch
unit of work is decreased, more gets accomplished overall
4. Make policies explicit—create a common and shared understanding of how work will be handled
to allow assessment, review and continuous improvement
5. Implement feedback loops—learn and improve continuously, reflect frequently, run improvement
experiments
38

39. Release wall
Iteration wall
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6
We are here
Iteration 2
Planned
In
elaboration
Ready
for dev
Ready for
testing
In dev
In
testing
Done
Transition lanes (only if necessary)
Current Iteration
Future Iteration
39

40. This phase is to close out all the remaining
reporting and governance activities needed
and ensure the organization makes good use
of what has been learned in this product
development effort.
• Confirm the working system satisfies the
needs of the user community
• Ensure the Measurement System for the
Business Benefit Realisation is up and
running well
• Wrap up all product development activities
• Feed forward the lessons learned to the
next product development efforts in the
organisation
Close
GOAL:
To close out product development
and governance activities
Business
Benefits
Realised
Project
Charter
Lessons
Learned
41