Kanban Board – Massimizzare il flusso

Come accennato nel post precedente sulle Split Columns della Kanban Board in VSO, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è:

Maximize Throughput while Minimizing Inventory and Operating Expense.

In questo post vorrei fare una precisazione sul concetto di Flusso e Throughput, di centrale importanza per il metodo Kanban. Se avete letto The Goal sapete benissimo che uno degli scopi principali di una azienda è fare soldi, punto! Sembra cinico, ma senza un flusso di cassa costante, potete avere delle idee bellissime, essere innovativi, brillanti, ma sicuramente avrete difficoltà nel realizzare le vostre idee.

Nel software, quando andiamo a declinare il metodo Kanban, che ricordo essere nato in un contesto manifatturiero (Toyota), bisogna capire cosa intendiamo con il termine throughput. Facciamo però prima un semplice ragionamento in ambito manifatturiero, pensando ad una azienda che produce elettrodomestici. Supponiamo che la azienda usi Kanban, il flusso sia ottimale e le linee di produzione lavorino in maniera efficiente, i colli di bottiglia sono stati individuati, etc etc.

La domanda interessante che ci si deve porre è questa: se si vuole massimizzare il flusso dell’azienda, bisogna definire in maniera inequivocabile quale sia lo stato finale della nostra Kanban board, altrimenti rischiamo di non trovare colli di bottiglia. Facciamo un esempio in cui consideriamo come ultima colonna della Kanban lo stato “imballato”, che identifica quando il nostro elettrodomestico è stato imballato e pronto per la vendita.

Possiamo da subito capire che probabilmente questo non è corretto, se per qualche ragione il nostro magazzino non è efficiente, rischiamo di accumulare prodotti in magazzino senza essere in grado di farli pervenire ai distributori. In questo modo, se il magazzino è il collo di bottiglia, esso non verrà individuato, e ci accorgeremo dei problemi quando gli elettrodomestici “imballati” non hanno più posto dove essere stoccati.

Ok! Per risolvere consideriamo come ultima colonna Kanban una nuova colonna chiamata immagazzinamento, in questo modo se il magazzino diventa saturo, essendo Kanban un metodo pull, le linee di produzione dovranno fermarsi, dato che il magazzino non è più in grado di accettare pezzi. Anche in questo caso, se in alcuni periodi dell’anno quel tipo di elettrodomestici si vede di meno (frigoriferi in inverno), rischiamo di riempire il magazzino perché i grossisti non hanno bisogno di nuova merce.

Piano piano ci si rende conto che idealmente, l’ultima colonna Kanban per la nostra azienda fittizia, dovrebbe essere “venduto al cliente”. Ora è chiaro che ragionare in questi termini è decisamente difficile, ma se nel nostro monitoraggio del processo non consideriamo che il nostro elettrodomestico deve essere venduto ad un cliente finale, si rischia di non vendere, non fare soldi, e fallire.

Tornando quindi al concetto iniziale: Throughput!! Se seguiamo le indicazioni di Goldratt, dobbiamo accertarci che quando parliamo di flusso, stiamo includendo tutti gli stadi fino a quello che ci permette di fare soldi per far vivere l’azienda!

Cosa implica questo in Kanban applicato ai processi software? Che nella nostra Kanban Board, l’ultima colonna deve essere, per lo meno, Usabile in Produzione, ovvero il software deve essere rilasciato e disponibile al cliente finale. Se ci dimentichiamo di questo, rischiamo di accumulare una grande quantità di lavoro “finito” ma che non è usabile dal cliente/utente finale, e che quindi non può generare soldi.

Ricordate quindi che in Kanban la massimizzazione del flusso è fondamentale ed è altrettanto fondamentale che nel flusso si considerino tutti gli stadi, dall’idea alla produzione!

In realtà nemmeno questo alla fine è realmente sufficiente e capiremo perché nel prossimo post.

Gian Maria.

0  

Articolo su Unit Testing su SQLServerCentral.com

Nell’articolo seguente andremo ad approfondire le procedure di unit test tramite l’utilizzo di tSQLt con SQL Server.

L’articolo è disponibile su SQLServerCentral.com ed è reperibile qui.
Aspetto vostri commenti.
Stay Tuned! 

TFS2015 Build vNext

