Header in

ICAgile Certified
Gill Sans
Professional
Bold 36pts
Subhead in Gill Sans Semibold 18pts
ICP

Copyright © 2020 NTUC LearningHub Pte Ltd. All rights reserved.

LHUB_ver1.0 1
THIS COURSE IS ACCREDITED BY

7
ICAGILE LEARNING ROADMAP

8
 CLAIMING YOUR NEW CERTIFICATION
1. Your training provider will upload the full class roster to ICAgile for certification.
2. You will receive an email containing instructions on how to access your ICAgile.com profile.
3. You will be required to complete a brief post-class survey.
4. Upon completing the survey, you will become certified and receive a copy of your certificate via email.

9
10
Criteria for Funding
In order to attain SOA, trainee is required to meet minimum attendance rate and
be assessed as ’Competent’.

100% ACTIVE TEST DURATION: 10 QUESTIONS PASSING MARKS:

ATTENDANCE PARTICIPATION 30 MINS 60%
What We'll Cover Over the Next Two Days...

Day 1 Day 2
▪ Module 1: Agile foundation ▪ Module 6: Organize around customer
▪ Module 2: Agile practices and value
▪ Module 3: Culture and mindset ▪ Module 7: Planning value work
▪ Module 4: Value-Driven ▪ Module 8: Visualizing and managing
Development work
▪ Module 5: Know the customer ▪ Module 9: Learn and adapt
▪ Summary
▪ Assessment

12
Module 1 Agile
The need of agility?

foundation
Agile values

Agile principles

Real world case studies

15
Why do businesses fail?

Originally published at www.brandminds.ro The Economist, Technological change - The last Kodak moment?
Jan 14th 2012

17
 ？ Everyone understands what needs to be done
？ Requirements will not change
？ Project will be completed on time
？ Product/service will serve customer needs
？ Customer needs will remain the same in future
？ Customers will use the product/service
？ Competition will not hurt us in the meanwhile
Planning

Traditional / Waterfall
Development

Execution
 Agile Defined

“Ability to both create and respond to change

in order to profit in a turbulent business
environment. “
- Jim Highsmith (2002)

20
 Iterative and incremental approach
Traditional

Idea Requirements Design Develop Test Deploy

Time

Agile
Refine Refine Refine Refine

Gather Gather Gather Gather

Design Design Design Design
feedback feedback feedback feedback

Develop Deliver Develop Deliver Develop Deliver Develop Deliver

Value preposition
 Adaptability to change

Traditional Agile
The Plan creates The Vision creates
cost/schedule estimates feature estimates

Fixed Features Cost Schedule

Value / Vision
Driven
Plan
Driven

Flexible Cost Schedule Features

Source: Michelle Sliger in “Relating PMBOK Practices to Agile Practices”

24
Heart of Agile - Empirical process

“ Agile has
become overly
decorated. Let’s
scrape away
those
decorations for a
minute, and get “
back to the heart
of agile.

Dr. Alistair Cockburn

Agile Manifesto co-author, and
Heart of Agile founder
Values of agile software development

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 there is value in the items on

the right, we value the items on the left more.
Principles of Agile software development
Welcome changing
Our highest priority is to Deliver working software
requirements, even late in
satisfy the customer frequently, from a couple
development. Agile
through early and of weeks to a couple of
processes harness change
continuous delivery of months, with a preference
for the customer's
valuable software. to the shorter timescale.
competitive advantage.

Build projects around The most efficient and

Business people and motivated individuals. effective method of
developers must work Give them the conveying information to
together daily throughout environment and support and within a development
the project. they need and trust them team is face-to-face
to get the job done. conversation.

Agile processes promote

sustainable development. Continuous attention to
Working software is the
The sponsors, developers, technical excellence and
primary measure of
and users should be able good design enhances
progress.
to maintain a constant agility.
pace indefinitely.

At regular intervals, the

Simplicity--the art of The best architectures,
team reflects on how to
maximizing the amount of requirements, and designs
become more effective,
work not done--is emerge from self-
then tunes and adjusts its
essential. organizing teams.
behaviour accordingly.

Adapted from Agile Manifesto

