Sunday, January 28, 2007 

Value and Learning

I wrote about Software and Value before, but the subject is vast and there is so much more to say.
We develop software to deliver value (to the customer and to our own company). Unfortunately, that value is often not well defined, measured, and planned.
By planned, I mean that our modeling, implementation, testing activities should be somewhat arranged so that at any moment, if we have to stop and deliver, we'll deliver the maximum value. This is easier said than done (see also another old post on features Vs. value. In many cases, the planning (if there is any planning) works exactly against this aim. Time is initially spent on some (hopefully) important infrastructure, so a value / time chart would look more like

than
.

In a sense, a lot of well-intentioned agile guys are just aiming at bringing the value chart closer to fig. 2. However, I see many cases where this is simply not possible, as there is no sensible way to split your task in smaller chunks with a measurable value for the customer. We can pretend that it is not true, and shoehorn those projects into a process built around quick delivery of small features; I don't think that's particularly clever.
What should we do then? Well, my current answer would be: if you can't optimize your plan for value, optimize for learning.
Now, again, a very common stance in the agile camp is that learning comes from frequent releases and user feedback. In this sense, optimizing for learning won't help much when optimizing for value is not an option, as you need to deliver something to the user (therefore some value) to learn anything.

However, learning doesn't come uniquely from the users. It's just a matter of what you need to learn. If you need to learn about requirements, or more broadly about the problem, users' feedback is certainly a good way. Still, you may have something to learn on the technological side as well. For instance, as we have very few workable quantitative methods, performances are often determined experimentally. Therefore, optimizing your plan for learning requires that you invest your time to get, as soon as possible, a rough approximation of performance figures. In other cases, we're not after performance but after precision, or we need to familiarize with some COTS components or libraries, or with legacy code, and so on.

There are many opportunities to revisit a plan to improve the learning curve. So, even in some worst-case scenario, you may find your value curve to look like fig. 1, but you can improve your learning curve to look more like fig. 2. That won't be so bad after all :-).
Note that all this makes sense only if you (and your company) accept the idea that a plan is a working tool, not a promise cast in stone. Otherwise, learning won't help make better decisions, steering the project, and taking chances along the road to optimize value.

Some homework: what is the role of design in different value/time and learning/time scenarios? Where, and how, it is ideally expected to take place? How is all this stuff related to the dog / skunk / colt / cow / bull classification of projects from Todd Little? Can we use it to rethink a bull project as a colt + cow?
Comments:
mi sembra che manchino le immagini
 
Se ci si riferisce alle immagini dei grafici, io le vedo benissimo.
 
Le motivazioni del principio "optimize for value" mi risultano chiare cosi' come il vantaggio di passare dal grafico di fig.1 a quella di fig.2. Riconosco di non averci mai pensato!
Non mi sono chiare invece quelle di "optimize for learning". Mi e' chiaro che quanto piu' si conoscano il dominio applicativo, il problema, l'utente e la tecnologia che si vuole usare tanto piu' utile (=di valore?) sara' la soluzione. Ed e' anche chiaro che tanto prima questo avvenga tanto meglio sara'. Ma questo e' un "vecchio" principio di design, di ogni design. Il principio "optimize for learning" si riferisce ad altro?
Inoltre proprio questo studio iniziale mi pare sia quello che rende la curva del valore di un progetto piu' vicina alla figura 1 che non alla figura 2. Come si compongono le due cose? Puoi spiegarmi meglio?
 
