Lean and contracting situations – Mary Poppendieck

post il 3-1-2007 RE: [leandevelopment] Budgeting a Lean Project

Tal,

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.

Mary Poppendieck

Università, in fila per filosofia. “Così si diventa buoni manager”

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.’

L’utilizzo del prodotto fa emergere nuovi requisiti

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.