Agility Scrum XP Kanban

1. PROCESS & METHODOLOGIES
Ben Khalfallah Héla
27 Octobre 2018

2. OUTLINE
1. Agility
2. Scrum
3. XP
4. Kanban

3. AGILITY
DECOMPOSE, ITERATE, OBSERVE AND ENHANCE

4. AGILITY
DIFFERENT PERSPECTIVES

5. PROCESS CONTROL MODELS

6. PROCESS CONTROL MODELS

7. AGILITY

8. « Why do we talk about ?

9. « All is about success

10. SUCCESS
➤ Success must be achieved / maintained in light of :
Dynamic environment
Complexity and chaotic environment
Unknown futures
Unpredictable states
Rapidly changing situations
New, diverse circumstances
Unexpected events
Unfamiliar situations
Changing tasks, purposes
Loss, Damage, Threats
Success = effectiveness, efficiency, survivability, control

11. « Agility is the ability to successfully
cope with changes in the
environment.

12. AGILITY
Agility
Re-configurability
Innovativeness
ReflexiveRobustness
Survivability
Responsiveness
Flexibility
Adaptability
Engineering

13. AGILE PRACTICES
THINKING
COLLABORATING
PLANNING
DEVELOPING
RELEASING

14. AGILE PRACTICES
➤ Thinking - Pair Programming, Energised Work, Informative
Workspace, Root Cause Analysis, Retrospectives etc.
➤ Collaborating – Trust, Sit Together, Real Customer
Involvement, stand-up meeting, coding standards, sprint
demo, reporting etc.
➤ Releasing – Done, No Bugs, Version Control, Continuous
Integration, Collective Code ownership, documentation etc.
➤ Planning – Vision, Release Planning, Iteration Planning,
estimating etc.
➤ Developing – Customer Tests, Test Driven Development,
Simple Design etc.

15. BEING AGILE
IT IS ABOUT THE PEOPLE AND TEAMS.
IT IS ABOUT CUSTOMER AND DELIVERING SOFTWARE.
IT IS ABOUT CONTINUOUS IMPROVEMENT.

16. AGILE METHODS
➤ Agile methods are processes that support the agile
philosophy.
➤ Agile methods consist of individual elements called practices.
➤ Practices include using version control, setting coding
standards, and giving weekly demos to your stakeholders.
➤ Agile Methods combine these practices to accentuate parts
that support agile philosophy.
public Method agileMethods {
getMethod(Agile.agile);
}

17. SCRUM
Adjust commitments &
deadlines
Clear commitments & deadlines
Retroaction
DECOMPOSE, ITERATE, OBSERVE AND ENHANCE
Short & limited iteration : 2-4 weeks

18. SCRUM
➤ Scrum is an agile process that allows us to focus on delivering the
highest business value in the shortest time.
➤ Scrum projects make progress in a series of “sprints”.
➤ It allows us to rapidly and repeatedly inspect actual working
software (every two weeks to one month).
➤ A constant duration leads to a better rhythm.
➤ The business sets the priorities. Teams self-organise to
determine the best way to deliver the highest priority features.
➤ Every two weeks to a month anyone can see real working software
and decide to release it as is or continue to enhance it for
another sprint.
➤ Product is designed, coded, and tested during the sprint.

19. SCRUM

20. NO CHANGES DURING A SPRINT

21. SCRUM FRAMEWORK
• Product owner
• ScrumMaster
• Team
Roles
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Ceremonies
• Product backlog
• Sprint backlog
• Burndown charts
Artifacts

22. SCRUM TEAM AND PHASES

23. PRODUCT OWNER
➤ The Product Owner is the sole person responsible for managing the
Product Backlog.
➤ Product Backlog management includes :
Clearly expressing Product Backlog items.
Ordering the items in the Product Backlog to best achieve goals and
missions.
Ensuring that the Product Backlog is visible, transparent, and clear to
all, and shows what the Scrum Team will work on next.
Ensuring the Development Team understands items in the Product
Backlog to the level needed.
➤ The Product Owner is one person, not a committee.
➤ For the Product Owner to succeed, the entire organisation must respect
his decisions.

24. PRODUCT OWNER

