tps lean and agile - brief history and future

55
TPS, Lean and Agile Brief History and Future Kiro Harada Attractor Inc. 8/11/2014 HCMC 9/11/2014 Hanoi

Upload: kiro-harada

Post on 29-Jun-2015

3.458 views

Category:

Software


1 download

DESCRIPTION

Talk at Agile Tour HCMC and Hanoi How we changed the way to work together and how we found TPS, Lean and Agile methods to improve.

TRANSCRIPT

Page 1: TPS Lean and Agile - Brief History and Future

TPS, Lean and Agile Brief History and Future

Kiro Harada Attractor Inc.

8/11/2014 HCMC 9/11/2014 Hanoi

Page 2: TPS Lean and Agile - Brief History and Future

History of Our Jobs

Page 3: TPS Lean and Agile - Brief History and Future

We were Hunters

http://commons.wikimedia.org/wiki/File:PRIMITIVE_MAN_HUNTING_ANIMALS_at_the_Museum_of_Vietnamese_History.JPG

Page 4: TPS Lean and Agile - Brief History and Future

We also were Farmers

http://www.flickr.com/photos/yuyasekiguchi/8413666440/

Page 5: TPS Lean and Agile - Brief History and Future

Then…

http://en.wikipedia.org/wiki/Lists_of_people_by_occupation

Page 6: TPS Lean and Agile - Brief History and Future

Number of Professions

28,275 Occupation Names are registered

in Ministry of Labor in Japan

Page 7: TPS Lean and Agile - Brief History and Future

We’d improved by Specialization

Page 8: TPS Lean and Agile - Brief History and Future

In early 1900’s,

We decided to go further in specialization:

Thinkers and Doers

Page 9: TPS Lean and Agile - Brief History and Future

Managers and Workers

Page 10: TPS Lean and Agile - Brief History and Future

Scientific Managementimproving economic efficiency, especially labor productivity by applying science to the engineering of processes and to management.

Frederik Taylor

Page 11: TPS Lean and Agile - Brief History and Future

Manufacturing Line

Page 12: TPS Lean and Agile - Brief History and Future

A Manager for Managers?

Page 13: TPS Lean and Agile - Brief History and Future

Management Hierarchy

http://commons.wikimedia.org/wiki/File:Tabulating_Machine_Co_Organization_Chart.jpg

Page 14: TPS Lean and Agile - Brief History and Future

and it worked GREAT!

Page 15: TPS Lean and Agile - Brief History and Future
Page 16: TPS Lean and Agile - Brief History and Future

Is Specialization for Improvements?

Page 17: TPS Lean and Agile - Brief History and Future

Hawthorne Experiment

http://en.wikipedia.org/wiki/Hawthorne_effect

Page 18: TPS Lean and Agile - Brief History and Future

What causes Productivity?

http://www.library.hbs.edu/hc/hawthorne/

Page 19: TPS Lean and Agile - Brief History and Future

Informal Organization

Page 20: TPS Lean and Agile - Brief History and Future

Organizational Sabotage

Page 21: TPS Lean and Agile - Brief History and Future

New Profession: Programmer

Ada Lovelace

Page 22: TPS Lean and Agile - Brief History and Future

Management the Development of Large Software Systems

a.k.a. Waterfall Method

Page 23: TPS Lean and Agile - Brief History and Future

We’d tried to run Software Dev just like Manufacturing Factories

http://en.wikipedia.org/wiki/KUKA#mediaviewer/File:BMW_Leipzig_MEDIA_050719_Download_Karosseriebau_max.jpg

Page 24: TPS Lean and Agile - Brief History and Future

but did not work

Challenged 54% Cancelled

32%

Successful 14%

Chaos Report / 1994

Page 25: TPS Lean and Agile - Brief History and Future

See what Winston Royce actually said:

I SYSTE M

I ANALYSIS

PROGRAM DESIGN

I c o o , . o

TESTING

I OPERATIONS

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.

However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.

329

I SYSTE M

I ANALYSIS

PROGRAM DESIGN

I c o o , . o

TESTING

I OPERATIONS

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.

However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.

329

Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: In: Technical Papers of Western Electronic Show and Convention