Nel lontano 2010, TFS2010 introduceva una nuova build, basata su Workflow Foundation, la quale andava a rimpiazzare la vecchia build di TFS 2008 basata su script MSBuild.

Personalmente debbo dire che ho sempre preferito la vecchia versione del 2008, soprattutto per la facilità di estensione. Mentre per Workflow Foundation è necessario usare Visual Studio ed addentrarsi in un designer non proprio semplice, personalizzare una build MSBuild è una operazione piuttosto semplice, alla fine si tratta solamente di file xml.

Chiaramente XML non è il linguaggio migliore per creare uno script, per cui nel corso degli anni molte persone hanno abbandonato questa strada a favore di Powershell, sicuramente più flessibile ed estendibile. Una build infatti non è altro che una sequenza, quasi sempre lineare, di operazioni da eseguire partendo dai propri sorgenti per ottenere dei risultati (build, test, deploy, etc) e quale migliore scelta dell’esecuzione di una serie di script PowerShell per definire una build?

Per questa ragione in TFS2015 la build è stata nuovamente modificata, per adattarsi a queste nuove richieste e sicuramente risolverà molti problemi emersi negli anni passati con l’attuale struttura di build. Dedicherò quindi una serie di post alle novità della build, cosi da potervi mostrare cosa ci aspetta nella prossima versione di TFS.

Build web experience

La novità più succosa e la prima che amo descrivere, è che tutta la configurazione e la gestione della build è completamente web. Niente più necessità di Visual Studio per editare una build, basta andare nella nuova voce di menu Build vNext e potrete gestire tutto dal vostro browser preferito.

image

Premendo il bottone per aggiungere una build viene subito presentata una possibile scelta tra due template già pronti, uno per una solution di Visual Studio, ed un altro per eseguire la build di Xcode.

image

Fin da subito possiamo quindi vedere che l’altra grande novità riguarda il fatto di poter avere agent di build che girano anche su macchine non Windows. La configurazione degli agent sarà appannaggio del successivo post, per cui non ci soffermeremo ora su questo aspetto.

Se scegliamo la build di Visual Studio si aprirà un editor web da cui si può configurare ogni aspetto della build.

image

Il primo tab da impostare è quello del Repository in cui basta selezionare repository git che volete utilizzare. Per questa CTP ancora è possibile solamente eseguire build vNext su team project basati su Git, nella versione finale si potrà usare anche TFVC.

image

La cosa interessante è che si può usare la build vNext per compilare qualsiasi repository git, anche su gitHub se necessario. La default Branch indica quale è la branch che verrà compilata di default per le build accodate manualmente.

Il successivo tab sarà quello dei Triggers, su cui si può indicare se si desidera la Continuous Integration (build ad ogni change), se si vuole accorpare più commit in un unica build (Batch changes) e chiaramente la possibilità di specificare tutte le branch che si vogliono monitorare, ad esempio in questo caso ho chiesto di monitorare ogni branch che comincia per feat-.

image

Una volta impostato il repository, si può direttamente fare il browsing da web per scegliere la o le solution che si vogliono compilare.

image

Nel tab dei test basta introdurre una regular expression che identifica gli assembly di test ed il gioco è fatto. Se si vogliono eseguire test differenti da MsTest, si hanno due scelte, la prima è specificare il percorso relativo dove trovare i test adapters, operazione che potete effettuare direttamente nelle opzioni del task di test.

image

Se invece usate nunit in tutti i vostri progetti e si vuole evitare di personalizzare ogni build di ogni progetto, si può andare nelle macchine dove è installato l’agent, aprire la cartella dove è localizzato il test runner di visual studio e copiare al suo interno i test adapters dopo averli scaricati dalla gallery di Visual Studio.

image

A questo punto si è creata una build minimale che esegue Build e Test run, interamente da interfaccia web con pochi semplici click. Se nell’installazione di TFS 2015 avete scelto di configurare il build agent automaticamente, potete direttamente lanciare una build e verificare che sia tutto ok.

image

Come si può vedere la build viene eseguita e potete verificarne l’output ed il progresso direttamente dall’interfaccia web.

Gian Maria.

Lean Startup, the art of Customer Development: pretotype

Una startup è un grande esperimento, pensato per validare la nostra idea e definire un business sostenibile che ci consenta di rendere profittevole la nostra iniziativa.

