Chapter 3

 Agile Development
Software Engineering: A Practitioner’s
Approach,
by Roger S. Pressman

1
What is Kanban?
 Kanban is a Japanese word that
literally means “visual card”. Kanban
cards were originally used in Toyota
to limit the amount of inventory tied
up in “work in progress” on a
manufacturing floor. Kanban not only
reduces excess inventory waste, but
also the time spent in producing it.
What is Kanban?
 Kanban term came into
existence using the flavors of
“visual card,” “signboard,” or
“billboard”, “signaling
system” to indicate a
workflow that limits Work In
Progress (WIP).
 The core concept of Kanban

Visualize Workflow
o
Split the entire work into defined
segments or states, visualized as
named columns on a wall.

o
Write each item on a card and put in a
column to indicate where the item is
in the workflow.
 The core concept of Kanban

Limit WIP
o
Assign explicit limits to how
many items can be in progress at
each workflow segment / state.
i.e., Work in Progress (WIP) is
limited in each workflow state.
o .
 The core concept of Kanban

Measure the Lead Time
Lead Time, also known as cycle time
is the average time to complete
one item. Measure the Lead Time
and optimize the process to make
the Lead Time as small and
predictable as possible
 The core concept of Kanban

Making process policies

explicit (e.g., write down
your reasons for selecting
items to work on and the
criteria used to define
“done”).
 The core concept of Kanban

Focusing on continuous
improvement by creating
feedback loops where changes
are introduced based on
process data and the effects of
the change on the process are
measured after the changes
are made.
The core concept of Kanban

Make process changes

collaboratively and
involve all team
members and other
stakeholders as needed..
The core concept of Kanban
The core concept of Kanban
Daily Life Example of Kanban
Kanban - Benefits

 Bottlenecks become clearly visible in real-time. This leads

people to collaborate to optimize the whole value chain
rather than just their part.

 Useful for situations where operations and support teams

have a high rate of uncertainty and variability.
Kanban - Benefits

 Tends to spread throughout the organization naturally,

including sales and management. This increases visibility of
everything that is going on at the company.

 Reduces inventory in the range of 25%-75%, thereby

reducing company costs.
Kanban - Benefits

 Since all segments/states in the workflow are visually

organized, the required items, reducing the wait times and
ensuring speed, continually support all the tasks in the
workflow.

 Overproduction of inventory is avoided, thereby saving

resources and time as well. This is termed as eliminating
waste.
FDD
History of FDD


FDD was first applied in the
year 1997 on a real-world
application by Jeff De Luca for
large software development
FDD Life Cycle

•Build overall model

•Build feature list
•Plan by feature
•Design by feature
•Build by feature
FDD Life Cycle
 Characteristics of FDD
•Short iterative: FDD lifecycle works in simple and
short iterations to efficiently finish the work on time
and gives good pace for large projects.
•Customer focused: This agile practice is totally
based on inspection of each feature by client and
then pushed to main build code.
 Characteristics of FDD
•Structured and feature focused: Initial activities
in lifecycle builds the domain model and features list
in the beginning of timeline and more than 70% of
efforts are given to last 2 activities.
•Frequent releases: Feature-driven development
provides continuous releases of features in the
software and retaining continuous success of the
project.
 Advantages of FDD
•Reporting at all levels leads to easier progress
tracking.
•FDD provides continuous success for larger size of
teams and projects.
•Reduction in risks is observed as whole model and
design is build in smaller segments.
•FDD provides greater accuracy in cost estimation of
the project due to feature segmentation.
 Disadvantages of FDD
•This agile practice is not good for
smaller projects.
•There is high dependency on lead
programmers, designers and mentors.
•There is lack of documentation which
can create an issue afterwards.