L'argomento non e' semplice quanto puo' sembrare.
Riprendo la frase in italico, aggiungendo un grassetto:
if you can't optimize your plan for value, optimize for learning.
In questo senso possiamo gia' derimere una parte del quesito: io suggerisco di ottimizzare per il learning quando non riusciamo ad ottimizzare per value, quindi non c'e' un vero rischio di trasformare la curva del valore da fig.2 a fig.1, perche' e' gia' come da fig.1.
Perche' ottimizzare per learning? Perche' lo sviluppo del software e' una attivita' di acquisizione di conoscenza. Gran parte della "cattiva fama" del design upfront e' in realta' ascrivibile ad un design prematuro, ovvero basato su troppa poca conoscenza.
Ottimizzando per learning, non solo si limita il problema di cui sopra: si aprono piu' rapidamente nuove opportunita' (o se ne chiudono rapidamente alcune fallimentari). Da cui la necessita' di piani flessibili, che accolgano cio' che impariamo strada facendo.
E' relativamente difficile parlare di queste cose in senso astratto, quindi provo a fare un piccolo esempio, estrapolando da un recente caso reale.
Dobbiamo riuscire a caricare modelli piu' grandi di quanto la RAM del pc possa accettare (in attesa di un passaggio a 64 bit). Ottimizzare per valore e' arduo: in un certo senso, la prima versione che riusciremo a realizzare e' gia' un tentativo di fornire un early value ai clienti (ovvero non puntiamo subito al massimo, ma ad un gradino intermedio).
Abbiamo a disposizione strategie realizzative diverse, alcune piuttosto tradizionali, altre piuttosto creative. In realta' non abbiamo alcuna idea del reale impatto prestazionale delle varie soluzioni (sappiamo che ci sara' - e' un classico trade/off space/time).
Un approccio allo sviluppo semplice e spesso adottato e':
- design di una soluzione flessibile che permetta di sostituire la strategia senza grandi sconvolgimenti
- implementazione della strategia piu' promettente
[ - eventuale delivery ]
- implementazione ed esame [eventualmente differito] delle alternative.
Questo approccio, tuttavia, non ottimizza per learning (lascio a voi pensare ad un approccio XP-like, considerando che quella sopra e' una feature non ulteriormente divisibile).
Un approccio diverso e':
- ricerca delle modifiche comunque necessarie alla base di codice esistente, qualunque sia la tecnica poi adottata.
- ricerca delle modifiche a maggior impatto prestazionale.
- implementazione di queste modifiche; eventuale test di regressione; selezione di modelli significativi e performance test. Nel caso reale, le performance finali saranno comunque peggiori di queste, quindi qui abbiamo gia' un primo momento importante: potremmo decidere che l'intera strada e' infruttuosa e accettare il costo connesso con altre strade precedentemente scartate.
- ecc ecc (diventerebbe un po' lungo :-).
Da notare che ad un certo punto un design flessibile salterebbe comunque fuori (un po' piu' avanti). Avendo imparato qualcosa nel frattempo, in genere questo design sara' piu' semplice di quello prodotto dalla strategia iniziale (anche se non ispirato ad uno "You Ain't Gonna Need It" [YAGNI] che trovo pretestuoso quanto un o "You Are Gonna Need It" [sempre YAGNI :-)]).
Come dicevo, l'argomento e' piuttosto articolato, ma spero di aver chiarito meglio alcune cose; sicuramente mi capitera' di tornarci su nuovamente in futuro.
 
I know you have and like a lot the book "The Laws of Software Process" by Armour because you've written about it in the past (and a lot of your blogging effort resolve around its concept).

Go back to section "XXXX is Event-Driven", you will find that:

"XXXX are driven more by what is actually learned than by what is expected to be learned"

Finding what XXXX is is left as an exercise for the reader ;-p

P.S.: I resisted a few days and than I gave up and commented
 
I guess I forgot to mention that I'm particularly fond of chapters 1-5 of the book. Your quote, my friend, happens to be from chapter 6 :-)). [sounds a little suspicious, but it's actually true :-)]
That said, we shouldn't forget (or ignore) that for "cow" projects (high complexity - low uncertainty) the need to be event-driven is not so strong, and we may look for more profitable dynamics. Which is my usualy point: shoehorning everything into an agile approch is not, in my view, agile.
 
yeah, you are right (in fact I quite like chapter 7 too...).

Shoehorning anything into anything is not a reasonable approach, I agree. My comment was more of a "silly joke" but I guess you already knew that ;-)
 
Post a Comment

<< Home