Questa è la definizione che stiamo utilizzando nei vari post legati a Lean Startup, andandone a fotografare le fondamenta e sfatando il mito che una startup è un’azienda in miniatura a cui è possibile approcciare in modo tradizionale.

L’obiettivo è, quindi, quello di validare scientificamente se la nostra idea è “sostenibile”, ovvero se riesce ad attrarre una serie di potenziali utenti (categorie) che sono disposti ad utilizzare i prodotti annessi e a pagare per i servizi a valore annessi. In funzione di ciò è naturale parlare di Customer Development,l’approccio ideato da Steve Blank e alla base di Lean Startup che lo combina con le pratiche Agili.

Nello specifico, Blank identifica due step operativi ben precisi: Search & Execution.

search execute extended

customer development

Search & Execution

Nella Search phase, la startup è alla ricerca di un Business Model che consenta di sviluppare la propria Vision, facendo evolvere costantemente la propria strategia ed effettuando i necessari PIVOT. Qui strumenti come il Lean Canvas e il Business Model Canvas trovano una naturale collocazione e possono essere sfruttati al massimo. Nella Execution phase, la startup ha convalidato il proprio modello di business ed il proprio prodotto, apprestandosi ad organizzarsi per consolidare il proprio business, utilizzando principalmente il Business Model Canvas.
Quello che Blank evidenzia sin dalla scelta del nome è che tutto gira intorno ai clienti (early-adopters, paying customers, ecc..), “utilizzati” come “validatori” delle ipotesi messe sul piatto.

In Lean Startup in a Nutshell, abbiamo visto come lo strumento principe per interagire con i clienti è il Minimum Viable Product (MVP) che, in funzione di quanto appena detto, gioca un ruolo fondamentale soprattutto nella fase di Search (Customer Discover e Customer Validation). Eric Ries, indica genericamente come MVP un insieme molto eterogeneo di strumenti: da una fake-webpage a un video di presentazione, per arrivare ai prototipi e poi a soluzioni incrementali funzionanti realizzate con approcci Agili.

In realtà è possibile classificare più di dettaglio gli artefatti legati alle due fasi in discussione, scindendo dagli MVP i cosiddetti “pretotype”, ovvero delle fake-solutions pensate per testare le nostre ipotesi senza dover realizzare fattivamente un prototipo del nostro prodotto. A coniare il termine “pretotype” è stato Alberto Savoia che, dualmente, si è preoccupato anche di definirne le caratteristiche fondamentali:

  • Be able to test a product hypothesis with minimal resources, ovvero consentire di testare le proprie ipotesi relative a un prodotto con il minimo utilizzo di risorse;
  • Accelerate learning, accelerare l’apprendimento;
  • Reduce wasted engineering hours, ridurre lo spreco dovuto ad una prematura ingegnerizzazione;
  • Get the product to early customers as soon as possible, rendere disponibile la soluzione agli early-adopters il prima possibile.

Come si vede sono tutte caratteristiche comuni agli stessi MVP, allora qual è la differenza? La differenza è che qui, come accennato, la soluzione è un fake assoluto (richiedendo un effort implementativo assolutamente irrisorio), ma sufficiente ad effettuare una prima e veloce validazione delle nostre ipotesi. Solo quando abbiamo identificato una prima strada percorribile è conveniente cominciare a lavorare ad un vero e proprio MVP, che, dovendo “testare” la reazione dei clienti nei confronti di un prodotto tangibile, anche se minimale, richiede il coinvolgimento di un vero Team di development organizzato in chiave Agile.