Agile – Why?
▪ Business value comes first
➢ The agile is responsive to business’ and users’ needs.

▪ Flexibility
➢ Traditionally, new business initiatives are defined fully upfront with little room for change.

▪ Continuous improvement
➢ Agile teams are always learning, collaborating and adjusting throughout regular reviews.

▪ Frequent value delivered

➢ Outcomes are delivered in smaller chunks and frequently

29
Source - 14th state of Agile survey
Agile roles are emerging - large scale
 15 min

Team activity: Success and innovation

32
End of Module 1
The need of agility?

Agile
foundation Agile values

Agile principles

Real world case studies

33
 Different agile practices
Module 2: Agile
practices Scrum framework

Extreme Programming

Kanban

Being agile in context

34
Source - 14th state of Agile survey
 Scrum
Scrum Master
Product backlog

Features
Feature 1
Feature 2 Product Owner Developers

Daily Scrum

Backlog refinement

15 mins

TO DO IN Done
PROGRESS Sprint review
Not more than
a month

Actions
Sprint backlog Potentially
shippable increment
Sprint planning Sprint

Retrospective
 WIP limit Explicit
Kanban policies

BACKLOG TO DO (WIP = 2) IN PROGRESS (WIP DONE

= 4)
* Only team pulls * Pick high priority * Done only when
cards from backlog cards first accepted by
to this lane customer

39
 When to apply agility?

AGILE is Better
Chaos
Iterative customer
feedback shapes
requirements

Agile is Best
Waterfall Iterative customer
Little benefit Feedback shapes
from Agile requirements +
Prototyping mitigates
risks

https://www.scrum-tips.com/2016/02/17/stacey-complexity-model/
Brainstorm @ Jamboard
Agile Practices in Your Organization
What are my challenges to agility?
 Different agile practices
End of Module
2: Agile Scrum framework
practices
Extreme Programming

Kanban

Being agile in context

42
Module 3: Growth mindset
Culture and
mindset
Organizational
culture

Learning journey

43
 Self Assessment

https://wabisabilearning.com/blogs/mindfulness-
wellbeing/growth-mindset-quiz
46
SCHNEIDER CULTURE MODEL
End of Module Growth mindset
3: Culture and
mindset
Organizational
culture

Learning journey

48
Module 4: Value Defining value
driven
development
Prioritization
techniques

Quality

49
Brainstorm @ Jamboard
Let’s talk value!
How does value looks like to you?
Core Description
Concept
Value The worth, importance, or usefulness of something to a stakeholder within a context.

Value can be seen as potential or realized returns, gains, and improvements. It is also
possible to have a decrease in value in the form of losses, risks, and costs.

Value can be tangible or intangible. Tangible value is directly measurable. Tangible

value often has a significant monetary component. Intangible value is measured
indirectly. Intangible value often has a significant motivational component, such as a
company's reputation or employee morale.

In some cases, value can be assessed in absolute terms, but in many cases is assessed
in relative terms: one solution option is more valuable than another from the
perspective of a given set of stakeholders.

The Business Analysis Core Concept Model™ (BACCM™)

“Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.”
~Agile Manifesto
 Lean Start-up approach
▪ Build, Measure, Learn feedback loop

◼ Plan and execute

initiatives based on initial
hypothesis

◼ Hypothesis to be validated
through measurable
metrics

◼ Learn from the data

collected and adapt
accordingly

http://theleanstartup.com/principles
 Inspect & Adapt – MVP Approach

What is your customer’s /

stakeholders’ needs?

Are they being fulfilled?

Is your product increment

testable/usable?

Iterative, Incremental

Pivot, Fail Fast, Fail early

https://www.youtube.com/watch?v=20SdEYJEbrE
 Priority Visualisation / Representation

MoSCow 2 x 2 Matrix
 Cost of Delay

Determine true business value by understanding Cost of Delay (CoD)

Impact + Urgency

CoD = How much money you lose (per unit of time) due to a delay in launching a
product/feature.

CoD = The impact of time on business outcome.

CoD = Opportunity Cost against time lost

CoD = Increase in risk over time

We are putting a price tag on time

Dealing with Cost of Delay

Expedite Fixed
Highest Cost of Delay
time
Time-bound

