My presentation from the Lean Kanban Central Europe 2012 conference in Vienna (Oct. 2012). Note that the subject is controversial, though.

1. Attaching Kanban to the
Command & Control World of
Project Managers
Lean Kanban Central Europe 2012
nikolaus.rumm@cellent.at
@nikolaus_rumm

2. Insert
Focus of this session is on IT projects
No silver bullet, though

3. Agenda
• Part I: The problem
– What is project management ?
– Why is it problematic with IT development projects ?
• Part II: Finding the right cure
– What is organizational culture ?
– How does it affect Kanban and project management ?
– How to handle project management and Kanban in the same
organization ?
• Part III: Summary

4. Part I
THE PROBLEM

5. The Project
A collaborative and temporary enterprise,
frequently involving research or design, that is
carefully planned to achieve a particular aim
Usually…
• something singular
• something new
• something risky
• something big
Source: Wikipedia, en.wikipedia.org/wiki/Project

6. Projects are temporary organizations
CEO
• The project‘s organization is a
Procurement Delivery Sales down-scaled version of the
IT Domestic
company‘s organization
Development Sales
• The organizational model is
IT Operations
International
Sales
the hierarchy
• The idea behind it is damage
Customer
Care limitation (risk isolation) and
decomposition
• In fact it‘s a confession that
Project
Manager the company is not able to
Analysis
achieve some aim with the
Dev Team QA Team
Team existing structures

7. Why they invented projects…
Hoover Dam Project Manhattan Project
• Cost: $49 M (1936) • Cost: $2 B (1946)
• Planning time: 5 years • Planning time: 3 years
• Implementation time: 5 years • Implementation time: 4 years
• Consortium size: 6 companies
• Team size: 130,000
• Team size: 5,200

8. …and what we made out of this idea
Call Statistics Report Project CRM Maintenance 2013 Project
• Cost: $6,200 • Cost: $14,000
• Planning time: 3 weeks • Duration: unlimited
• Implementation time: 2 days • Team size: 0.2 FTE
• Team size: 0.5 FTE

9. The awful truth is…
• By 2012 the predominant IT
management model is the
command & control bubble
• Everything is a project with a
price tag
P2
• What‘s not a project is called
P4 overhead and thus considered
P1
P3
P5 inefficient
P8
P6
P7 P11 • The majority of IT projects are
just renamed cost units
P9 P10
• This is a sign of missing trust
between upper and middle
The „weak matrix“ (release 2012)
management

10. Projects focus on Short Term Gain
• The idea of the temporary
organization encourages
The boss
optimization of short-term
Impress her ! gain
• This includes accepting a
Project manager
customer rip-off, even if
we lose the customer after
Do the least acceptable the project has finished
once he signed that contract
• Some project managers
focus on satisfying their
The customer
line manager and not on
the customer

11. Project Managers tend to be Heroes
• Heroic management
• Smooth operations are not good for
heroes
• Possible trouble magnets
• Prone to burnout in larger projects
• Strong bias on dysfunctional
communication
• Note that some employees actually
like that because the hero is
responsible for everything
• „King of the hill“-syndrome
– He who knows everything
– He who plans everything
– He who decides everything

12. Traditional PM requires Planning
The practise of project management
often assumes that right at the
beginning…
– The goals are clear
– The goals are stable
– The planner has complete knowledge
of the problem
– The planner has complete knowledge
of how to achieve the goals
Each assumption is wrong

13. How wrong is your Plan ?
Requirements change at an
average rate of 1-2% per month
Even if you know everything and
elaborate a perfect plan a one-
year project team develops 12-
24% into the bin
Inability to follow the change in
demand automatically implies
reduced quality

14. Project Managers plan Input
• The planning/controlling
object is the work package
• Work packages describe…
– what to do
– who will do it
– when it will start
Henry Laurence Gantt
(1861 – 1919) – when it will be completed
• Co-founder of scientific • Work packages are input
management targets
• Inventor of the Gantt chart (1910)

15. Input Planning
• Input planning focuses on what to do and not on what to achieve
• Input planning is much more complicated and error prone than output
planning
• Assumptions
– Each resource‘s productivity is known for each task
– Each resource‘s productivity is stable
• Both assumptions are wrong
• Productivity variation between developers is 1:10

16. Input vs. Output Planning
Product Product
Output Target Output Target
Vision Vision
Project Project
Output Target Output Target
Goals Goals
Features Output Target Features Output Target
Work
Input Target Ad hoc
Packages
• Less work
• Better quality
Statistical
Schedule Input Target
Control
Product Product
Output Output
Increment Increment Transformation
& Error Source