In linea di massima, sono individuabili sei tipologie di pretotype:

  • In Person Interview / Proposal, si tratta di camuffare un prodotto esistente e proporlo sotto forma di uno nuovo, in modo da verificarne l’interesse. E’ una tecnica su larga scala che richiede un’ampia esposizione e, di conseguenza, un ampio rischio per il brand;
  • Smoke test: Landing Page + Adwords, consiste in una pagina web minimale utilizzata per confutare l’interesse verso una nuova soluzione presentandola in modo semplice e invitando l’utente, ad esempio, ad inserire la propria email per ottenere maggiori informazioni. Stesso discorso per mini-campagne Adwords in cui, banalmente, contare il numero di click;
  • Explainer Video, viene utilizzato un video che spiega il comportamento del futuro sistema;
  • Fake Door, pensato per misurare la % di utenti interessati ad un prodotto non ancora realizzato, ma pubblicizzato tramite una campagna minimale (es: Google ADV o
  • Pinocchio (Mockup), utile per testare la forma e l’estetica di un nuovo prodotto;
  • Mechanical Turk, pensato per testare l’interesse verso un prodotto particolarmente complesso da realizzare. Si pensi ad un software di intelligenza artificiale il cui appeal può essere verificato simulandone il funzionamento tramite operatori reali che rispondono all’interazione dell’utente.

Al di là della soluzione scelta, l’aspetto fondamentale è che si tratta di artefatti estremamente semplici che possono essere realizzati senza il supporto di un Team di development, andando a sfruttare strumenti comuni o tool appositi come (es: LeadPages.net). Un esempio di startup che ha sfruttato la tecnica dello Smoke Test è Groupon.

Una volta effettuata la prima convalida e/o i primi Pivot, possiamo passare agli MVP veri e propri, andando a verificare delle ipotesi più strutturate e consentono anche di coprire fattori tecnologici.

DotNetCampus 2015 a Roma, non mancate!

Il 30 Maggio 2015 tornerà il DotNetCampus, la più grande conferenza italiana sul mondo .NET Con i suoi oltre 9000 iscritti in quattro edizioni. 

Dotnethell.it sarà presente, non solo come sponsor, ma anche con il sottoscritto. Parlerò di Continuous Integration su database, nella track ALM.

Vi aspetto numerosi anche a Roma, così cogliamo l’occasione per fare due chiacchiere su questo topic che interessa il mondo dello sviluppo su database sempre di più.

Cosa troverete?

Le sessioni sono suddivise in track tematici paralleli e tenute da speaker di fama nazionale ed internazionale. L’evento, organizzato dal gruppo DevLeap, richiama l’interesse delle testate di settore e della stampa nazionale garantendo agli sponsor una visibilità senza eguali.
L’agenda è suddivisa in sessioni sulle varie tecnologie attuali e future. Le sessioni parallele sono inserite in differenti track consentendo ai partecipanti di scegliere per ogni slot l’argomento di maggior interesse. 
Gli argomenti della prossima edizione ruoteranno intorno a queste tematiche: 
- sviluppo web/cloud
- accesso ai dati
- Windows 8
- Windows Phone 8
- design della user interface
- pattern e metodologie
- ciclo di vita del software (ALM e DLM) 
- metodologie Agile


Che novità ci saranno quest’anno?

- Sul sito potrete pubblicare il Vostro profilo, le Vostre storie di successo e potrete proporre un’idea o un progetto che verrà valutata dagli sponsor per possibili collaborazioni. 
- Troverete inoltre gli annunci di lavoro inseriti dagli sponsor.
- Durante la conferenza saranno previsti vari momenti in cui gli studenti potranno visitare i booth degli sponsor, lasciare i propri curricula, presentarsi e ottenere informazioni sull’azienda. 
- Gli sponsor di livello Gold o superiore potranno prenotare una saletta nella quale effettuare colloqui, incontrare studenti, effettuare presentazioni, godere di maggior spazio.
- Durante la giornata, ove specificato, sarà possibile partecipare a laboratori didattici in cui gli studenti verranno guidati dallo speaker nella realizzazione di una applicazione reale.
Per maggiori info leggete qui
Il mio consiglio è di registrarvi il prima possibile. Ci si vede a Roma!
Stay Tuned! 


Novità di VSO Sprint 79

Come sempre potete leggere tutte le novità sul blog di Visual Studio Online, precisamente a questo indirizzo, ma per chi si fosse perso il post, ecco le novità che sono ora disponibili. In questo sprint il team si è focalizzato nel risolvere alcuni issue di UserVoice che hanno un numero elevato di voti e che sono quindi sentiti come molto importanti da parte della community. Questo significa che, come sempre dico a tutti, il team legge i suggerimenti di User Voice, per cui se qualche cosa non vi soddisfa, quello è il posto migliore per dare i vostri suggerimenti.

Finalmente, dopo tanto tempo, ecco arrivare il parametro @currentIteration, che vi permetterà di fare delle query sui Work Item assegnati alla iterazione corrente. Purtroppo questo parametro non funziona in Excel.

Le novità più importanti riguardano però la Kanban Board, la quale supporta ora il riordinamento delle card, operazione molto importante per la prima colonna, che rappresenta il BackLog.

La modifica più importante è però l’introduzione della Definition of Done per le colonne della Kanban Board. Tornerò sull’importanza di questa funzionalità in un successivo post.

Un’altra importante aggiunta è la possibilità di visualizzare i bug come task nella Taskboard e considerarli logicamente figli dei vostri requisiti.

Come potete vedere il team di Visual Studio ALM continua, sprint dopo sprint, a migliorare il prodotto.

Happy VSO.

Gian Maria.

0  

Kanban Split Column

Finalmente in Visual Studio Online sono stati introdotti alcuni miglioramenti alla Kanban Board, che per lungo tempo era stata lasciata senza sensibili miglioramenti. In questo ultimo update di VSO è stato introdotto una funzionalità realmente fondamentale, che aumenta di molto la possibilità di usare realmente la Kanban Board in TFS/VSO.

Il cambiamento di cui sto parlando è l’introduzione delle Split Columns, ovvero la possibilità di suddividere ogni colonna in due sotto-colonne, rispettivamente Doing and Done. Vediamo il perché questa funzionalità è cosi importante.

Si parte da un presupposto: Kanban è un processo PULL, in cui ogni stadio decide di prendere in carico una card dallo stato precedente, se e solo se non ha raggiunto il suo limite e se tutte le regole sono soddisfatte (regole aggiuntive e Definition of Done). Questo è il segreto e la base su cui poggia Kanban, ogni stadio inizia a lavorare su un task solamente se ha modo di farlo. Questo viene fatto per evitare ingorghi nel processo e per massimizzare il flusso. Lo strumento principale di Kanban è la Board, che deve permettere immediatamente di individuare i problemi affinché il team possa affrontarli.

Ora analizziamo la situazione seguente:

image

La situazione rappresentata ci dice che: le colonne di Analysis e Committed sono attualmente piene (3/3), quindi non è possibile aggiungere del Work In Progress a nessuna delle due colonne. La domanda che ci si pone è: lo stadio di Analysis non può prendere in carico nessun nuovo item, ma i tre item che sono attualmente nella colonna sono stati terminati o no?

La risposta alla domanda precedente è di fondamentale importanza. Supponiamo i due casi estremi. Caso A: i tre item nella colonna Analysis sono tutti “in progress” questo significa che la colonna Analysis è in stato di pieno regime. Caso B: i tre item nella colonna Analysis sono completati e pronti per lo stadio successivo, questo significa che la colonna Analysis è paralizzata, dato che non può prendere in carico nuovo lavoro fino a che la colonna successiva (Committed) non prende in carico ancora del lavoro. Purtroppo dalla Kanban Board precedente è impossibile discernere i due casi.

Senza entrare nei dettagli, stiamo toccando quella che è chiamata teoria delle code che stabilisce modelli matematici per predire l’avanzamento in una catena di processi. L’identificazione delle code è fondamentale in Kanban, ed è una delle ragioni principali per l’adozione stessa del metodo.

Il metodo Kanban ha come scopo la massimizzazione del flusso ed in questa ottica l’individuazione delle code è un’operazione di massima importanza.

D’altra parte, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è: Maximize Throughput while Minimizing Inventory and Operating Expense. La declinazione nello sviluppo software non appare sempre semplice, se da una parte è chiara la parte di minimizzare le Spese (Operating Expenses), si può anche intuire la massimizzazione del flusso (Maximize Throughput, concetto su cui tornerò in un post successivo), è difficile capire come minimizzare lo stoccaggio (Minimizing Inventory), dato che alla fine il codice non occupa spazio :).

