1. INTRODUCTION TO
AGILE &
LEAN SOFTWARE DEVELOPMENT
Lean Software Development 1

2. ① Introduction to Agile
 Traditional vs. Agile
 Agile Manifesto & Principles
② Definition of Agile
 Iterative & Incremental & Plan Do Check Act
 Empower & Cross Functional Teams
 Reliance on Automation
③ Agile Core Principles & Practices
④ Agile Software Development Lifecycle
A. Agile
Lean Software Development 2

3. 6/30/2015 Lean Software Development 3
① Agile Manifesto & Principles
 Produce Value Early: highest priority is to satisfy the Customer through
early & continuous delivery of valuable software.
 Welcome Change: welcome changing requirements, even late in development.
Process harness change for the customer’s competitive advantage.
 Iterative Delivery: Deliver working software frequently, every couple of
weeks/months, with a preference to the shorter timescale.
 Daily Business Collaboration: Business People and Developers must work
together daily throughout the project.
 Trust Motivated Team: build projects around motivated individuals. Give
them the environment & support their need, and trust them to get the job done.
 Face-to-Face Communication: most efficient & effective method of conveying
information to and within development team is face-to-face conversation.
 Working Software: working software is the primary measure of progress.
 Sustainable Pace: Agile processes promote sustainable development. The
Sponsors, Developers, Users should maintain a constant pace indefinitely.
 Technical Excellent: continuous attention to technical excellence &
good design enhances agility.
 Keep It Simple: simplicity - the art of maximizing the amount of
work not done - is essential.
 Self-Organize: the best architectures, requirements, and designs
emerge from self-organizing teams.
 Reflect & Adjust: At regular intervals, the team reflects on how to become
more effective, then tunes & adjusts its behavior accordingly.
The Agile Manifesto:
 Individuals and Interactions
over Processes and Tools
 Working Software over
Comprehensive Documentation
 Customer Collaboration over
Contract Negotiation
 Responding to Change over
following a Plan

4. 6/30/2015 Lean Software Development 4
② Definition of Agile – Iterative
Time
Analysis
Design
Coding
Testing
20% done
(100% usable!)
Time
Analysis
Design
Coding
Testing
Do we have half
a solution yet?
Traditional Process Agile Process

5. 6/30/2015 Lean Software Development 5
② Waterfall Requires Perfect Vision
1 2 3 4 5
Waterfall calls for a fully formed idea up front.
And, doing it on time requires
dead accurate estimation.

6. 6/30/2015 Lean Software Development 6
② Incremental - Agile Expects Vision Shift
1 2 3
A more iterative allows you to move from
vague idea to realization making course
corrections as you go … stop when
diminishing returns are encountered!
4 5
… builds a rough version, validates it, then
slowly builds up quality

7. 6/30/2015 Lean Software Development 7
② Short Iterations, Small Releases

8. 6/30/2015 Lean Software Development 8
② Short Iterations, Small Releases

9. PDCA PDCA for GAP Analysis
6/30/2015 Lean Software Development 9
② Deming’s PDCA (Plan Do Check Act/Adjust)

10. 6/30/2015 Lean Software Development 10
② Empower & Cross Functional Teams

11. 6/30/2015 Lean Software Development 11
② Reliance on Automation
Build Scripts
(Ant, Puppet, Bash,
PowerShell)
Version Control
(SVN, CVS, GIT)
Build Integration
(Jenkins, Maven)
Test 1
(Automated Regression Tests)
Test 2
(Manual & Migration Tests)
Sandbox
On-Demand Pull
Nightly Pull
Automated Push
Manager
Developers
Tester
Compile/Tag Source
Run Unit Tests
Run Functional Tests
Run Test Coverage
Static Code Analysis
Build Database
WatchesCommit Uses
Test
Informs
Stakeholder
Inspect

