LKCE11

It is time for new conference in the Lean Kanban series, Lean Kanban Central Europe at Munich. The venue is beatiful, http://www.kuenstlerhaus-muc.de/english/index.php. Arne and the gang have done excellent job so far and everything looks good and ready.

Tuesday 18.10

Keynote, John Seddon 

John continued quite much on the same aspects as he was talking in LKBE11. Here are some quotes from the session:

Managers are obsessed with managing by cost which is a different world what managing by value, That is the problem

You want to make money? Join IT: this way you can fail and still make big money

Specialization increases hand-0ffs

I hate f***ing tools

What we need to do is teach people how to study the work

On Kanban: swimlanes introduce unneccesary overhead (keeping people there). Limiting Work in Progress increases flow

Monday 17.10 

Karl Scotland: The Science of Kanban

Concept of KFC: Kanban flow in Cadence.
Taylor`s Scientific Management vs. anti-Scientific Management.
Cynefin Model http://www.cognitive-edge.com

Visualization.
Multitasking
Single Loop vs. Douple Loop learning

Process

Flow= SpeedxDensity

Fast Feedback->Smaller Queues->Lower WIP->Faster Flow->Fast Feedback
Life Cycle Profits
Cost of Delay
Lean Startup: Ideas->Build->Code->Measure->Data->Learn->Ideas->…
Asymmetric Pay-Offs

Plan->Do->Check->Act
Observe->Orient->Decide->Act

The Golden Circle Why->How->What http.//www.starwithwhy.com/

ECONOMICS PEOPLE PROCESS -> LEAN in the middle

Katherine Kirk: Kanban and the Importance of Equanimity

Came to Notice – a regular pattern. A failing system wants to change. BUT Kanban=Change, Change=Learning, Learning=Discomfort, Discomfort=Resistance

BBC: Politics and data conversion -> Unexpected reactions

Story1: Managers incentives in conflict

Story2: 1 Month contracts vs cold wet spagetti
Ignore the data! -make us look good to the next quarted
18 months: we might need to change

Story3: I want Kanban as long as I do not have to change

“How am I expected to give this a positive twist to upper management, if your team keep plastering reality over the walls”

“Im glad people are leaving, they keep telling bad news”

Why? Out of comfort zone!

  • People and Change
  • Change is uncomfortable. Example: Continuous Improvement

Time to find out my heritage. Comfort and useless activities? 

  • Obsession with comfort
  • But comfort = boredom
  • Boredom seemed to be irritating
  • Needing lots of distraction and entertainment
But what you do if you live in constant change. Searcing for answer…
We need a thinking model…. Mahasi Vipassana -Theravada. Learning to live with constant change.
First point of learning is equanimity. A thinking model for change. “This is the way it is”. No ego, No attachment to the outcome of method.
Tribe has a sense of equanimity
Expexted Change
Can`t get upset about the wind of the heat
Equanimity gives us perspective http://twitpic.com/71o0ln

Barriers versus borders. Scrum vs Kanban…

The Cause of Suffering http://twitpic.com/71o233
http://twitpic.com/71o2qc

Keynote: David J. Anderson: Predictability&Measurement with Kanban

David is retrospecting on the Kanban history and the road to Munich conference. 

Create a regular delivery cadence
Develop a strong config management capability -key skill to have to be predictable
Develop a capability to deploy effectively – if you are not doing too often, rehearse still as often as possible.
Build Code with high quality – it stuff goes to production and it doesn`t work trust is lost. 

Understanding capability by studying the natural philosophy of the work. People make commitments without understanding the problem. It will help you if you understand the philosophy of the work and environment.  

John Seddon has observed that allocating capacity with Classes of Service “damages capacity!”

Example of major project with two-tiered kanban board. 11 million dollar project from 2007. Simulating S-curve with a Z.

Unplanned Work Report. Dark Matter: most of the companies produce 40-60% of Dark Matter even in sprint. Little`s Law. 

Changing the WIP limit without maintaining the staffing level ratio represents a change to the way of working. It is a change to the system design!

Yuval Yeret: Key points and practices for using Kanban for Enterprise Product Development @yuvalyeret

Classes of Service on Product Development. More classes? Work Types?
Tracking Progress, better collaboration towards a common goal.

Introducing classes of treatment. How to do the work and how to route it internally. ->
Treatment Tags (Flags on kanban board)

Keynote: Kent Beck, Software G Forces (the affects of Acceleration)

 

 

 

 

Similar keynote from this summer. http://www.youtube.com/watch?v=KIkUWG5ACFY

Different Deployment Frequencies:
1990: Annual/Quarterly
2010: More Quarterly, even more daily and hourly
2030: More on Weekly, Daily and hourly.

This is the direction SW world is going. More and more larger deployment move to hourly and minutely cycles.

Causation? More Feedback->Smaller Slices->Shorter Cycles 

How to handle more and more feedback as an organization? This is the learning that needs
to happen to succeed.

Annual to Quarterly

  • Automated acceptance tests
  • Refactoring
  • Continuous Integration
  • Subsciption

 Quarterly to Monthly

  • Developer Testing
  • Stand-Up meetings
  • Cards on a wall
  • Pay per use
           Not needed???
  1. Q/A Department (organizational distance is too expensive)
  2. Multiple deployed versions 
  3. Design Document
  4. Change Request Process
  5. Analysis and Build Teams
Monthly to Weekly
  • Automated data migration
  • Temporary branches
  • Keystoning (hide UI changes to allow functionality growth underneath)
  • Kanban
  • One button deploy
               Not Needed?
  1. Test Team
  2. Design Document
  3. Up-Front usability
  4. Active release branch
Weekly to Daily
  • Immunization
  • Data-Informed usability
  • Feature flags
  • One piece flow (vs. Kanban multistaged pipelines “how can I get rid one of those columns?)
               Not Needed?

  1. Multi (time run out…..)

Daily to hourly
  • Root Cause analysis
  • Deploy on Green 
Nemawashi is the easiest way to achieve continuous deployment.

n

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s