Kanban ci aiuta a rispondere a questo problema adottando la tecnica dello split column. Nel nostro account VSO, se premiamo il Customize column troviamo una nuova opzione per le colonne.

image

Quello che accade è che ogni colonna viene ora suddivisa in due sotto-colonne, Doing e Done; questo ci permette di iniziare ad individuare le code nel nostro sistema. Vediamo allora come sarebbero rappresentati i due casi precedenti adottando questa nuova funzionalità. Il CasoA: sarebbe cosi rappresentato

image

è chiaro che il sistema sta larvando bene, tutte le colonne sono impegnate e a pieno regime. Il CasoB avrebbe invece una rappresentazione molto differente.

image

Si è creata una coda tra gli stati di Analysis e Committed, dato che abbiamo la colonna Analysis bloccata dal fatto che il lavoro nella colonna Committed non sta proseguendo, per questo non vengono prese in carico (pull) le card terminate in Analysis e questo fa si che la colonna Doing di Analysis sia vuota e bloccata. Tutte le card che sono nella colonna Dona rappresentano infatti card in Coda per lo stadio successivo e possono essere paragonate a quello che Eliyahu Goldratt chiama Inventory in “The Goal”.

Se siamo d’accordo che è necessario minimizzare le code ed evitare che il lavoro si accumuli nelle colonne “done”, senza questa funzionalità, è impossibile capire dalla nostra Kanban Board se siamo nel CasoA oppure nel CasoB e si perde una informazione di vitale importanza.