Standard Intangible
COD increases over time Can be identified but cannot be
quantified or easily estimated
Trip to Antarctica
 Value or Quality – What’s the trade-off?
High
Customer
value

Low High
Engineering Engineering
quality quality

Low
Customer
value
Agile triangle
End of Module Defining value
4: Value driven
development
Prioritization
techniques

Quality

61
Module 5: Know
People and their interests

the customer
Identifying the customers

Managing the value of work

Gathering feedback

62
Who is the customer?

64
 Header in Gill Sans Bold 36pts
Subhead in Gill Sans Semibold 18pts

https://twitter.com/shuligilutz/status/1116302825888284679

Copyright © 2020 NTUC LearningHub Pte Ltd. All rights reserved.

LHUB_ver1.0
 Header in Gill Sans Bold 36pts
Subhead in Gill Sans Semibold 18pts

Copyright © 2020 NTUC LearningHub Pte Ltd. All rights reserved.

LHUB_ver1.0
 Customer Personas

Lives in Tampines, Singapore

https://www.highervisibility.com/blog/creating-buyer-personas/
 Thinking about customer satisfaction
Requirements
Definition
Type

Must Be (Expected Requirement that can dissatisfy (but

Quality) cannot increase satisfaction)

One-Dimensional The more of these, the more a user is

(Desired Quality) satisfied
If absent does not cause
Delighters (Excited
dissatisfaction, but will delight users if
Quality)
present
User is indifferent to whether the
Indifferent
feature is present or not

https://www.isixsigma.com/tools-templates/kano-analysis/kano-analysis-customer-needs-are-ever-changing/
Stakeholder management
 Working with continuous feedback

- Surveys - Usability testing - Customer interviews - Pilot users -

71
Module 5: Know
People and their interests

the customer
Identifying the customers

Managing the value of work

Gathering feedback

72
Module 6:
Individuals and interactions

Organizing
around value Effective communication

Team and organizational

structures

Working environment

73
Brainstorm @ Jamboard

How may we work well together?

 Built-in
instability

Self-
Learning
organizing
organization
teams

Characteristics
of agile team

Overlapping
Subtle control development
phases

Multi-
learning
Team Charter
 Tuckman's Model of Team Formation and Development

https://www.toolshero.com/management/tuckman-stages-of-group-development/
 Shift in Roles, Shift in Structure

The 5 Trademarks of Agile

Organizations, McKinsey
Quarterly, Dec 2017
Richard Hackman’s Four Levels of Team Authority

https://www.mountaingoatsoftware.com/blog/two-types-of-
authority-leaders-must-give-to-self-organizing-teams
Communication Management
 COMMON COMMUNICATION ISSUES
Anything that slows the movement of ideas between minds slows the projects

Cockburn, Alistair (2016) Elements to a Theory of Software Development. HaT Technical Report, March issue, p. 3
 Co-located Teams

• Team seated in single location; Ideal for Agile

• Seamless F2F communication & visibility
– ‘Caves & Common’ for privacy & think-tank
• Aid Osmosis communication
• Visible information radiators
Osmotic communication
Who is on a team matters
less than how team
members interact and
structure their work ...

Findings from Project Aristotle, a Google

People Analytics Division 2012 initiative
 Brainstorm @ Jamboard

How do we organize ourselves in a remote setup?

End of Module
Individuals and interactions

6: Organizing
around value Effective communication

Team and organizational

structures

Working environment

87
Module 7: Understanding agile
planning
Planning value
work
Different levels of
planning

Estimating work

88
 What is planning?

• Planning is the exercise to guess what it will be like to develop a

software with customer
• Some purposes of planning
✓ Brings the whole team together
✓ Decide on scope and priorities
✓ Estimate cost and schedule
✓ Give everyone confidence that the system can actually be done
✓ Provide a benchmark for feedback
Backlog inspired by vision
(Foreseeable future Capabilities
~ 3 months)

Release
Chosen
(On-demand or as Features/Stories
Next priority
planned)

Iteration
(Timebox iteration Story A Story B
~ 1-4 weeks)

Day
(Ideal Time Task 1 Task 2 Task 1
~ 4-5 hrs)
 What is a story?

