Understanding the principals of Agile

1. Agile Overview
Benny Zangiri
Jan 2018

2. How it all began
History and Background

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

9. Software Development

10. Methodologies & Methods
Agile
Lean
Kanban
Scrum
Crystal Methods
Scrumban
DSDM
FDD

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

16. Agile Concepts
Agile is not a religion!

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

22. Agile Methodologies
Kanban & Scrum

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

28. Focus on Scrum

29. Scrum Flow
Sprint
Pre-Planning
Sprint
Pre-Planning
Sprint
Planning
Sprint
Planning
Sprint
Retrospective
Sprint
Retrospective
Scrum Team
Daily
Scrum
Daily
Scrum
Sprint
Review
Sprint
Review
Product
Backlog
Sprint
Backlog

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

32. Roles & Responsibilities
 Product Owner
 Scrum Team
 Scrum Master

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

36. Ceremonies

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

38. Pre Planning
Sprint
Pre-Planning
Sprint
Pre-Planning
Sprint
Planning
Sprint
Planning
Sprint
Retrospective
Sprint
Retrospective
Scrum Team
Daily
Scrum
Daily
Scrum
Sprint
Review
Sprint
Review
Product
Backlog
Sprint
Backlog

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

40. Planning
Sprint
Pre-Planning
Sprint
Pre-Planning
Sprint
Planning
Sprint
Planning
Sprint
Retrospective
Sprint
Retrospective
Scrum Team
Daily
Scrum
Daily
Scrum
Sprint
Review
Sprint
Review
Product
Backlog
Sprint
Backlog

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

43. Daily Scrum
Sprint
Pre-Planning
Sprint
Pre-Planning
Sprint
Planning
Sprint
Planning
Sprint
Retrospective
Sprint
Retrospective
Scrum Team
Daily
Scrum
Daily
Scrum
Sprint
Review
Sprint
Review
Product
Backlog
Sprint
Backlog

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

46. Review
Sprint
Pre-Planning
Sprint
Pre-Planning
Sprint
Planning
Sprint
Planning
Sprint
Retrospective
Sprint
Retrospective
Scrum Team
Daily
Scrum
Daily
Scrum
Sprint
Review
Sprint
Review
Product
Backlog
Sprint
Backlog

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…

48. Retrospective
Sprint
Pre-Planning
Sprint
Pre-Planning
Sprint
Planning
Sprint
Planning
Sprint
Retrospective
Sprint
Retrospective
Scrum Team
Daily
Scrum
Daily
Scrum
Sprint
Review
Sprint
Review
Product
Backlog
Sprint
Backlog

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

51. Sprint Metrics

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

54. Additional Topics

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

61. Thanks