12. 6/30/2015 Lean Software Development 12
③ Agile Core Principles &
Practices
1. Early Delivery of Value through Iterations with Demos: the project should be
broken into a series of time-boxed, iterations that have a demo to show progress to
all Stakeholders.
2. Continuous Involvement of the Customer: tradeoff is an important part of the
process. Prioritize business value of work with Business & IT working
collaboratively to balance risk.
3. Retrospectives: weekly team retrospective should be held to learn how to improve
& enhance the project delivery efforts.
4. Communication: daily ‘Scrum’ should be held amongst team members to
understand what has been accomplished, what will be accomplished & what
roadblocks exist.
5. User Stories reflect Business Value & Priority: User Stories are managed in a
backlog, prioritized by business value & releases are determined by the
development velocity & what is deemed acceptable as a production release.
6. Acceptance Tests for all Requirements: Everyone owns ‘quality’. Standards, Test
Automation, and key principles, such as Test Early / Test Often, are emphasized.
7. Sustainable Pace or Velocity: Team Members are involved in estimates &
commitment dates.
8. High Visibility: Information on project status, progress and issues/risks should be
maintained in real-time, web accessible tools.

13. 6/30/2015 Lean Software Development 13
④ Agile Software Development Lifecycle
Crystal
DSDM
XP
FDD
Agile
RUP
Scrum
Concept
Creation
Requirements
Specification
Design Code Unit
Test
Integration
Test
System
Test
Acceptance
Test
System
in Use
Adapted from Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002).
Agile Software Development Methods: Review and Analysis. VTT Publications 478. (pp. 95)
KEY: Project management
Process
Practices / activities / work products

14. 6/30/2015 Lean Software Development 14
① Traditional vs. Agile Project Management
Conventional projects
take too long and
often miss the mark
Lean (agile) methods link developers
and users to hit the mark quickly:
Extrinsic-Value & Intrinsic-Quality

15. Communication:
 Frequent collaboration
between Users & Programmers
 Use simple design,
common metaphors,
application of patterns
Simplicity
 Focus on the simplest solution
 Don’t build more functionality
than required
 Refactor complexity
Feedback
 Unit Tests for feedback
from the System
 Acceptance Tests
for feedback from Customer
 The Planning Game
for feedback from the Team
Courage
 Refactor code to make
future changes easier
Throw code away that is obsolete
Respect
 Respect for others; self-respect
 Adopting the other 4-values
 Respect gained from others in Team
6/30/2015 Lean Software Development 15
① 5 Core Principles of XP

16. 6/30/2015 Lean Software Development 16
① XP Practices
Fine-Scale
Feedback
Pair
Programming
Planning
Game
Test-Driven
Development
Whole Team
Continuous
Process
Continuous
Integration
Refactoring
or Design
Improving
Small
Releases
Shared
Understanding
Coding
Standard
Collective
Code
Ownership
Simple
Design
System
Metaphor
Programmer
Welfare
Sustainable
Pace

17. 3 Principles
Start with what you
know
Agree to pursue
incremental,
evolutionary change
Respect current roles,
responsibilities, and job
titles
5 Core Practices
Visualize
Limiting Work-In-Progress
Manage Flow
Make management policy
Improve collaboratively
using “safe to fail”
experiments
6/30/2015 Lean Software Development 17
① Lean Kanban

18. 1. Lean for Software vs. Manufacturing
2. From Lean Manufacturing :
 Aim for continuous flow (single-piece flow)
 Watch your queues (pull production)
3. Pay to learn early in the project
4. Develop for Business Value once risks are down
5. Trim the Tail: choose to deliver by Value / Date
B. Why Agile / Lean in Software
Development
Lean Software Development 18

19. 6/30/2015 Lean Software Development 19
① Lean for Software vs. Manufacturing
I wish they’d decide
what style
they want!
Users &
Sponsors
Testers
Business
Analysts
I wish they’d
decide what
functions they
want!
A decision
I wish they’d decide
on the UI design
already!
I wish they’d think a
bit more carefully
before coding!
Programmers
Every
line of code
is a decision
UI
Designers
Software development looks like manufacturing if
the unit of inventory is the invalidated decision!

