Kanban faces several common arguments against its adoption. These include concerns that Kanban will: 1) Limit the ability to plan work. 2) Cause work to take longer to complete. 3) Result in work getting stuck if work-in-progress limits are enforced. 4) Not align with stakeholder priorities if they do not consider flow. 5) Reduce team cohesion by focusing on individual tasks rather than collaboration.

1. 5
ARGUMENTS
against
KANBAN
@NickOostvogels

2. Kanban is on the rise
Source
:
VersionOne
-­‐
State
of
Agile
Survey
2011

3. When introducing new
ideas…
h"p://www.flickr.com/photos/smannion/3385144016/

4. People compare it
to what they know
h"p://www.flickr.com/photos/mvjantzen/4815422633/

5. … and
start to
criticize
h"p://www.flickr.com/photos/the-­‐g-­‐uk/3913466332/

6. Kanban is hard to explain
briefly
h;p://www.flickr.com/photos/digitalmums/6310508350/

7. That’s normal
• Kanban is a change
management approach,
not a process
• Less prescriptive
• It’s roots go all the way back to
lean thinking

8. What is Kanban?
In Industry
hp://www.flickr.com/photos/scania/2869199313/

9. In Software Development
Change Management
approach
that employs a WIP
limited pull system
hp://www.flickr.com/photos/adelcambre/2768856149/

10. 1. Start with what you now
2. Agree to pursue incremental,
evolutionary change
3. Initially, respect current roles,
responsibilities job titles
Source
:
limitedwipsociety.org

11. then adopt the core practices
1. Visualize
2. Limit Work In Progress
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively
Source
:
limitedwipsociety.org

12. For me …
Kanban is a way
to change your process into one
that focuses on end to end value
and getting stuff delivered.

13. And that’s hard to sell !

14. Available on
Leanpub.com/kanbanforskeptics

15. 5
tough
questions
hp://www.flickr.com/photos/40358860@N04/4250860618/

16. 1.
we lose
our ability
to plan
hp://www.flickr.com/photos/40358860@N04/4250860618/

17. No
estimates?
hp://www.flickr.com/photos/photojonny/2268845904/

18. Customers want estimates

19. estimates are used to decide
hp://www.flickr.com/photos/ol1/4605912815/

20. we manage people by estimates
hp://www.flickr.com/photos/lambdachialpha/3795728748/

21. Typical Release planning
Translation into
Initial
requirements
specs
Estimation
Review
Release
estimations
Plan

22. Issues of software development
• Not a repeatable process
• Never built something alike
• (educated) GUESSING

23. Kanban : measuring

24. Different
sizes ???
hp://www.flickr.com/photos/jaydedman/2593673396/

25. Use a scale
compare

26. Standard size

27. Why sizing?
hp://www.flickr.com/photos/lawdeda/4094259672/

28. Planning with measurements

29. Reduce variation
1. Working with averages
must be reliable
2. Fast response
3. Base for continuous
improvement

30. Small releases
Kanban != continuous deployment

31. Small releases
Kanban can lead to continuous
deployment

32. Won’t this
annoy
our users?
hp://www.flickr.com/photos/photojonny/2268845904/

33. Small releases
NO, because…
• Updates will be smaller
• Risk for bugs is lower
+ Releasing early creates a sense of
urgency

34. options for Re-planning
1. Reprioritize the input queue
2. Cadence
3. Pull a planning meeting

35. 2.
it will
take longer
hp://www.flickr.com/photos/40358860@N04/4250860618/

36. No
deadlines?
hp://www.flickr.com/photos/photojonny/2268845904/

37. Parkinson’s law
“The amount of time which one has to
perform a task …
… is the amount of time it will take to
complete the task.”

38. From a cost perspective
From a value perspective
From an HR perspective

39. Healthy balance in Kanban
Managing by measuring
http://www.flickr.com/photos/wok_design/2499217405/

40. Healthy balance in Kanban
Helping to improve
instead of command control
http://www.flickr.com/photos/wok_design/2499217405/

41. Theory of Constraints
for process
improvement
http://www.flickr.com/photos/96dpi/3371440496/

42. the weakest chain determines
the rate of the entire system

43. the WIP Limits will let
you feel the TOC and
do something about it

44. Flow
• Only work on customer orders
• Reduce guessing to avoid waste
• Limit WIP to reduce inventory,
cost risk
hp://www.flickr.com/photos/23945877@N05/2623633694/

45. WIP limits create
a pull system

46. Isn’t this
inefficient?
hp://www.flickr.com/photos/photojonny/2268845904/