“Tell me and I forget. Teach me and I remember.

Involve me and I learn.”

- Benjamin Franklin
 3Cs
• Card: Write what you’d like
to see in the software on a
bunch of index cards.
• Conversation: Get together
and have a rich conversation
about what software to
build.
• Confirmation: Together
agree on how you’ll confirm
that the software is done.
Structuring Requirements Hierarchy & Types of Estimates

Type of Estimate
EPIC
EPIC
T-Shirt Sizing (XS, S, M, L, XL)
Features
Features
User Story Story Points (Fibonacci Nos: 0,
User Story 1, 2, 3, 5, 8, 13, 20, 40, 100)
User Story
Task
Real time or elapsed time or
Task ideal time (hours or days)
Task
Team planning: Stage 1
Brainstorming

94
 User stories

• Used to create time estimates for release planning

• Drive creation of acceptance tests
• Written by customer, in customer terminology
• Contains just enough detail to make a low risk estimate on
how long it will take to implement
 Format of User Stories
This is no mandatory structure for user stories; however, the most
popular format includes 3 elements:
a user role or persona [WHO]
a necessary action, behaviour, or feature [WHAT]
the benefit or business value received by the user when the story is implemented
[WHY]

Example format 1:
As a <role>, I want to <feature> so that <goal or value>
As a current bank account holder, I want to access my account, so that I can
withdraw cash

Example format 2:
In order to <business value>, as a <role>, I need to <behaviour>
In order to withdraw cash from my account, as a current bank account holder, I
need access to my account
 User Stories in the Product Backlog

User Story Story ID No. Priority

As an online customer, I want to be able to search for

6 1
products online so that I can make a purchase

As an online customer, I want to add products to a

3 2
shopping cart so that I can pay for them

As a CFO, I like to complete an order so that I can

7 3
receive payment

... and so on
 Good Stories are “INVEST”ed

Independent. Ensure the story can stand alone, thus avoiding the creation
I of complex dependencies with other stories

Negotiable. Assumes that there will be ongoing negotiation about the

N priority, form and function that the story represents

Valuable. Stay focused on things that are valuable to the user and not on
V the technical details meaningful only to developers

Estimable. Keep the story discreet and clear enough to develop an order-
E of-magnitude estimate for effort in resource requirements

Small. For clarity, estimating and planning purposes, ensure the story doesn't
S become an epic

Testable. Explicitly describe in the story the feature that is expected so that it
T can pass as a simple “yes” or “no” test

Wake, William C. "INVEST in Good Stories, and SMART Tasks." XP123.com, 2003. http://xp123.com/xplor/xp0308/index.shtml
Team planning: Stage 2
Initial backlog

99
Collaborative planning - Poker

• Product owner brings the most important

stories to the game
• The team explores the needs together. This
helps team gain understanding of the
requirement
• Each team member individually estimates
the effort required to complete the user
story. This estimate is called story points
• The estimates are produced at the same
time by all members to avoid influence
• Any differences in estimates between team
members are discussed with PO, and
requirements are further refined
• When all team members reach a consensus
on effort, the user story is updated with
story points
Team planning: Stage 3
Estimate and Split

101
Splitting stories
Splitting patterns and anti-patterns
End of Module Understanding agile
planning
7: Planning
value work
Different levels of
planning

Estimating work

104
Module 8:
Information radiators

Visualizing and
managing work Managing WIP

Managing changes

Continuous integration

105
 Visualize the flow
To Do Refine Development Integrate Validate Deliver

In Progress Done In Progress Done In Progress Done In Progress Done

Customer Cashier Kitchen Staff Assembler Server Customer

Burn Down Chart
Average Velocity
 Work-In-Progress (WIP)

Work in progress (WIP) refers to the type of work that has

commenced but not yet been completed

Excessive number of WIPs are indicative of several problems:

• WIP takes up resources and yet delivers no return of the
investment until it is turned into a finished item
• WIP masks bottlenecks within processes which in turn slows the
overall workflow as WIP prevent efficiency issues from surfacing
• Large number of WIPs could translate into scrap or expensive
rework if a change is imminent
 Explicit policies