17. Why do they plan Inputs ?
• Traditional project management is still
influenced by a mechanistic mindset
from the industrial era (i.e. scientific
management)
• Focus on efficiency and labour
productivity
• Patterns
– Find the best way how things are done
– Eliminate variability by standardization
Frederick Taylor – Divide labour until you can downskill the
(1856 – 1915) worker
• These assumptions are not applicable
• Father of scientific management to brain-workers
• All attempts to industrialize software
development have failed

18. Input Planning is not applicable to
Software Development
Construction Project SW Development Project
Plan Very detailed Sketchy
Validation of the plan Formal Informal
IT support available
Dependencies between Very strict Medium
tasks
Variability of productivity Low High
Freedom of choice for the Non-existing High
worker
Changes Few Many
Impact of changes Local Possibly global
Work mode Follow the plan Follow the goal
(even if there‘s a plan)

19. The One-Shot Project Plan
• Note that the principles of project
management require frequent
replanning
• Many projects have no up-to-date
project plan
• Reasons
– Too much effort
– Could surface the bad truth
• The plan is necessary for getting the
approval, but after that no one is
asking for it
• Outdated plans are a clear indication of
cargo cult project management
• Common in organizations that treat
projects as instruments of accounting
and controlling and not for
development

20. Part II
FINDING THE RIGHT CURE

21. Organizational Culture
„How we do things around here to succeed“
• Quite stable
• Very difficult (if you‘re the CEO) if not impossible (if you‘re an
external consultant) to change
• Changing it takes at least 2-3 years
• Attracts or chills possible employees
Source: William E. Schneider, The Reengineering Alternative

22. Assumption #1
All organisations are –
fundamentally – living social
organisms
• Stable core of beliefs, ethics and
principles
• The system reacts to attempts
that pull it off center with
resistance and homoeostasis
• Fundamental changes are
unlikely without a crisis
Source: William E. Schneider, The Reengineering Alternative

23. Assumption #2
Organisational culture is more
powerful than anything else
Leader-
Strategy • Agile implementations must
ship
consider strategy, leadership
and – above all – culture in
Culture order to be sustainable
• If the change is not
sustainable then the change
initiative has failed
Source: William E. Schneider, The Reengineering Alternative

24. Assumption #3
System-focused interventions
work. Component-centered
interventions usually do not.
– The system can’t be decomposed
– Anything we do in agile
management must address the
whole system
Source: William E. Schneider, The Reengineering Alternative

25. Assumption #4
Interventions clearly tied to
business strategy work.
Interventions not clearly tied to
business strategy do not
– Start where you are
– Accept how the company
currently works
– The intervention must accomplish
the company’s purpose and not
that of the change agent
– The others are always more
Source: William E. Schneider, The Reengineering Alternative

26. The Baseline
„If the management idea fits the nature of the
organizational culture it will most likely work.
If not, it will most likely fail.“
• Kanban does not fit to all organizational cultures
• Kanban is less invasive than Scrum, but still a big challenge
for most enterprises
Source: William E. Schneider, The Reengineering Alternative

27. Organizational Culture
We pay attention
to…
Collaboration Culture Presence and Control Culture
Reality
Goal Synergy Goal Dominance
Method Teamwork Method Gain control
Customer Relationship Cooperation Customer Relationship Controlled
Organizational Model Team Organizational Model Hierarchy
Archetype Family Archetype Military
The way we take
Personal decisions is… Impersonal
Goal Improvement Goal Excellency
Method Personal growth Method Growth of expertise
Customer Relationship Fulfilment Customer Relationship Exploit your USP
Organizational Model Network Organizational Model Matrix, ad hoc
Archetype Religion Archetype University
Possible
Cultivation Culture Future Competence Culture
Source: William E. Schneider, The Reengineering Alternative

28. The Six Kanban Practices
• Visualize work
• Limit the work in progress
• Manage flow
• Make policies explicit
• Implement feedback loops
• Improve collaboratively, evolve experimentally
Source: Leopold, Kaltenecker, Kanban in der IT

29. Six Kanban Core Practices
We pay attention
to…
Collaboration Culture Presence and Control Culture
Reality
Make
Feedback
policies
loops
explicit
Visualize
Limit the WIP
work
Scrum ?
The way we take
Personal decisions is… Impersonal
Improve
(based on Manage flow
models)
Kanban focuses on operational excellence
by getting statistical control and improving the
Possible system‘s culture
Cultivation Culture Future Competence Culture

30. Core Processes of Traditional PM
We pay attention
to…
Collaboration Culture Presence and Control Culture
Reality
Project
Initiating
planning
Executing Controlling
The way we take
Personal decisions is… Impersonal
Closing
Traditional project management focuses on getting control
of a team and utilizing them to the highest possible extent
Possible
Cultivation Culture Future Competence Culture