47. NO, it reduces risk waste!
• The risk of starting something that doesn’t
match expectations
• The risk of declining value

48. 3.
Things will
get stuck,
we can’t keep
WIP limits! hp://www.flickr.com/photos/40358860@N04/4250860618/

49. “Our testers can never keep up
the pace of our developers.
Developers would be idle for
half of the time!”
hp://www.flickr.com/photos/wheaKields/4774087006/

50. Remember:
Kanban doesn’t focus on
maximizing utilization of people

51. End to end flow efficiency
hp://www.flickr.com/photos/serdar/125457544/

52. WIP limits will always cause
bottlenecks
That’s a good thing!
It drives continuous improvement
towards end to end efficiency

53. Being idle due to uneven flow distribution
drives people crazy!
h;p://www.flickr.com/photos/annayanev/3491617954/

54. Ex. 1 - Requirements

55. Ex. 2 - Defects

56. Ex. 3 - Deployment

57. Ex. 4 - Emergencies

58. Ex. 4 - Emergencies

59. Collaboration is a cure
for bottlenecks

60. 4.
Stakeholders
don’t care
about feeding
the flow
hp://www.flickr.com/photos/40358860@N04/4250860618/

61. Prioritization doesn’t have
to be on a task level

62. Clear rules make
prioritization easier
• What is the type of feature? (new, bug,
enhance- ment, ...)
• What is the business value?
• What is the cost of delay and which
type?
• Any dependencies on other
features?
• …

63. it forces stakeholders to do their
homework!
hp://www.flickr.com/photos/cayusa/2194119780/

64. Encourages building an MVP
Stakeholders care about
Return on
Investment
hp://www.flickr.com/photos/59937401@N07/5929491095/

65. Stakeholder collaboration

66. Stop relying on status
reports
Visual progress instead

67. focus on economic decisions
instead of fighting for capacity
hp://www.flickr.com/photos/jpeepz/6236688/

68. 5.
we will
lose
team cohesion
hp://www.flickr.com/photos/40358860@N04/4250860618/

69. Won’t the team turn
into factory workers?
hp://www.flickr.com/photos/psit/5207166416/

70. WIP limits lead to
cross-boundary communication

71. Good teams have a
common goal
hp://www.flickr.com/photos/atomicshed/161716498/

72. Good teams have a
common goal
Vertically organized
companies lead to teams
with conflicting goals
hp://www.flickr.com/photos/atomicshed/161716498/

73. in Kanban, everybody
contributes to the
end 2 end process
hp://www.flickr.com/photos/saamiam/4203685689/

74. this is a powerful change
management approach
• no theoretical frameworks
• no new job descriptions
• only some basic rules

75. What about
creative
thinking?
hp://www.flickr.com/photos/photojonny/2268845904/

76. The focus on improving
flow stimulates creativity
• Team will start to investigate
• Limit back-cycles
• Lead Cycle time measuring
stimulates close collaboration

77. Won’t it
cause a
death
march?
hp://www.flickr.com/photos/photojonny/2268845904/

78. Measurements are used to
understand reality
have a base for improvement
hp://www.flickr.com/photos/usnavy/6083504722/

79. Not pushing to go faster
but improving end 2 end
hp://www.flickr.com/photos/rwp-­‐roger/3854246685/

80. Now you have a response!
1. We lose our ability to plan
2. It will take longer
3. Things will get stuck
4. Stakeholders don’t care about
feeding the flow
5. We will lose team cohesion

81. Thanks!
http://leanpub.com/
kanbanforskeptics
@NickOostvogels

82. 6.
Software
development is
not manufacturing!
hp://www.flickr.com/photos/40358860@N04/4250860618/

83. Kanban has
it’s roots in
the Toyota Production System
That’s why it feels so right for
support teams.

84. It feels different
in product development

85. not all lean manufacturing
principles are valid for product
development
hp://www.flickr.com/photos/chrism70/104302940/

86. Instead fast feedback loops are
more interesting
Removing waste by truncating a
bad path quickly

87. Product development characteristics:
• creative thinking
• continuous testing of new ideas
• seeking as much feedback as possible
• intense discussions

88. Lean product development:
• Strong leadership
• Cross-functional teams
• Set-Based Concurrent Engineering
• Short feedback loops
• Focus on the customer and supplier
• Cadence, Pull, and Flow

89. The application differs in Lean
• Product development
• Manufacturing
The same way it differs in Kanban for
• Software development
• Support operations

90. Nevertheless they are built on the
same principles!

91. Thanks!
http://leanpub.com/
kanbanforskeptics
@NickOostvogels