Cycle time = 7 min 30
sec
Quality
Capacity Definition standard
allocation of Done policy
Policy

To Do Refine Development Integrate Validate Deliver

In Progress Done In Progress Done In Progress Done In Progress Done

Burger

Fries In Progress

Drinks

30 5 1 1
sec min min min
 Managing change
Relative prioritization or ranking enforced

Prioritize Prioritize
d items d items

1 Change analyzed 1
& prioritized
2 2
A Change
3 A accepted, item 5
3 dropped
4

5 4
Cutoff constrained Cutoff constrained
by time or budget by time or budget
5
 Common Ways to Manage Change Requests in Agile

During the Iteration:

• No changes are made that would endanger the Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product
Owner and Developers as more is learned but only when it is
deemed necessary.

Scrum Guide (2017), p, 9

 Continuous Delivery
Continuous Delivery (CD) is a software engineering approach in
which teams keep producing valuable software in short cycles and
ensure that the software can be reliably released at any time
https://www.infoq.com/articles/cd-benefits-challenges/
Continuous Integration (CI)
Visualize and manage:
Stage 4
Team Visualization

115
End of Module
Information radiators

8: Visualizing
and managing Managing WIP
work

Managing changes

Continuous integration

116
Module 9: Learn Need of reflection
and adapt

Team retrospective
techniques

Adapting process
and product

117
 Learn to adapt

Refine

Gather
Design
feedback

Develop Deliver

118
Reflections

119
 The Prime Directive

"Regardless of what we discovered, we understand and truly believe that

everyone did the best they could, given what they knew at the time, their
skills and abilities, the resources availability, time and the situation at
hand.”

--Norm Kerth, Project Retrospectives: A Handbook for Team Review

120
Flow of a reflection session

121
Retrospectives
 Retrospective Techniques
Some common retrospective techniques include:

DROP ADD
Activities that you do Activities that you
and you should stop should add to your
doing practice within the team

KEEP IMPROVE
Activities that you Activities that you are
are already doing, already doing, but you
and that work well could improve them

Retrospective Starfish DAKI

Learn and Adapt: Stage 5
Team Retrospective

124
End of Module Need of reflection
9: Learn and
adapt
Team retrospective
techniques

Adapting process
and product

125
Summary

126
Thank you

127
APPENDIX 1
• The Agile Manifesto

128
 Scrum Artifacts
Tangible by-product produced during product development
High
1. Product backlog FINE GRAINED

– features, functions, enhancements, fixes… SMALL STORY

P
– Description, Estimate, Priority MEDIUM GRAINED R
– Priority: value, cost, risk, necessity I
– DEEP: Detailed appropriately (rolling wave), Large Story
O
Estimated, Emergent, and Prioritized COARSE GRAINED R
– Product backlog Grooming I
– Only one PB even for multi teams T
EPIC Y
2. Sprint Backlog
Low
– PB items for the sprint + Task plans
– Contains User story, Tasks, Schedule, Resources, Status, Remaining work {DAY 1,
DAY 2,..., DAY N}
3. Increment = ∑ completed PB items
 Lean Software Development
Agile Lean • Lean manufacturing
“Maximize Value” “Minimize Waste”
• Optimize the whole with
speed and sustainability
• Tools:
• “fast-flexible-flow” - Womack & Jones
• Value Stream Mapping
• 5S (Sort, Set in order, 7 Principles
Shine, Standardize, 1. Eliminate Waste
Sustain) 2. Empower the Team
• 5 Why 3. Deliver Fast (Feedback, Maximize ROI)
• Visual Control 4. Optimize the Whole
• 7 forms of waste 5. Build Quality In (QA)
• Pull systems • Refactoring, automatic build & test
6. Defer Decisions: Mitigate uncertainty
• WIP techniques
7. Amplify Learning: Short Iterations
• Business Value Delivered
Chart
• Visual control to represent the velocity of
business solutions delivered
 7 Forms of Lean Waste in Software