25. SCRUM MASTER
➤ Represents management to the project.
➤ Responsible for enacting Scrum values and practices.
➤ Removes impediments & difficulties.
➤ Ensure that the team is fully functional and productive.
➤ Enable close cooperation across all roles and functions.
➤ Shield the team from external interferences.

26. SCRUM MASTER

27. PRODUCT BACKLOG
➤ The requirements.
➤ A list of all desired work on the project.
➤ Release definition (a release can be realized on one or multiple sprints).
➤ Prioritized by the product owner.
➤ Reprioritized at the start of each sprint.

28. PRODUCT BACKLOG - HOW ?
Brainstorm, discuss, improve and innovate
customer specifications

29. PRODUCT BACKLOG - HOW ?
Sketch ideas
User flow & rules
Content
Navigations & animations

30. PRODUCT BACKLOG - HOW ?
Define modules (epics), stories and components
Modules
Stories
Components :
Backend
Frontend
Design

31. PRODUCT BACKLOG - HOW ?
Estimate stories, define releases and priorities
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a
reservation.
5
As a guest, I want to change the dates of
a reservation.
3
As a hotel employee, I can run RevPAR
reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50

32. PRODUCT BACKLOG - HOW ?
Sketch ideas User flow & rules
Functional Specification Document (FSD)
Customer
specifications
Modules, Stories
& Components

33. PRODUCT BACKLOG - HOW ?
Define the next iteration :
Sprint Backlog
Releases & Priorities

34. SPRINT BACKLOG
➤ Any team member can add, delete or change the sprint
backlog.
➤ If work is unclear, define a sprint backlog item with a larger
amount of time and break it down later.
➤ Daily and weekly roadmaps according to sprint progress.
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the foo class
Mon
8
16
8
12
8
Tues
4
12
16
8
Wed Thur
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8

35. BURNDOWN CHART
Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tues Wed Thur Fri
4
12
16
7
11
8
10
16 8
50

36. SPRINT PLANNING MEETING
High-level design is considered
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product

37. THE DAILY SCRUM
➤ Parameters :
Daily.
15-minutes.
Stand-up.
➤ Not for problem solving !
➤ Whole world is invited.
➤ Only team members, ScrumMaster, product owner, can talk !
➤ Helps avoid other unnecessary meetings.

38. THE DAILY SCRUM
What did you do yesterday ?
What will you do today ?
Is anything in your way ?

39. THE SPRINT REVIEW (DEMO)
➤ Team presents what it accomplished during the sprint.
➤ Typically takes the form of a demo of new features or
underlying architecture.
➤ Informal :
➤ 2-hour prep time rule.
➤ No slides.
➤ Whole team participates !
➤ Invite the world !

40. SPRINT RETROSPECTIVE
➤ Periodically take a look at what is and is not working.
➤ Typically 15–30 minutes.
➤ Done after every sprint.
➤ Whole team participates :
ScrumMaster.
Product owner.
Team.
Possibly customers and others.
DECOMPOSE, ITERATE, OBSERVE AND ENHANCE
RETROACTION

41. SPRINT RETROSPECTIVE RETROACTION
START DOING
STOP DOING
CONTINUE DOING

42. SCRUM VALUES

43. « Scrum’s roles, events, artifacts, and rules are
immutable and although implementing only parts
of Scrum is possible, the result is not Scrum. Scrum
exists only in its entirety and functions well as a
container for other techniques, methodologies, and
practices.
https://www.scrumguides.org/scrum-guide.html

44. EXTREME PROGRAMMING (XP) - WHAT ?
XP takes commonsense principles and practices to extreme levels:
➤ If code reviews are good, we’ll review code all the time (pair
programming).
➤ If testing is good, everybody will test all the time (unit testing).
➤ If design is good, we’ll make it part of everybody’s daily
business (refactoring).
➤ If integration testing is important, then we’ll integrate and test
several times a day.
➤ If short iterations are good, we will make the iterations really,
really short – seconds, minutes and hours, not weeks, months
and years.

45. « XP is a lightweight methodology for
small to medium sized teams developing
software in the face of vague or rapidly
changing requirements.
-Kent Beck

46. « XP doesn't conduct complete up-front
analysis and design--an XP project starts
with a quick analysis of the entire system,
and XP programmers continue to make
analysis and design decisions throughout
development.

47. « XP works well when there are uncertain
or volatile requirements.