31. Finding the right Cure
• Would you buy a medicine that
claims to help against all diseases ?
• The six Kanban practices have to be
adopted to fit the organizational
culture
• Kanban will fit control
cultures, might be adoptable to
collaboration and competence
cultures and will most likely fail in
cultivation cultures
„If the management idea fits
the nature of the • This is the same compatibility
organizational culture it will pattern as with traditional project
most likely work. management
If not, it will most likely fail.“

32. Kanban Principles
1. Start where you are
– Understand culture, strategy and leadership
– Identify stakeholders, pain points and interests
2. Apply evolutionary, incremental change
3. Initially respect job titles, roles,
responsibilities and processes
4. Encourage leadership on all levels
– Depending on the organizational culture this
might be difficult

33. The usual Stakeholders
Happy customers will help you in
keeping the management buy in
Customer Line
Management
Win the customer Do not betray the line
(reliability, predictability) management (transparency)
Win the end users Project Plan resources and build
End Users (quality, flexibility) Team up creative tension
Stick to the rules Other
Other
Other
(but don‘t overperform) Plan resources Projects
Projects
(availability) Projects
Win
PMO Legacy
Legacy
Legacy
Products
Products Join
Products
Avoid

34. Know your Strengths and Weaknesses
(as compared to traditionally managed projects)
Strengths Weaknesses
• Better control of productivity • No stable plan by definition
• Less variability • Statistical control is not as sexy as direct
• Usually better quality control (for traditional managers)
• Much more flexibility • Some cultures might not like the idea of
• Better integration with legacy a team taking decisions
maintenance and other projects
• Plenty of metrics available
Opportunities Threats
• Users/customers are generally • You‘re a democratic alien in C&C
disappointed of traditionally managed • You‘re a heartless number cruncher in
IT projects collaboration cultures
• Users/customers usually like the way of • You‘re mediocre in competence cultures
working with agile teams • You‘re totally insane in cultivation
• Long-term relationship with the cultures
customer is possible • The PMO usually hates you
• External interventions might erode your
agile implemenentation

35. Strategy 1: The eroding sandwich
Traditional Traditional
Development
Project Release
(Kanban)
Management Planning
Customer IT Operations
• Perhaps the easiest way in established companies
• Pros: easy, less conflict, potential growth in both
directions
• Cons: undermines end-to-end thinking, possible
concurrency with project manager, focuses too much
on process mechanics

36. Strategy 2: Coexistence
Traditionally
managed
project
Kanban
Customer project Line Management
• Perhaps the best way if supported by line management
• Pros: exploitation of the full potential of Kanban possible,
allows the build-up of creative tension with traditional
projects, prevents monoculture
• Cons: might lead to unproductive conflict, totally
depending on line management‘s buy in, requires intense
relationship management with line management, limited
possibilities for cultural change

37. Strategy 3: All-in
Kanban
project
Customer
• Pure Kanban implementation; short term goal in
startups, long term goal in established companies
• Pros: exploitation of the full potential of Kanban
possible, advanced management/leadership principles
possible
• Cons: maybe not the best fit for all customers (and
their cultures) if you are an IT services company

38. Part III
SUMMARY

39. Summary
• Traditional project management has an
impressive track record but is not well-suited for
IT development projects
– Relies on a plan
– Plans input, not output
– Biased on waterfall
– Projects tend to optimize short-term gain
• Traditional project management is about
decomposition and getting control
• Many companies misuse projects for accounting

40. Summary (2)
• Organizational culture is at the core of a company
and influences everything
• If the management idea fits the nature of the
organizational culture it will most likely work;
otherwise it will fail
• Organizational cultures can be divided in
– Command – stick to the rules !
– Collaboration – work together as a team !
– Cultivation – grow !
– Competence – be the best !

41. Summary (3)
• Kanban focuses on getting (statistical) control
of a complex production system (short term
goal) and improving it (long term goal)
• Project management focuses on getting
control of a team and utilizing them to the
highest possible extent (short term goal)
• Both methods have the idea of control, based
on rules and rationale at the core

42. Summary (4)
• Kanban and project management fit well into
command cultures
• Kanban and project management might work in
collaboration and competence cultures
• Kanban and project management will likely fail in
cultivation cultures (use Scrum there ?)
• Kanban and project management can coexist, as
they ultimately are rooted in the same culture

43. Appendix
SOMETHING PERSONAL

44. The Kanban Community
Where do you think that the Kanban community (the
ones that regularly meet at conferences like this one)
best fits into ?
We pay attention
to…
Collaboration Presence and Control Culture
Culture Reality
Personal The way we take Impersonal
decisions is…
Cultivation Culture Competence Culture
Possible
Future
Understand your bias and know your blind spots

45. The Future of Kanban
• Try to attach Kanban to other businesses than IT
• The market for IT processes is very saturated
• There‘s strong demand for such kind of management
in many fields of business
• Integrate people from other disciplines to get fresh
ideas
Learn and grow outside of IT !