due post il 31-12-2006 e 1-1-2007
Re: [APM] Management lineage of software processes
Interestingly, the Toyota Production System (TPS) was already doing most of what we now call agile, already back in the 1970s.
The west didn’t notice what they were doing and misinterpreted it. (most of) Those of us who wrote the agile manifesto in 2001 were not aware of TPS, and simply wrote what was on our minds. Since then, many of us have looked at TPS — and I for one, can’t see that we’ve added very much to what was already in TPS (test-first comes to mind as an exception).
Re: [APM] Management lineage of software processes
Thanks, Boris. Well, I have three times visited a place in SLC(O.C.Tanner) where they are implementing TPS pretty strictly in their awards production, and I am unable to to suggest anything that they haven’t already been doing for over a year. I.e., TPS already leads them to everything I know.
Personally, I think it’s pretty nifty that we in software managed to reinvent our own localization of the ideas of TPS without knowing first about TPS. It doesn’t bother me if Toyota got there first (over a 60-year period). I think the ideas are there to be found by multiple groups of people … the math adds up, reflection and inspection lead there.
But the only reason I brought this all up was that someone asked about the sequencing of ideas and influences. AFAIK, we software people were not particularly influenced by Deming or TPS in coming up with the agile manifesto (I can speak for myself — my information came strictly from staring at my interview results and management attempts in the early/mid 1990s … I suspect the same was true for at least most of the people at the Snowbird meeting). And still, looking at time sequencing, it is clear that lean manufacturing got there first. I still don’t know about Deming’sstuff.
post il 3-1-2007 RE: [leandevelopment] Budgeting a Lean Project
It seems that you are in a contracting situation, as opposed to developing software for use within your own organization. If I can make that assumption, then I would suggest that lean principles are not particularly viable unless lean contracting is also part of the equation. When you reach organizational barriers and lean organizations run up against non-lean organizations, it is often impossible for the supplier to act in a lean manner.
As an example, many automotive suppliers have adopted lean practices in order to supply Toyota. The lean areas of their plants are much more efficient and cost-effective, but they are usually not able to supply other automobile companies with the lean area of the plant – they have to maintain a non-lean (and less efficient) area of the plant to serve those other customers. Why? Because the Detroit automotive companies still want parts delivered in large batches – they thin the economies of scale are the dominating factor in their business, despite decades of evidence to the contrary.
Similarly, if you have customers that believe that accumulating huge batches of detailed requirements is the most efficient way to contract with suppliers, then you may have to operate in a non-lean way with those customers. When you find customers that want a lean supplier, you can partner with them in a lean way, and as the automotive suppliers found out, deliver better, more cost effective software. However, in general, the choice lies with the customer, not the supplier.
Corriere della Sera, cronaca di Milano, 26 agosto 2006
“Consiglia a tutti gli studi filosofici Franco Tatò:
‘Ai ragazzi dico: non abbiate il complesso dell’ingegnere. Con la filosofia si sviluppa la capacità di sintesi, si confrontano le situazioni, si imparano le lingue (molti testi non sono tradotti). Sono questi i requisiti di un buon manager. […] Anche perché le nozioni acquisite diventano presto obsolete, tanto vale imparare un buon metodo di lavoro e avere una testa che funziona.’
da “Mondo Digitale” anno V n° 2 – Giugno 2006 – articolo “La comunità virtuale degli esaminatori ECDL”, di Daniela Maria Ricco, Giuseppe Giliberto, Giuliano Russo, pag.51:
“[…]l’uso di strumenti e le modalità di esecuzione dei compiti si influenzano a vicenda. Carroll e Campbell [Carroll J.M., Campbell R.L.: Artifacts a psycological theories: The case of human-computer interaction. In “Behaviour and Information Technology”, 1989 – sic -] hanno messo in evidenza il carattere circolare della relazione artefatti-compiti (task-artifact cycle): le persone svolgono determinati compiti, con maggiore o minore soddisfazione, usando determinati strumenti. I nuovi strumenti, una volta adottati, alterano i compiti per cui vennero progettati e modificano le situazioni in cui i compiti venivano svolti in precedenza. In questo modo lo strumento nuovo crea un nuovo compito e una nuova situazione sociale in cui si svolge il compito. Questi ultimi generano poi a loro volta il bisogno di ulteriori miglioramenti che sarebbero possibili grazie ad una nuova famiglia di artefatti da inventare per svolgere meglio il nuovo compito e così via.”
In “Communications of the ACM”, June 2006, l’articolo “A Systematic Approach in Managing Post-Deployment System Changes”, di David Kang e Roger Chiang, affronta l’argomento in modo più operativo, e fornisce indicazioni utili per un’implementazione organizzativa della gestione dei cambiamenti.
Mary Poppendieck insiste ripetutamente sull’esigenza di passare da una visione per progetti ad una visione di product development.