# Waste Example
1 Partially done work Code waiting for QA, Specs waiting for development
2 Extra processes Unused/over documentation, unnecessary approvals, bureaucracy
3 Extra features Little/no value adding for end user, gold plating
Technology showcase
4 Task switching People assigned to multiple projects
5 Waiting / Delay Waiting for reviews, approvals, clarification, guidance,
feedback
Experiencing dependencies (internal/ external)
Slow communication…
6 Motion Info/deliverable movement from one to
another
Distributed teams, hand-offs
7 Defects Defective documents, requirements or software
Tom and Mary Poppendieck
 Welcome to Kanban

• Kanban is NOT a software development life cycle or project

management methodology
• Kanban is an approach to incremental, evolutionary process and
systems change for organizations
• It is an approach to change management – a framework for driving
change in an organization.
• In developing the Kanban method, a change management
approach that uses kanban systems to provoke change is enabling
the emergence of Lean Software Development in organizations
 Kansan's Change Management Principles
• Start with what you do now
• Understanding current processes, as actually practised (not as prescribed in the
policy)
• Starting from current practice establishes the baseline of performance &
effectiveness from which future changes can be assessed
• Respecting existing roles, responsibilities, and job titles
• Gain agreement to pursue improvement through evolutionary change
• Not big bang changes
• Changes will always evolve but the process will never reach the perfect state
• Goals offer direction for change
• Encourage acts of leadership at all levels - from the individual contributor to
senior management
• People has to feel comfortable to lead or at least to take charge temporarily
 Five Key Properties of Kanban

5. Use models* to
1. Visualize workflow recognize improvement
opportunities

2. Limit work-in- 4. Make process

progress policies explicit

3. Measure and
manage flow

* Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an
understanding of variability through the teachings of W. Edwards Deming, and the concept of muda (waste)
from the Toyota Production System. The models used with Kanban are continually evolving, and ideas from
other fields, such as sociology, psychology, and risk management are appearing in some implementations.
 1. Visualize the Workflow
Label the columns to
To Do Analysis Development Testing Done represent either the type of
work or who is responsible
In prog. Cmplt. In prog. Cmplt. In prog. Cmplt.
Use cards to represent work
items (in the form of user
stories, for example)

Pull cards from left to right

as work gets completed

• Visualize the work on a board with cards to represent work items like user
stories or tasks
• Use different colours to represent different types of work items like themes, user
stories or tasks
• Place the cards in the respective columns depending on their workflow status
• As the work gets completed pull the cards from left to right
 2. Limit the WIP
Exceeding the WIP limit will
To-Do Analysis (5) Development (4) Testing (3) Done result in a blockage

In prog. Cmplt. In prog. Cmplt. In prog. Cmplt.

When you notice a blockage,

stop work to assist
I can't start
I have too Let me anything
much work! help you

Blockages interrupt flow so

others can't continue working

• Set WIP limits to minimize multi-tasking and ensure cards move smoothly across
the board
• Fill the To-Do column with top priority work from the product backlog,
replenishing as necessary
• If the flow gets blocked, the entire Kanban team should stop work, collaborate
and fix it
 3. Focus on Flow

To-Do Analysis (5) Development (4) Testing (3) Done Watch for blockages that
interrupt workflow

In prog. Cmplt. In prog. Cmplt. In prog. Cmplt.

Track cycle time to measure

team's performance

Track lead time to see

how long your customers
are waiting for delivery

• Look out for interruptions in flow and use them as opportunities to improve
• The workflow should run smoothly, not stop and start
• Choose some flow metrics to track and analyse them
• If your workflow is running smoothly, you know you are delivering value
4. Make
policies
explicit
 5. Continuous improvement
Plan how to improve
the current method
To-Do Analysis (5) Development (4) Testing (3) Done
Implement changes to
In prog. Cmplt. In prog. Cmplt. In prog. Cmplt. test them

Let's make
How can we some changes If it works, great! If
improve our and see what not, let's try
current Kanban happens something else
method?
Monitor the results.
If successful,
implement on a wider
scale

• Even after implementing Kanban, work is never finished

• A vital part of Kanban is to continuously improve your processes
• Monitor the way work is performed and make improvements on an ongoing
basis
 Kanban Properties in Action

1.

2.

4.

3.

Jesper Boeg (2012) Priming Kanban

Scrum vs. Kanban