48. « Extreme Programming teams don’t use
too much documentation. They usually
solve problems through discussions
inside of the team.

49. « XP focuses on people and values team
work over power.

50. « Extreme Programming is focused on the
code rather than on design.

51. EXTREME PROGRAMMING (XP) - PRINCIPLES
1. Simplicity – Only do what is needed and asked for.
2. Communication – Everyone is part of the team and
communicate daily.
3. Feedback – Demonstrate software early and often and listen
to any feedback.
4. Courage – Tell the truth about progress and estimates.
5. Respect – Everyone contributes value even if it is just.
enthusiasm.

52. EXTREME PROGRAMMING (XP) - FUNDAMENTALS
➤ Writing unit tests before programming and keeping all of the
tests running at all times.
➤ Integrating and testing the whole system--several times a day.
➤ Producing all software in pairs, two programmers at one
screen.
➤ Starting projects with a simple design that constantly evolves
to add needed flexibility and remove unneeded complexity.
➤ Putting a minimal system into production quickly and
growing it in whatever directions prove most valuable.

53. EXTREME PROGRAMMING (XP) - LIFE CYCLE

54. EXTREME PROGRAMMING (XP) - PRACTICES
➤ Planning Games: Quickly determine scope of next iteration by taking
into consideration business priorities and estimates.
➤ Small Releases: Deliver quickly and early by have short iterations, first
create a minimum marketable feature and release new versions based on
feedback.
➤ Metaphors: Guide development using simple shared story to eliminate
technical talk.
➤ Simple Design: Just-enough-design policy ie. exact specifications just for
that story. Extra complexity removed once discovered.
➤ Testing: Develop test cases first, then code to test cases, then automate
test cases.
➤ Pair Programming: 2 developers working on 1 story where 1 drives and
the other 1 navigates where they would continuously switch roles.

55. EXTREME PROGRAMMING (XP) - PRACTICES
➤ Re-factoring: Restructure complex/poor structured code without
effecting behaviour, aims to remove duplication, simplify or add
flexibility.
➤ Collective Code ship: Anyone works on any code to avoid knowledge
silos which results in high quality code.
➤ Continuous Integration: Automated builds and tests so the system
checked every time a task is completed.
➤ 40-hour Work Week: No overtime to enable long term productivity
and predictable results.
➤ On-Site Customer/Whole Team: Have a product /business/real life
user on the team to answer questions is a member of the team
➤ Coding Standards: Strict adhere to code standards with rules that
emphasise communication through code.

56. EXTREME PROGRAMMING (XP) - ROLES
➤ Tracker.
➤ Customer.
➤ Programmer.
➤ Tester.
➤ Coach.

57. EXTREME PROGRAMMING (XP) - DISADVANTAGES
➤ Extreme Programming is focused on the code rather than on design. That
may be a problem because good design is extremely important for
software applications.
➤ Lack of defect documentation may lead to the occurrence of similar bugs
in the future.
➤ XP is geared toward a single project, developed and maintained by a
single team.
➤ XP will not work in an environment where a customer or manager insists
on a complete specification or design before they begin programming.
➤ XP will not work in an environment where programmers are separated
geographically.
➤ XP has not been proven to work with systems that have scalability issues
(new applications must integrate into existing systems).

58. KANBAN Toyota

59. SCRUM VS KANBAN
Scrum Kanban
Time-boxed iterations are an essential part Time-boxed iterations are optional
Team commits to a specific amount of work
for each iteration
No such commitment is required
Velocity is the default metric for planning and
managing the project
Lead time is default metric for planning and
managing the project
Cross-functional teams prescribed Specialist teams allowed
Items must be broken down so they can be
completed within a single sprint
No particular item size is required
Burn-down chart used Only the board is used
Implicit WIP limits in a sprint Explicit WIP limits per workflow

60. SCRUM VS KANBAN
Scrum Kanban
Estimation necessary Estimation optional
Cannot add items to ongoing iteration Can add new items whenever capacity is
available
The sprint backlog is owned by the team The Kanban board may be shared by multiple
teams or individuals
Has definite roles Doesn’t have any roles
Uses a prioritized product backlog Prioritization of tasks is optional

61. « Scrum is best-suited for products and
development projects. Kanban is best for
production support.