(WesCon) August 25–28, 1970, Los Angeles, USA. in 1970

Page 26: TPS Lean and Agile - Brief History and Future

The Machine that Changed the World

Toyota’s Secret Weapon in the Global Car Wars

Page 27: TPS Lean and Agile - Brief History and Future

Lean Manufacturing

the expenditure of resources in any aspect other than the direct creation of value for the end customer to be wasteful, and thus a target for elimination.

Page 28: TPS Lean and Agile - Brief History and Future

7 Wastes - Muda 無駄Transportation

Inventory

Motion

Waiting

Over-Processing

Over-Production

Defects

Page 29: TPS Lean and Agile - Brief History and Future

Toyota Production System

Figure curtesy of Satoshi Kuroiwa

Page 30: TPS Lean and Agile - Brief History and Future

Multi-skilled Worker

Skill Map with Training Plans

Page 31: TPS Lean and Agile - Brief History and Future

How TPS was born…

Page 32: TPS Lean and Agile - Brief History and Future

Toyoda Type G Automatic Loom (1924)

http://commons.wikimedia.org/wiki/File:1924_Non-Stop_Shuttle_Change_Toyoda_Automatic_Loom,_Type_G_1.jpg

Page 33: TPS Lean and Agile - Brief History and Future

Toyota was almost bankrupt in 1950’s.

A major labor dispute resulted in resignation of most executives including the founder Kiichiro Toyoda.

They had no money to buy extra machines, lines, parts and hire managers.

Page 34: TPS Lean and Agile - Brief History and Future

TWI Program in WW II (Training Within Industry)

Page 35: TPS Lean and Agile - Brief History and Future
Page 36: TPS Lean and Agile - Brief History and Future

To make your work

Easier and Safer

Page 37: TPS Lean and Agile - Brief History and Future

Software Crisis

Page 38: TPS Lean and Agile - Brief History and Future

New New Product Development Game

https://hbr.org/1986/01/the-new-new-product-development-game/ar/1

Page 39: TPS Lean and Agile - Brief History and Future

Scrum:Ordered Backlog

Fixed Time-Boxes

Demo or Die

Swarming

Page 40: TPS Lean and Agile - Brief History and Future

Swarming

Page 41: TPS Lean and Agile - Brief History and Future

Agile ManifestoWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

Page 42: TPS Lean and Agile - Brief History and Future

Conway’s Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

—M. Conway

Page 43: TPS Lean and Agile - Brief History and Future

Organization Architecture and Product Architecture

Page 44: TPS Lean and Agile - Brief History and Future

How Software had actually been Developed?

Page 45: TPS Lean and Agile - Brief History and Future

Inverse of ControlsDon’t Call Us, We’ll Call You.

Page 46: TPS Lean and Agile - Brief History and Future

What happened to Organization Structure

Page 47: TPS Lean and Agile - Brief History and Future

Informal became less Informal

Page 48: TPS Lean and Agile - Brief History and Future

Community

Page 49: TPS Lean and Agile - Brief History and Future

Improve Productivity Quality by Stopping Specialization

People are naturally multi-skilled.

Swarm of People

Kaizen Mind

Page 50: TPS Lean and Agile - Brief History and Future

Trend continues…

Page 51: TPS Lean and Agile - Brief History and Future

DevOps

Figure curtesy of Tomoharu Nagasawa, Atlassian Evangelist

Ideas / Feedbacks�

Working Software / Deployment Pipeline�

Deployment�

Monitoring�Prioritize�

Development�

Page 52: TPS Lean and Agile - Brief History and Future

Lean Startup

Idea�

Build�

Code (Product) �

Measure�

Data�

Learn�

Page 53: TPS Lean and Agile - Brief History and Future

Self-Organization

https://www.youtube.com/watch?v=LzjifmHavAQ

Page 54: TPS Lean and Agile - Brief History and Future

http://qz.com/196200/toyota-is-becoming-more-efficient-by-replacing-robots-with-humans/

Page 55: TPS Lean and Agile - Brief History and Future

Future

Swarming of various skilled people works

Utilize automation for repeatable processes

Trend continues to eliminate current borders

Communities will be more and more important.

We seek for better collaboration that scale not by skill specialization.