20. 6/30/2015 Lean Software Development 20
① Software Development has correction loops
Detailed
decisions about
external
appearance
Decisions
about function
and style
Detailed decisions
about function
and data
Decisions
about program
structure
Decisions
about system
correctness
Users &
Sponsors
UI
Designers
Programmers
Testers
Business
Analysts

21. 6/30/2015 Lean Software Development 21
② From Lean Manufacturing:
aim for continuous flow
time
Testers
100 lines of code
show up for testing
# of design decisions
Decisions being
validated or broken
How long this line of code
/ screen / use case /
decision
sits in the testing queue
Decisions arriving

22. 6/30/2015 Lean Software Development 22
② Kaizen - Continuous Improvement IEEE

23. 6/30/2015 Lean Software Development 23
② From Lean Manufacturing:
watch your queues
Users & Sponsors
absent
UI Designers
Business Analysts
some
Programmers
Database Designers
Tester
Enough
Users & Sponsors
UI Designer
A few
Business Analysts
Lots of
Programmers
Single, solitary
Database Designer
Many
Business Analysts
Not enough
Programmers Some
Testers
Enough
Users & Sponsors

24. 6/30/2015 Lean Software Development 24
③ Waterfall is a late-learning strategy
Delivers nearly no knowledge
(or risk reduction)
Knowledge comes at
the “moment of truth”:
final integration.
time
cost
Growth of knowledge with
big-bang integration

25. 6/30/2015 Lean Software Development 25
③ Agile pay to learn early in the project
Development sequence indifferent
(with respect to knowledge)
Delivers knowledge
(risk reduction)
time
cost
Growth of knowledge with
early, continuous integration

26. 6/30/2015 Lean Software Development 26
④ Develop for Business Value
once risks are down
time
Knowledge growing
(risk reduction)
cost
Growth of business value
Business value growing

27. 6/30/2015 Lean Software Development 27
⑤ Trim the Tail: choose to deliver
by Value or Date
Trim to deliver
on-time (or early)
Delay to get more
or better

28. Lean Software Development History &
Thinking Tools
C. Lean Software Development
Lean Software Development 28

29. 6/30/2015 Lean Software Development 29
7 Lean Principles
Lean
Eliminate
Waste
Amplify
Learning
Decide as
Late as
Possible
Deliver as
Fast as
Possible
Empower
the Team
Build
Integrity
In
See the
Whole

30. 6/30/2015 Lean Software Development 30
① Eliminate Waste
Waste is anything that doesn’t add VALUE
to a product
Value as Perceived by Customer
Many types of Waste to be avoided
 Delivering Value
Deliver what the Customer wants immediately
 Value Stream Mapping

31. 6/30/2015 Lean Software Development 31
① Eliminate Waste - Delivering Value
Waste Description Example
Partially Done
Work
Work started, but not complete;
partially done work can entropy
• Untested / Undocumented Code
• Specs waiting for development
Extra Processes Extra work that does not add value • Forgetting Decisions, re-trying
Solution, un-utilize Knowledge
• Unnecessary approvals
Extra Features Features that are not required, or
are thought as nice-to-haves
• Gold plating
• Technology features
Task Switching Multi-tasking between several
different projects when they are
context-switching penalties
• People on multiple projects
Waiting Delays waiting for reviews &
approvals
• Waiting for prototype reviews
• Waiting for document approvals
Motion The effort required to communicate
or move information or deliverables
from 1 group to another; if teams
are no co-located, this effort may
need to be greater
• Distributed teams
• Handoffs: passing/getting
information/work from someone
Defects Defective documents or software
that need corrective
• Requirements defects
• Software bugs

