KANBAN and Scrum - Mixing both to develop a better approach to develop software.

1. Naveen Kumar Singh
Agile coach and consultant

2.  Software Developer, Agile coach and Trainer,
 Certified Scrum Practitioner (CSP), CSM, PMI-ACP, PMP
 More than 17 Years of experience in Software development
 Reach out to me
 LinkedIn - in.linkedin.com/in/naveenkumarsingh1/
 Twitter - https://twitter.com/naveenhome
 Mail – naveenhome@gmail.com
 Blog - scrumcertifications.blogspot.in

3. To Do In Progress Done

5. •Scrum Master
•Product Owner
•Team
Roles
•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Ceremonies
•Product backlog
•Sprint backlog
•Increment
Artifacts

6. To Do In Progress Done

7. Toyota Production System
 “The two pillars of the Toyota
production system are just-in-
time and automation with a
human touch, or autonomation.
The tool used to operate the
system is kanban.”
 Taiichi Ohno, Toyota Production
System (adopted 1962)

8. Kanban promotes continuous
collaboration and encourages active,
ongoing learning and improving by
defining the best possible team
workflow

9. Kanban Principles
 Visualize your work
 Limit WIP
 Manage Flow
 Test as soon as “DONE”
 Dealing with Bottlenecks

10. To Do In Progress Done

11. Visualize your work

12. Limit WIP

13. Manage Flow

14. To Do In Progress Done

15. Start with something simple
Easy to start if following Scrum, XP, FDD
Challenges while following Scrum
eXtreme Programming (XP) helps

16. Challenges with Scrum – Scrum doesn’t not talk about a particular
workflow during development
XP – Gives us a nice concrete model to work from. Basically a scaled
down implementation of V model workflow

17. XP model
Write
Story
Write
Test
Design
Write
Unit
Test
Write
Code
Run
Unit
Test
Validat
e
Design
Run
Story
Test

18. SCRUM-BAN
This can be useful for existing Scrum teams who are looking to improve
their scale of capability.
This can also be useful for more cautious new users who find comfort in
an “established” method.
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

19. SCRUM-BAN
The Idea of using a simple task board with index cards is as old as Agile
itself. A simple variation of this task board with simple
Pending -> In Process -> Complete workflow.
The cards represent work items in current scope of work.
Name can be associated with the cards to indicate who’s working on
what.
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

20. SCRUM-BAN
The simple approach is to start with Scrum like iterations and iteration
planning processes, and begin to add pull features to the team’s internal
process.
White board Vs Electronics tools
White board – easy and simple, no cost but nothing to prevent you from
accumulating a big pile of WIP
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

21. SCRUM-BAN
Just as an unregulated index card on a cork board is not a Kanban, time-
boxed iteration planning is not pull. No reasonable interpretation of lean
involves building to a one month forecast unless the cycle time is one
month.
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

22. To Do In Progress Done

23. Kanban Daily StandUp Meetings
Team size 20-50
Meeting facilitator enumerates work, not people
People who are available and eligible to operate a workstation are
expected to attach to any stations that have capacity according to board.
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

24. Cycle time Vs Lead time
Lead time clock starts when the request is made and ends at delivery.
Cycle time clock starts when work begins on the request and ends when
the item is ready for delivery. Cycle time is a more mechanical measure
of process capability. Lead time is what the customer sees.
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

25. Release Early and Release Often
Determine the minimum deployable feature set, and then build that as
fast as you can
Reference – SCRUMBAN – Essay on Kanban Systems for Lean Software Development

26. To Do In Progress Done

27. KANBAN SCRUM
No prescribed roles
Pre-defined roles of Scrum master,
Product owner and team member
Continuous Delivery Timeboxed sprints
Work is ‘pulled’ through the system
(single piece flow)
Work is ‘pulled’ through the system
in batches (the sprint backlog)
Changes can be made at any time No changes allowed mid-sprint
Cycle time Velocity
More appropriate in operational
environments with a high degree of
variability in priority
More appropriate in situations
where work can be prioritized in
batches that can be left alone

28. Shorter cycle times can deliver features faster.
Responsiveness to Change
When priorities change very frequently, Kanban is ideal.
Balancing demand against throughput guarantees that most the
customer-centric features are always being worked.
Requires fewer organization / room set-up changes to get started
Reducing waste and removing activities that don’t add value to the
team/department/organization
Rapid feedback loops improve the chances of more motivated,
empowered and higher-performing team members