Un altro valore secondario dello split column è permettere in maniera semplice allo stadio successivo, di capire quali card dello stadio precedente possono essere prese in carico. Senza la colonna Done infatti, quando si libera uno spazio nella colonna Committed, non è ben chiaro dalla Board quali card dello stadio precedente (Analysis) possono essere prese in carico, perché non si ha la distinzione tra ciò che è in corso d’opera e ciò che invece lo stadio precedente ha completato.

Gian Maria.

Comments Off  

Lean Startup in a Nutshell, parte 6 – Tools & Platforms

startup toolsCon questo post andiamo a chiudere la serie “Lean Startup in a Nutshell”, dando uno sguardo a tool e piattaforme utili soprattutto al mondo delle startup IT. La premessa è d’obbligo: le startup non sono legate esclusivamente al mondo dell’Information Technologies, così come non lo è Lean Startup.

E’ possibile affermare che, con rare eccezioni, lo strumento principe è una piattaforma Cloud (come accennato nel primo post della serie) che consente di creare una infrastruttura IT in modo rapido e dinamico, estendendola progressivamente e pagando solo per il suo reale utilizzo. I principali vantaggi dell’utilizzo del Cloud sono:

  • Pay-per-use & Continuous Innovation: si paga solo ciò che realmente si consuma, contenendo al minimo le spese e accedendo da subito a tecnologie all’avanguardia;
  • Mobilizzazione del Capitale, passaggio dalle spese in conto capitale (CapEx) alle spese operative (OpEx);
  • Riduzione del Time-to-Market, ovvero del tempo che intercorre dall’ideazione di un prodotto alla sua effettiva commercializzazione/disponibilità;
  • Scalabilità, Affidabilità e Sicurezza, garantite in modo costante;
  • Riduzione della Complessità Operativa, semplificando il modello di costo e abbattendo drasticamente i relativi costi operativi di gestione.

Ma gli strumenti a disposizione delle startup sono molteplici, e i campi a cui afferiscono vanno da quelli del coding al marketing: Building/Coding, Domain and Website Management, eCommerce, Design, Mobile, All Things Content, Social Media, Marketing Resources, Business/Legal Tools and Resources, ecc.

Volendo dare delle indicazioni, senza la pretesa di creare una lista delle soluzioni migliori (cosa umanamente impossibile visto anche che le alternative aumentano ad un ritmo giornaliero), possiamo individuare i seguenti tool da combinare alle varie esigenze di Lean Startup:

  • Validate Learning
    • MVP (prototipizzazione rapida): MockFlow, Balsamiq, PowerPoint, Visual Studio LightSwitch (BizSpark program)
  • Innovation Accounting:
    • Brand Value: Mention, Microsoft Power BI;
    • Social Media Presence Management: Buffer;
    • Social Media Influencers: Followerwonk;
    • Customer Satisfaction and Collaboration: Intercom, Freak, Streak
  • Build-Measure-Learn:
    • Team and Stockholders communication: Slack e VisualStudioOnline Team Room;
    • Application Lifecycle Management: Asana, VisualStudioOnline, Jira (GreenHopper);
    • Application Coding: Heroku, Visual Studio (BizSpark program)
    • IT Infrastructure: Microsoft Azure (BizSpark program), Google Cloud Platform for Startups, Aruba Cloud Startup

La maggior parte delle soluzioni proposte offrono piani gratuiti, spesso particolarmente generosi, che consentono di accompagnare la propria startup nella crescita e nella trasformazione in un’azienda con un business sostenibile.

 