32. 6/30/2015 Lean Software Development 32
① Waste – Value Stream Mapping Before
Sales people
Marketing
Requirements’
sources
Entering reqs. to the
system
Analysis
Management
Acceptance
Prioritization Release Planning
VAT: 1 hour VAT: 3 hour
VAT: 1 hour
VAT: 1 hour
VAT: 1 hour
NVAT: 5 days
NVAT: 3 days
NVAT: 4 days
NVAT: 2 days
VALUE ADDING TIME (VAT): 7 hours
NON-VALUE ADDING TIME (NVAT): 14 days Development process

33. 6/30/2015 Lean Software Development 33
① Waste – Value Stream Mapping Process
Three general steps (Abdulmalek and Rajkopal):
Choose a product target for improvement.
Draw a Current State Map of the process, then
analyzing the system and identifying its Weaknesses.
Create a Future State Map, depicts how the system
should look like when wastes have been removed.
Apply the technique of “Five Why’s” which aims
to identify the root-cause behind the Weakness.
Value Stream Mapping follow the Continuous
Improvement philosophy of Lean (Kaizen).

34. 6/30/2015 Lean Software Development 34
① Waste – Value Stream Mapping - After
Sales people
Marketing
Requirements’
sources
Entering reqs. to the
system
Analysis
Management
Acceptance
Prioritization Release Planning
VAT: 1 hour VAT: 3 hour
VAT: 1 hour
VAT: 1 hour
VAT: 1 hour
NVAT: 3 days
NVAT: 2 days
NVAT: 3 days
NVAT: 2 days
VALUE ADDING TIME (VAT): 7 hours
NON-VALUE ADDING TIME (NVAT): 10 days
Development process

35. 6/30/2015 Lean Software Development 35
② Amplify Learning
Development is an exercise in discovery
Adapt based upon empirical data, not assumption
Repeat steps until requirements are met
Expect & embrace mistakes then learn from them

36. 6/30/2015 Lean Software Development 36
③ Decide as Late as Possible
Expect uncertain & make decisions
when uncertain is at a minimum
Avoid locking in decisions until the future is closer &
easier to predict (with options-based approach)
Delay decisions are based on fact, not speculation,
not on uncertain assumptions / predictions
Keeping design options open & adapting to context is
more valuable than committing early

37. 6/30/2015 Lean Software Development 37
④ Deliver as Fast as Possible
Rapid Software Development has many
advantages
Customers get what they need now
 not the biggest that survives, but the fastest
Customers can delay determining what they want
until they know more  Just-In-Time in Iteration
Compressing the Value Stream eliminate waste
 Self-Pulling system during a stand-up meeting

38. 6/30/2015 Lean Software Development 38
⑤ Empower the Team
No One understands the details better than
the People doing the work.
Developers can let each other know
when work needs to be done  Work-Out technique
Use of “Pull” and “Local Signaling” mechanisms
 Find good people & let them do their own job
Self-Organizing Teams are more empowered
 Ownership of challenges, success or failure

39. 6/30/2015 Lean Software Development 39
⑥ Build Integrity In (Build Quality In)
A System has integrity when it gives the
Customer exactly what they want.
Perceived Integrity is crucial
 Understand problem domain & resolve same time
Conceptual Integrity is mandatory
 Refactoring: simplicity, clarity, minimum amount
Integrity is the result of many
processes working together effectively

40. 6/30/2015 Lean Software Development 40
⑦ See the Whole
Concentrate on the effort of the Team as a
WHOLE rather than as a group of individuals.
Focus on Overall system performance
 Think big, act small, fail fast; learn rapidly
Avoid tendency to maximize only
specialized parts of overall system
Be wary of individual organization needs when using
Contracts

41. 6/30/2015 Lean Software Development 41
More Info
Social Linked-In:
vn.linkedin.com/in/nguyennhatthanh
Social Slideshare:
www.slideshare.net/SmartBizVN
Personal Website:
http://smartbiz.vn/sales/en
Show Cases:
http://smartbiz.vn/sales/en/projects/
Email: Sun.SmartBiz@gmail.com
Phone: (+84) 938 203080