20121023 lkce 2012

Attaching Kanban to the Command & Control World of Project

Managers

Lean Kanban Central Europe 2012

[email protected]@nikolaus_rumm

Insert

Focus of this session is on IT projectsNo silver bullet, though

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

THE PROBLEMPart I

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

Projects are temporary organizationsCEO

Procurement Delivery

IT Development

IT Operations

Customer Care

Sales

Domestic Sales

International Sales

Project Manager

Analysis Team Dev Team QA Team

• The project‘s organization is a down-scaled version of the company‘s organization• The organizational model is

the hierarchy• The idea behind it is damage

limitation (risk isolation) and decomposition• In fact it‘s a confession that

the company is not able to achieve some aim with the existing structures

Why they invented projects…

Hoover Dam Project

• Cost: $49 M (1936)• Planning time: 5 years• Implementation time: 5 years• Consortium size: 6 companies• Team size: 5,200

Manhattan Project

• Cost: $2 B (1946)• Planning time: 3 years• Implementation time: 4 years• Team size: 130,000

…and what we made out of this idea

Call Statistics Report Project

• Cost: $6,200

• Planning time: 3 weeks

• Implementation time: 2 days

• Team size: 0.5 FTE

CRM Maintenance 2013 Project

• Cost: $14,000• Duration: unlimited• Team size: 0.2 FTE

The awful truth is…• By 2012 the predominant IT

management model is the command & control bubble

• Everything is a project with a price tag

• What‘s not a project is called overhead and thus considered inefficient

• The majority of IT projects are just renamed cost units

• This is a sign of missing trust between upper and middle management

P1

P2

P3

P4

P5P6

P7P8

P9 P10

P11

The „weak matrix“ (release 2012)

Projects focus on Short Term Gain

• The idea of the temporary organization encourages optimization of short-term gain

• This includes accepting a customer rip-off, even if we lose the customer after the project has finished

• Some project managers focus on satisfying their line manager and not on the customer

The customer

The boss

Project manager

Do the least acceptable once he signed that contract

Impress her !

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

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

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

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– when it will be completed

• Work packages are input targets

Henry Laurence Gantt(1861 – 1919)

• Co-founder of scientific management

• Inventor of the Gantt chart (1910)

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

Input vs. Output Planning

Project Goals

Project Goals

Product Vision

Product Vision

Features

Work Packages

Features

Product Increment

Product Increment

Ad hoc

Schedule Statistical Control

Output Target

Output Target

Output Target

Input Target

Input Target

Output

Output Target

Output Target

Output Target

OutputTransformation& Error Source

•Less work•Better quality

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– Divide labour until you can downskill the

worker

• These assumptions are not applicable to brain-workers

• All attempts to industrialize software development have failed

Frederick Taylor(1856 – 1915)

• Father of scientific management

Input Planning is not applicable to Software Development

Construction Project SW Development ProjectPlan Very detailed SketchyValidation of the plan Formal

IT support availableInformal

Dependencies between tasks

Very strict Medium

Variability of productivity Low HighFreedom of choice for the worker

Non-existing High

Changes Few ManyImpact of changes Local Possibly globalWork mode Follow the plan Follow the goal

(even if there‘s a plan)

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

FINDING THE RIGHT CUREPart II

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

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


Assumption #2

Organisational culture is more powerful than anything else

• Agile implementations must consider strategy, leadership and – above all – culture in order to be sustainable• If the change is not

sustainable then the change initiative has failed

Culture

Leader-shipStrategy


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


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


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


Organizational Culture

The way we take decisions is…Personal

We pay attention to…

Impersonal

Presence and Reality

Possible Future

Goal Dominance

Method Gain control

Customer Relationship Controlled

Organizational Model Hierarchy

Archetype Military

Goal Synergy

Method Teamwork

Customer Relationship Cooperation

Organizational Model Team

Archetype Family

Goal Improvement

Method Personal growth

Customer Relationship Fulfilment

Organizational Model Network

Archetype Religion

Goal Excellency

Method Growth of expertise

Customer Relationship Exploit your USP

Organizational Model Matrix, ad hoc

Archetype University

„We succeed by being the

best“

Be the best !

„We succeed by getting and

keeping control“

Stick to the rules !„We succeed by working

together as a team“

Collaborate !

„We succeed by growing

people who fulfil our vision“

Grow !

Collaboration Culture Control Culture

Cultivation Culture Competence CultureSource: William E. Schneider, The Reengineering Alternative

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

Six Kanban Core Practices



Impersonal


Possible Future


Cultivation Culture Competence Culture

Visualize work Limit the WIP

Manage flow

Make policies explicit

Feedback loops

Improve (based on models)

Scrum ?

Kanban focuses on operational excellence by getting statistical control and improving the system‘s culture

Core Processes of Traditional PM



Impersonal


Possible Future



Controlling

Closing

Initiating

Executing

Project planning

Traditional project management focuses on getting controlof a team and utilizing them to the highest possible extent

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

• This is the same compatibility pattern as with traditional project management

„If the management idea fits the nature of the

organizational culture it will most likely work.

If not, it will most likely fail.“

Kanban Principles

1. Start where you are– Understand culture, strategy and leadership– Identify stakeholders, pain points and interests

2. Apply evolutionary, incremental change3. Initially respect job titles, roles,

responsibilities and processes4. Encourage leadership on all levels– Depending on the organizational culture this

might be difficult

Legacy ProductsLegacy

Products

Other Projects

Other Projects

The usual Stakeholders

ProjectTeam

Line Management

Customer

End Users

Other Projects

Legacy Products

PMO

Stick to the rules (but don‘t overperform)

Win the end users(quality, flexibility)

Win the customer(reliability, predictability)

Do not betray the line management (transparency)

Plan resources(availability)

Plan resources and build up creative tension

Happy customers will help you in keeping the management buy in

Win

Avoid

Join

Know your Strengths and Weaknesses(as compared to traditionally managed projects)

Strengths• Better control of productivity• Less variability• Usually better quality• Much more flexibility• Better integration with legacy

maintenance and other projects• Plenty of metrics available

Weaknesses• No stable plan by definition• Statistical control is not as sexy as direct

control (for traditional managers)• Some cultures might not like the idea of

a team taking decisions

Opportunities• Users/customers are generally

disappointed of traditionally managed IT projects

• Users/customers usually like the way of working with agile teams

• Long-term relationship with the customer is possible

Threats• You‘re a democratic alien in C&C• You‘re a heartless number cruncher in

collaboration cultures• You‘re mediocre in competence cultures• You‘re totally insane in cultivation

cultures• The PMO usually hates you• External interventions might erode your

agile implemenentation

Strategy 1: The eroding sandwich

• 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

Traditional Project

Management

Customer IT Operations

Traditional Release Planning

Development (Kanban)

Strategy 2: Coexistence

• 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

Traditionally managed project

Customer Line ManagementKanban project

Strategy 3: All-in

• 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

Customer

Kanban project

SUMMARYPart III

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

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 !

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

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

SOMETHING PERSONALAppendix

The Kanban Community

Where do you think that the Kanban community (the ones that regularly meet at conferences like this one)

best fits into ?

The way we take decisions is…

Personal


Impersonal


Possible Future

Collaboration Culture

Control Culture


Understand your bias and know your blind spots

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 !

20121023 lkce 2012

Business

acceptablethe project

practise of project

planning time

projects organization

years implementation

fte team size

days team size

companies team size