asana  mockflow

heroku bizspark

Startup tools & platforms

Si conclude così il nostro viaggio introduttivo nel mondo di Lean Startup, viaggio in cui abbiamo evidenziato la validità dell’approccio proposto da Ries per la creazione di un business sostenibile che coniughi l’intuizione (Vision) degli imprenditori con gli strumenti indispensabili al suo raggiungimento.

Some love to Kanban Board in TFS

Nell’ultimo update di VSO che è stato effettuato ieri (http://www.visualstudio.com/news/2015-feb-18-vso) sono finalmente state fatte importanti modifiche alla Kanban Board, che era rimasta un po ferma da troppo tempo a mio avviso.

La prima novità è che è possibile aggiungere gli item direttamente dalla board, ma sicuramente la funzionalità piu succosa è la divisione delle colonne in doing e done. Non starò qui a sottolineare l’importanza di questa funzionalità, dato che senza la possibilità di capire quali Item sono realmente fatti e sono pronti per essere presi (pull) dalla colonna successiva, la Kanban board ha poco valore.

Nell’upgrade vi sono anche altre novità, tra cui la possibilità di assegnare piu persone alle test suites, e l’annuncio che le funzionalità di Application Insights saranno migrate nel nuovo portale di azure. Il nuovo link di riferimento per Application Insights è quindi il seguente: http://azure.microsoft.com/en-us/services/application-insights/

Happy VSO e buon fine settimana. Smile

Lean Startup in a Nutshell, parte 5 – Growth Engine

engineL’approccio scientifico proposto da Lean Startup consente di validare le proprie ipotesi, accelerando quanto più possibile il loop build-measure-learn. Finora abbiamo posto l’enfasi sul creare il “giusto” prodotto/servizio in linea con la Vision, rispondendo alla seguente domanda:

  • A value hypothesis: What product or service will satisfy that demand?

Ma la strategia scelta deve, inoltre, confutare una ulteriore e fondamentale ipotesi:

  • A growth hypothesis: How can growth be made sustainable so that it happens without requiring new funding?

che ci proietta sulle questioni inerenti la crescita del proprio business, andando a trasformare rapidamente, anche se gradualmente, il nostro “esperimento” in un’azienda in grado di generare e sostenere profitto.

strategy 2 values

Strategy: 2 values

Si tratta di ricercare un modello di crescita dipendente dal contesto che, per forza di cose, può evolvere in qualcosa di decisamente complesso. Tale attività rientra nelle “cose noiose” che sono il succo dell’Innovation Accounting, fondamentali per il successo del nuovo business.

La crescita passa, banalmente, dall’acquisizioni di nuovi clienti. Tale processo è ben rappresentato da Steve Blank (“The Startup Owners Manual”) che definisce tre step fondamentali per attuarlo, andando a coniare l’acronimo: GKG: Get (Customer) Keep (Customer) Grow (Customer). In sintesi l’obiettivo primario è quello di acquisire (GET) un numero iniziale di clienti sufficienti a sostenere il proprio business, creando le condizioni per fidelizzarli (Keep) e quelle affinché si riesca ad ottenere una crescita sostenibile (Grow) che porti nuove risorse finanziare da investire in nuovi esperimenti.

Durante la fase di crescita bisogna fare particolare attenzione ai nuovi fattori, spesso in contrasto:

  • esigenze dei clienti attuali;
  • ricerca di nuovi clienti;
  • gestione (aggiustamento) dell’attuale modello di business;
  • esplorazione di nuovi business model.

Tali fattori (non esclusivi) vanno bilanciati attraverso pratiche di gestione (anche qui, Innovation Accounting docet), come:

  • gestione oculata delle risorse, finite ma garantite. Un budget eccessivo può portare a rilassarsi, mentre è fondamentale che quello allocato non venga tagliato al fine di garantire una tranquillità nelle attività;
  • concedere autonomia nello sviluppo. I Team impegnati nella sperimentazione devono essere relativamente liberi di organizzarsi e provare nuove soluzioni;
  • stimolare e premiare i dipendenti. Stock options e bonus sono un buono strumento per spronare i dipendenti a dare il meglio di se.

Blank propone di approcciare al GKG secondo lo schema seguente:

gkg

The Startup Owner’s Manual”: Get-Keep-Grow

in cui le varie fasi possono contare su una serie di tool e soluzioni, ben riassunte nella figura seguente:

gkg explined

GKG tools and solutions

La crescita, in particolare, garantisce la trasformazione della startup in un’azienda consolidata, grazie alle revenue annesse e alla possibilità di investire in nuovi progetti/iniziative/servizi. Non sorprende, quindi, la sua trattazione esplicita in Lean Startup, che si concentra sui cosiddetti motori di crescita (Growth Engines) da applicare al proprio “esperimento” ed inquadrabili in due modelli fondamentali:

  • Jump-start Engine, basati su azioni una tantum, come, ad esempio, l’acquisto di ADV slot sui più noti motori di ricerca;
  • Sustainable Engine, basati su azioni che generano un flusso continuativo di crescita.

Soprassedendo sul modello “Jump-start”, di facile comprensione, il modello “sostenibile” è suddivisibile in tre specifiche categorie:

  • Sticky: i clienti che provano il prodotto/soluzione decidono di utilizzarlo regolarmente (es. acquisti ripetuti o abbonamenti). Questo modello di crescita spinge la startup a concentrarsi sui clienti che ha già acquisito: un cliente felice vale più di 100 passaggi pubblicitari!
  • Viral: basato sul passaparola (word of mouth), diretto o indiretto. Nel primo caso l’utente fa da promotore esplicito del prodotto, nel secondo è l’utilizzo implicito che contagia gli altri (side effect: l’esempio più ricorrente è il colore delle cuffie bianche dell’ipod che ne hanno spinto le vendite). La “misura del contagio” può essere fatta attraverso un viral coefficient (VC), ovvero il numero dei nuovi utenti generati dai vecchi:
    • VC molto inferiore a 1, il trend di crescita è breve. Si immagini di avere VC=0.1, ciò significa che 100 utenti ne portano 10, quei 10 ne porteranno 1 e poi l’effetto virale termina;
    • VC uguale (o molto vicini) ad 1, il trend di crescita è costante;
    • VS maggiore di 1, crescita esponenziale.

L’ideale è che ogni cliente “contagi” almeno 1 nuovo utilizzatore (meglio più di uno, chiaramente) a provare il prodotto/servizio.

Tale motore è particolarmente difficile da attuare perché richiede che il prodotto superi le attese stesse dei clienti e che il target di riferimento sia perfettamente inquadrato: in caso contrario l’effetto virale termina rapidamente e il numero di clienti tende presto a stagnarsi;

  • Paid Growth: ottenimento di nuovi clienti tramite investimento diretto. La forma più comune di questo approccio è, banalmente, la pubblicità, ma possiamo anche citare l’impiego dei call center o l’apertura di sedi di rappresentanza in punti strategici particolarmente trafficati. Il fattore predominante è il profitto marginale, ovvero la differenza tra il valore totale del cliente (lifetime customer value , il profitto legato al cliente) e il costo marginale (costo di acquisizione del cliente).

Questo motore richiede che si verifichi costantemente la copertura dei costi: finché si ottiene un profitto su ogni cliente, è possibile investire i profitti stessi in ulteriore pubblicità per accelerare la crescita.

Ovviamente, i modelli di growth engine possono essere combinati, ma per ottenere delle metriche specifiche che ne convalidino i risultati (Actionable Metrics) è fondamentale che si riesca a misurare puntualmente il loro effetto. Bisogna, inoltre, tener presente che un growth engine va legato ad un breve/periodo di riferimento, dopodiché può perdere rapidamente efficacia rendendo necessario un rinnovamento di strategia o, in extremis, un PIVOT.

Prima di concludere è cruciale evidenziare che quando l’azienda passa da uno stato di startup ad uno stato “consolidato”, non è ovviamente più possibile fare esperimenti continui sul prodotto o sulla soluzione core, dovendo garantire un alto livello di qualità ai propri clienti. In tal caso è opportuno approcciare una (mini) divisione o un (mini) Team che ha il compito di continuare a sperimentare soluzioni innovative parallelamente al core business.

Con questo quinto appuntamento ci avviamo alla fine della serie, lasciano spazio nel prossimo ed ultimo post ad una rassegna di tool e piattaforme che facilitano l’applicazione dei concetti di Lean Startup.