3. The Supermarket
In the 1940s, Toyota started studying American
supermarkets
In a supermarket, customers generally retrieve what they
need at the required time—no more, no less. Furthermore,
the supermarket stocks only what it expects to sell in a
given time, and customers take only what they need,
because future supply is assured
They noticed that store clerks restocked a grocery item by
their store’s inventory, not their vendor’s supply. Only
when an item was near sellout did the clerks order more
This observation led Toyota to develop the methodology
system that aligns inventory levels with actual consumption
4. Toyota Production System (TPS)
The main objectives are to design out
overburden (Muri) and inconsistency (Mura),
and to eliminate waste (Muda)
The goal is designing a process capable of
delivering the required results smoothly
It is crucial to ensure that the process is as
flexible as necessary without stress or
overburden since this generates waste
5. Toyota Production System (TPS) – cont.
TPS is grounded on two main conceptual pillars:
Just-in-time – meaning "Making only what is
needed, only when it is needed, and only in the
amount that is needed“
Jidoka (Autonomation) – meaning "Automation
with a human touch"
6. The Toyota Way principals
Continuous improvement
Form a long-term vision, meeting challenges with courage and
creativity
Improve our business operations continuously, always driving for
innovation and evolution
Go to the source to find the facts to make correct decisions
Respect for people
Respect others, make every effort to understand each other, take
responsibility and do our best to build mutual trust
Stimulate personal and professional growth, maximize individual
and team performance
The right process will produce the right results
7. Lean
Evolved from TPS at the 1950s
Lean comes from Lean Manufacturing, as a way
to optimize the production line to minimize
waste and maximize value to the customer
Everything and every step are examined
8. Kanban
Kanban (“visual signal” or “card” in Japanese)
system that aligns inventory levels with actual
consumption
A signal tells a supplier to produce and deliver a
new shipment when material is consumed.
Achieved by better communication through
visual management
11. Methodologies & Methods – cont.
Methodologies: Lean, Agile
Methods: Kanban, Scrum
Lean and Agile practices complement each other and have a lot in
common
Continuous Improvement and Respect for People are rooted in
both
Respect for people means, respect the customer by value delivery
and respect the employee & Team by providing autonomy, mastery
and purpose
While Lean and Agile considered Methodologies/Philosophies,
Kanban & Scrum are implementations (methods) of Lean and Agile
12. Lean Software Development
Lean development can be summarized by seven principles:
Eliminate waste
Amplify learning & knowledge
Decide as late as possible – planning activities should be
concentrated on the different options
Deliver as fast as possible – to get customer feedback
Empower the team – "find good people and let them do their own
job"
Build Quality in – quality is everyone’s job!
Optimize the whole – organize teams to be complete, multi-
disciplined, co-located product teams, which enables them to have
everything they need to deliver E2E, without reference to other
teams (Spotify model)
13. Lean Software Development – cont.
What is software development waste?
Building wrong/unnecessary feature
Mismanaging the backlog
Defects and lower quality
Unnecessarily complex solutions
Waiting/multitasking
Knowledge loss
Ineffective communication
Unclear or constantly changing requirements (Rework, quality, lack
of focus)
Bureaucracy
14. Agile & Lean
Both agile and lean are aimed at achieving business
goals and delighting clients with a competitive product of
the best quality
Lean is about Smart development, improving by
eliminate waste and making development process
sustainable
Agile is about executing faster, adopting to changes and
making the development process flexible
From here we’ll talk about Agile…
15. Agile & Lean – cont.
Achieving
business goals
Best Quality
Eliminate waste
Sustainable
process
LeanAgile
Execute fast
Adopting to
changes
Flexible
process
17. Waterfall
Poorly adoptive to changing requirements
Discover flaws at late stage
Very hard to estimate resources and time
Value not achieved until the end
18. What is Agile
Agile is a time-focused, iterative philosophy that
allows to build a product step-by-step
(incrementally), delivering it by smaller pieces.
One of its main benefits is the ability to adapt and
change at any step (depending on feedback, market
conditions, corporate obstacles, etc.) and to supply
only relevant products to the market.
19. Benefits of Agile
Allow changes easily
Increase customer satisfaction
Increase visibility
Lower development risk, increase quality
Regular process improvement
20. Agile Concepts (based on the 12 principles)
Regular delivery of software
Progress should be measured by delivery of valuable software to customers
Strive for continuous delivery, in short cycles as possible
The Team
Open and free communication through daily stand-up and other channels. Face-to-
face is the best
Maintain high availability between peers
People perform best when they are doing something they are passionate about
Trust is a key factor. Built over time and easy to lose
Continuous improvement via retrospectives
Design excellence
Know the balance between “Building the right thing” to “Building the thing right”
Continuous attention to technical excellency
Build what you know you need now and not what you think you may need someday
Keep it simple
Welcome changes, even late in development
21. Common misconceptions about Agile
No more planning
No more design
No more QA
No documentation
Requirements changes all the time
Allow you to go faster
23. 60 seconds on science…
A picture is worth a thousand words for scientific
reasons: The brain processes visual information
60,000 times faster than text
40 percent of all nerve fibers connected to the
brain are linked to the retina
Visual information comprises 90 percent of the
data that comes to our brain, suggesting that our
neurological pathways might even prefer
pictorial displays over text
24. Kanban
Kanban approach aims to manage work by
balancing the demands with available capacity
Work is pulled as capacity permits, rather than
work being pushed into the process when
requested
25. Scrum
Short term detailed planning with constant feedback
Simple inspect and adopt cycle
Clear tracking and transparency
Progress in sprints
Sprint
Backlog
Sprint
2–4 Weeks
24 Hours
Deliverables
26. General Practices
Both Scrum and Kanban share the following general practices:
Visualize the work flow
Work items are visualized to give participants a view of
progress and process, from start to finish usually via board.
This increase communication and collaboration
Limit Work in Process
By limiting content, you can avoid problems caused by task
switching and reduce the need to constantly reprioritize items
Optimize Flow & Continuous Improvement
Teams collect metrics, measure their effectiveness by tracking
flow, quality, throughput and more. Continuous improvement
is a culture!
27. Scrum & Kanban - Key differences
Scrum limit WIP by unit of time (sprint iteration). Kanban
by workflow state (e.g. max 5 in ‘In Progress’)
Scrum board is reset between iterations. Not the case in
Kanban
In Scrum, changes in product backlog take effect next
sprint. In Kanban, changes in product backlog take effect
as soon as capacity become available
In Scrum, estimations and commitments are mandatory
(per sprint iteration). Optional in Kanban
30. Product Backlog
Product Backlog is dynamic and lists all features,
enhancements and fixes required to be made to
the product in the next releases
List should be prioritized by business value
Clear requirements and Definition of Done (DoD)
must be included
Definition of Done is the acceptance criteria
defined by the Product for ‘Product Entity’
completion
31. Product Entities
Product content is breaking to pieces, using the following entities:
Item
Defined by the Product Manager
Describe a major feature, usually cross functional
Epic
Defined by the Product Manager
Describe specific functionality. Usually mean ‘big User Story’
Usually will take more than one Sprint to complete
User Story
Defined by the Product Manager/Owner or the Scrum Team
Small, testable, deliverable unit, that fits into one Sprint
Task
Defined by the Scrum Team only
33. Product Owner
Follow the Product Manager vision
Represent the voice of the customers
Responsible for managing the product backlog
Order and prioritize of items
Ensuring that the Backlog is visible and clear
to all, and shows what the Scrum Team will
work on next
Ensuring the Team understands the items to
the level needed
34. Scrum Team
Self organized, cross-functional team
Assuming E2E responsibility for product
development and delivery
With great power comes great responsibility
35. Scrum Master
Make sure the scrum team is progressing as planned by
removing impediments
Monitor the work, for example:
Track sprint burndown
Track plan vs actual
Keep the team focused on the tasks and completing the
Sprint goals
Responsible for the process and ceremonies
Plan team capacity
Supporting the Product Owner activities
37. Sprint & Ceremonies
The Sprint is the heart of Scrum
Sprint is a short duration iteration, consist of the
following ceremonies: Pre-planning, Planning,
Daily, Review/Demo and Retrospective
During the sprint:
No changes should be made that would risk
the sprint goal
Quality do not decrease
39. Pre Planning – cont.
When: 3-4 working days before the beginning of
the Sprint
Participating: Product Manager, Team
Product Manager presenting the USs to the
team, reviewing the requirements
All USs must be ready before this meeting,
containing clear requirements and DoD
41. Planning – cont.
When: First day of the sprint
Participating: Team, Product Manager (optional)
Plan is created by the collaborative work of the
entire team
The planning answers the following:
What can be delivered in the upcoming Sprint
How this can be achieved
The input to this meeting is the Product Backlog, Team
capacity for the sprint and past performance of the
Team
42. Planning – cont.
The number of items selected from the Product Backlog
for the Sprint is up to the Team and only the Team can
assess what it can accomplish over the upcoming sprint
DoD must be understood by all members
All User Stories should be break into Tasks, considering
all work aspects
Tasks are given estimations by one of the following
Story Points
Time Estimation
At the end of the planning, the Team commit to the
sprint content
44. Daily Scrum – cont.
Who: Team, Product Owner (optional)
No more than 15 min
The meeting optimizes team collaboration and
performance by inspecting the work since the
last Daily and forecasting upcoming Sprint work
Every day, the Team should understand how it
intends to work together as a self-organizing
team to accomplish the Sprint Goal by the end of
the Sprint
45. Daily Scrum – cont.
Every team member answer 3 questions:
What I did yesterday?
What I will do today?
Any restrictions holding/delaying my work?
Scrum Master to facilitate resolution of impediments
outside the daily meeting
Daily Scrums improve communications, eliminate other
meetings, identify impediments for removal, highlight
and promote quick decision-making, and improve the
Team’s level of knowledge. This is a key inspect and
adapt meeting
47. Review – cont.
When: last day of sprint
Who: Team, Product Manager, key stakeholders
The team present and demonstrate the work
accomplished in the Sprint
Work considered completed according to DoD
Can replace Hand Over meeting to Support in
some cases
Product Manager must not be “surprised” at this
point…
49. Retrospective – cont.
When: after the Review and prior to the next Planning
Who: Team
Most important tool for continuous improvement
The team inspect the last sprint regarding the process,
relationships, tools and more
Every member must share:
What was good (to preserve)
What went wrong (to improve)
An improvement plan should be created and placed for
next Sprint
50. Retrospective – cont.
This encourages the Team to improve, within the
Scrum process framework and practices to make
it more effective and enjoyable for the next
Sprint
During each Retrospective, the Team plans ways
to increase product quality by improving work
processes
Scrum Master responsibility to track the
improvements
52. Burndown Chart
Burndown chart is a graphical representation of work left to do
versus time
The backlog is on the vertical axis, with time along the horizontal.
It is useful for tracking and predicting when all of the work will be
completed
53. Velocity Chart
Velocity Chart shows the amount of value delivered in each
sprint, enabling to predict the amount of work the team can get
done in future sprints
It is useful during sprint planning meetings, to help decide how
much work the team can feasibly commit
55. User Story
User Story is small & testable unit, to fit into single sprint
US should be derived from related Epic which is part of an Item
US should be ready before pre-planning, holding:
Clear Requirements (if needed, link to
Requirements/MRD/SRS doc)
DoD
Every US should hold the following tasks
Design, Unit Test, writing TP (QA), Code Review, Monitoring,
Create handover doc
Adding US after Planning should be avoided. If must:
Via Product Manager/Owner
Requires a quick planning forum
Removing a US with ‘equivalent’ EE + buffer on low maturity
56. Story Points
Usually sizing by Fibonacci sequence: 1,2,3,5,8,13,21
Benefits:
Gives us an overview of the scope of work
Uses multiple perspectives to determine the size of
work
Clears out that we can’t be exact
Sizing considering:
The amount of work to do
The complexity of the work
Risk or uncertainty in doing the work
Time / Duration
57. Scrum Board
Team add categories that fit their work flow
Board must be updated all time and reviewed by the team
in the Daily meetings
58. Defects
Bug found at early stage is much more cheaper
in money, effort and time, to fix than the same
bug found later in the process
Bugs related to a feature that was detected
during the sprint must be fixed immediately as
part of the feature. Feature can not be marked
as completed otherwise
Bugs detected after sprint completed should be
managed in Bugs backlog
59. Capacity Planning - Example
Number of working days in sprint, reducing:
5% un-planned absence
1 day for ceremonies (for 2 weeks Sprint)
X% code review (to others)
Y% support (when support is small. Otherwise, add
“Support Bucket” US)
~15% Scrum Master
60. From Dev to Production
Version release should be planned for the first day of next
sprint
Features that require stabilization period will be released
in the next planned release
Release Notes should be published upon every release,
indicating all features and known bugs. Main customers
for that are Support and Success
Product Manager is responsible to publish external
Release Notes
Need to establish short & fast Patch release process for
unexpected issues