Risks?!? TimeBox them!

Do you know why one of the pillar of  SCRUM is the time-boxing technique? Do you know the parkinson’s law or the student syndrome?

---

As you probably know, SCRUM uses the timeboxing technique to limit the time necessary for “everything”.

The meetings for example:

• Planning (aka kick-off): 8 hrs
• Daily (aka review): 15 mins
• Demo (aka phase gate): 4 hrs
• Retrospective (aka CPI – continuous process improvement meeting) : 3 hrs

The most important thing that SCRUM timeboxes, however, is the Sprint.

A predefined time (usually 2/4 weeks) used by the team, to implement the system/product/service, achieving part of the project objectives (those with the highest priority in that moment).

Within the sprint, indeed, all the meetings above reported are instantiated as already described here.

Why SCRUM locks in such a strong way the project timings?

Oh, maybe because the founders (Jeff Sutherland and Ken Schwaber) and the communities that developed the framework, known very well the parkinson’s law and the student syndrome!

The law of Parkinson cites “Work expands so as to fill the time available for its completion“. How many times do you verify that even if a project is ahead of schedule, the earned value remained 99% till the end planned?

What Parkinson wrote, is, again, totally confirmed by the student syndrome. It, infact, refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline.

This is what the most part of students tend to do, me included, studying for an exam just few days before attending to it. Even if this will restrict them to study also every nights till the exam itself.

When instead the time is limited and the things to do are defined and well understood (even if avoiding an excessive grade of details), the people involved feel that like a challenge, a moment to test themselves, their expertise, the way how they collaborate and solve emerging problems.  A big chance for personal and professional growth.

The high grade of commitment aforementioned and the prioritizing approach in selecting the things to do, aim to two main advanteges:

• Realising faster the most valuable functionalities that the customer needs for its business
• Drastically lowering of the risks

Regarding this last point, having a short feedback cycle between the team and the customer thanks to limited duration of the sprint, helps the stakeholders involved to understand if any type of  adjustment is necessary. This, furthermore, arise  early during the project life cycle.

Finally, the risk is lowered also because the product owner should prioritize the product backlog, keeping as the most important features, those who have the major risk rate.

Stay tuned!

A successful and sustainable way to manage projects

What if a project management methodology will offer the possibility to be more efficient in conducing projects and, in the meanwhile cutting off paper, energy and time consumption?

---

This is a tough era for a project manager.

Customers ask for better products, having less time available and with tight budgets.

The latest researches in terms of projects success (Standish Group, CHAOS Report 2009), shows that there’s a high percentage of projects that continue to fail (24%) and another 44% that are challenged. In other words: the customer expectations not ever (almost never) satisfied.

The main problems of those bad projects results, can be summarized as follows:

• Ineffective gathering requirements analysis (ambiguous or missing requirements, misunderstandigs, etc.)
• Bad requirements prioritization
• Continuous scope changes
• Lack of customer engagement and relative feedback
• Late deliveries and slow time to market

Why not considering agile as a possible answer? Yes, of course, agile!

Do you remember the agile manifesto?

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Main advantages:

1. The iterative and prototyping approach lets you to figure out, in advance, if the requirements you collected, are well understood and implemented; that aims to a general risks reduction.
2. Thanks to a well structured approach in prioritizing the customer/user necessities, avoiding of low/unuseful features implementation.
3. Thanks to a closely customer engagement, the feedback loop is reduced consistently.
4. Thanks to short deliveries and prioritization of the features, the customer is able to gather faster business results and ROI.
5. Thanks to short communication’s lines, team members co-location, free project’s information accessibility, the misunderstandings between the several stakeholders, are greatly reduced.
6. The scrum time-box approach, allows the members to be more focused and committed, not wasting time for ineffective meetings.
7. The short feedback loop gives an immediate evidence of problems and bugs, heavily reducing the reworking activities

Furthermore.

Take a moment considering that the optimizations derived from the points above, will aim to:

• reduction of the possibility of errors and consequent reworking (saving time and money)
• reduction of the compiled documentation (saving time, money and avoiding paper and ink consumption)
• reduction of sunk costs (cost deriving from meeting, travels, communication costs, etc.)

Can you evaluate what quantity of carbon monoxide won’t be produced?

Think green, be agile!

Agile PMI Certification: News

Qualche news dopo la visione del webcast della presentazione del lancio della nuova certificazione e di qualche ricerca su internet.

---

 

Oggi ho assistito al Webcast di presentazione della nuova certificazione agile del PMI, che si era tenuto il 17/3 e al quale non avevo potuto paretecipare.

Sembrerebbe che il PMI stesse seguendo con interesse l’evoluzione delle discipline agili, da almeno due anni (marzo 2009) e che nel marzo 2010 abbia deciso di lavorare alla nuova certificazione professionale.

Durante la presentazione, sono state riassunte le informazioni base di cui ho già scritto in questi post (Il PMI e la nuova certificazione “agile” e Agile PM Certification Suggested Books). 

Nella presentazione sono citate le seguenti metodologie come appartenenti alle discipline agili: scrum , xp , kanban , fdd e dsdm.

L’interesse del PMI per la tematica, è risultato evidente soprattutto nel modo in cui è stato rimarcato il messaggio che il PMBOK non debba essere pensato come alla “vecchia metodologia” di conduzione dei progetti.

Esso, invece, rappresenterebbe la cassetta degli attrezzi a dispodizione del project manager:  il “cosa fare“; mentre le discipline agili il “come farlo“. Strumento (PMBOK) e processo di implementazione (Agile).

Papers

Curiosando qua e là nella rete, alla ricerca di qualche papers tra quelli segnalati, ho trovato qualcosa di interessante soprattutto su un paio di autori: Michelle Sliger e Mike Griffiths.

Ecco il risultato delle miei ricerche:

• Agile Project Management and the PMBOK® Guide by Michelle Sliger
  • 1^ Puntata http://tinyurl.com/ekb4p
  • 2^ Puntata http://tinyurl.com/k4n4n
  • 3^ Puntata http://tinyurl.com/f9uop
  • 4^ Puntata http://tinyurl.com/vvnjc
  • Presentazione http://140.99.29.241/images/uploads/PMBOKtoAgileMapping.pdf
• Selling Agile: How to get buy-in from your team, customers and managers by Michelle Sliger
  • http://140.99.29.241/images/uploads/WhitePaper_SellingAgile.pdf
• Development Projects by Mike Griffiths
  • http://leadinganswers.typepad.com/leading_answers/files/developments_in_agile_project_management_mike_griffiths.pdf

Ah, dimenticavo. Per chi volesse seguire il tema su Twitter ecco il tag di riferimento: #pmiagilecert.

Stay tuned!

SCRUM? Proviamo per 30 giorni a tornare bambini!

Come imparano i bambini? E se Scrum vi offrisse di tornare bambini per trenta giorni? Accettereste di provarlo?

---

Come fanno i bimbi ad apprendere così velocemente e con tanto entusiasmo? Beh, partono avvantaggiati, molto avvantaggiati.

Innanzittutto non conoscono pregiudizio. Nessuna sovrastruttura mentale che li condizioni nella loro esplorazione: solo tanta voglia di capire cosa gli stia intorno.

Poi fanno largo uso di una tecnica efficacissima: sperimentano il mondo e la sua complessità, semplicemente attraverso l’uso dei propri diretti sensori: i cinque sensi.

Ed eccoli lì a toccare tutto, prese della corrente comprese, con mani e piedi. Li troverete sempre con in bocca qualcosa (la peggiore), intenti ad assaporarne il gusto, oppure a fissare sbalorditi la coda del vostro gatto che incessantemente si muove ritmicamente al suono del pendolo appeso alla parete.

Questo tipo di esplorazione ha l’enorme pregio di giovarsi di un ciclo di feedback estremamente corto. Tra la sperimentazione e il risultato, tra l’ispezione e l’eventuale adattamento, passano pochi attimi.

Subito saranno in grado di comprendere se la sperimentazione fatta, possa e debba essere ripetuta. In caso affermativo, al prossimo giro, saranno in grado di applicarvi un adattamento capace di far evolvere il loro modo di ”essere” in rapporto a quella esperienza.

Fantastico, chi di voi ha figli, riscopre giornalmente quella magia

Bene. Cosa centra tutto questo con Scrum?

Scrum si basa su un approccio alla gestione dei progetti, di tipo empirico  basato su tre pilastri fondmentali: trasparenza, ispezione e adattamento.

La trasparenza. Nei rapporti, nei comportamenti, nel mostrare il lavoro fatto e nello scegliere e ‘accettare quello ancora da fare, nel reperire e interpretare le informazioni; insomma, nel permettere alla realtà di emergere, per come è “realmente”.

L’ispezione. In quel contesto di trasparenza, l’ispezione è il miglior modo per esplorare la complessità del mondo e capire se il tipo di approccio da noi utilizzato è quello corretto.

L’adattamento. Risultato “automatico”, obbligato, quasi imposto e forzato dalla stessa esperienza dell’ispezione. Ci permetterà, senza ombra di dubbio alcuno, di scartare ciò che non ha funzionato e reiterare e migliorare nella sua applicazione, ciò che ha funzionato.

E finalmente arriva quello che considero il vero collante di Scrum, nonché il suo valore più alto: il corto ciclo di feedback “impostoci” dalla sua organizzazione “time-boxed” del tempo.

Lo sprint: massimo trenta giorni di lavoro per fornire risultati veri, tangibili, verificabili da tutti! Membri del team, ScrumMaster, ProductOwner, management, committenti.

I daily scrum meeting: quindici minuti per raccontare cosa ho fatto ieri, cosa farò oggi e quali sono gli impedimenti che ho trovato. Quindi minuti appunto, non uno di più, per raccontare agli altri la tua esperienza e ascoltare e percepire quella degli altri. Farla tua.

Hai poco tempo, lo devi sfruttare al meglio per fornire agli altri le informazioni più importanti, condividerne l’esperienza: non più ego-centrici ma team-centrici.

Il planning meeeting. Una giornata di analisi, non di più. Il team deve scegliere dal product backlog, cosa implementare nel prossimo sprint e decidere come farlo. Non c’è tempo per i dettagli, per stime accurate, ti devi fidare di te, della tua esperienza, del gruppo.

Il review meeting. Mezza giornata in cui il team mostra cosa ha fatto, in piena trasparenza. Funzionalità realizzate e non, cosa ha funzionato e cosa no. Anche qui la realtà deve emergere, gli stakeholders coinvolti devono capire quale è la realtà dei fatti (sia in positivo sia in in negativo) perché anche per loro si metterà in moto il processo di adattamento. In base ai risultati raggiunti, alla velocità e alle performance dimostrate, alla visione “dal vivo” e “in anteprima” delle funzionalità, modelleranno nuove aspettative che si concretizzeranno per voi, in una revisione tangibile del product backlog.

Il retrospective meeting. Momento fondamentale di revisione del lavoro svolto: cosa ha funzionato? cosa invece no? cosa potrebbe essere migliorato? I giapponesi chiamano questo processo con una sola parola “Kaizen“. Noi lo chiamiamo miglioramento continuo.

Ken Schwaber, in uno dei suoi libri, ci racconta che in progetti SW complessi, permettere alla trasparenza di emergere, è piuttosto difficile. Pensate infatti ad un team di sette persone, in cui quattro sviluppano, due effettuano test e l’ultima scrive la documentazione. E’ impensabile permettere ad ognuno di loro di conoscere cosa stia facendo il collega affianco; e anche il daily scrum non permetterebbe loro di fare piena esperienza, delle esperienze degli altri.

E’ per questo che in quei casi ci può venire in aiuto la metodologia XP Programming e alcune sue specifiche tecniche, che permettono l’emersione della realtà in maniera automatica, costante e giornaliera. Quali sono queste tecniche?

• Integrazione continua del codice e build giornaliere: faranno emergere subito eventuali problemi e, quando invece le cose vanno bene, permetteranno ad altri membri del team di usufruire immediatamente del lavoro fatto dai colleghi.
• Test-driven development: scrittura dei test anticipatamente allo sviluppo del codice. Permette di verificare al termine della codifica di una routine, se quanto scritto è corretto.
• Pair programming: lavoro congiunto sullo stesso codice, da parte di due sviluppatori. Quattro mani, quattro occhi, due cervelli.
• Collective code ownership: ogni membro del team accede ed è responsabile di tutto il codice. Lo usa, modifica, visiona in piena libertà.

Allora? Torniamo bimbi per trenta giorni?

Beh, ora vi lascio… anche se mi è venuto in mente giusto ora, un parallelismo tra Scrum e Zen.

Si, ok, ho capito. Per stasera ve lo risparmio!

Agile PM Certification Suggested Books

Ecco i primi libri e papers suggeriti dal PMI per chi guarda alla certificazione Agile PM (vedi anche post precedenti: post1 e post2).

Papers (acquistabili per circa 15 dollari dal marketplace di PMI.org):

• Agile Project Management and the PMBOK® Guide by Michelle Sliger
• Agile PMP®: Managing software projects in the face of uncertainty by Mike Cottmeyer
• Challenges in Implementing Agile Project Management by Jesse Fewell
• Looking for an Edge by Jesse Fewell
• Selling Agile: How to get buy-in from your team, customers and managers by Michelle Sliger
• Utilizing Agile Principles Alongside the PMBOK® Guide for Better Project Execution and Control in Software
• Development Projects by Mike Griffiths

Libri:

• Agile Project Management by Jim Highsmith
• Effective Project Management: Traditional, Agile, Extreme by Robert K. Wysocki
• Project Management the Agile Way by John C. Goodpasture, PMP
• The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
• Running an Agile Software Development Project by Mike Holcombe
• Managing Agile Projects, First Edition by Kevin Aguanno, editor
• Agile Project Management: How to succeed in the face of changing project requirements by Gary Chin
• Agile Project Management with Scrum by Ken Schwaber

La lista sopra non è ancora quella ufficiale di riferimento per lo studio, ma essendo comunque fornita dal PMI credo non sarà molto diversa.

Io sono partito acquistando l’eBook dell’ultimo libro dell’elenco sopra (Agile Project Management with Scrum di Schwaber), perché consigliato anche da Simon Bennet, il trainer del corso Scrum a cui ho partecipato.

Buon libro. Approfondisce le tematiche Scrum con molti esempi sul campo e, cosa ancor più a valore aggiunto, cerca di tracciare legami tra le modalità di conduzione e rappresentazione di progetti standard con progetti agili (in questo caso Scrum appunto).

Per chi infine fosse interessato a seguire su Twitter la tematica, ecco il tag di riferimento: #PMIAgileCert

Nice morning!

Il vero valore di una certificazione professionale

Sull’onda del precedente post, ecco alcuni pensieri in libertà sul valore effettivo delle certificazioni.

---

Già nel “lontano” 1999, quando presi la mia prima certificazione (Microsoft Certified Professional in SQLServer), alcuni dei miei colleghi/amici mi prendevano in giro, dicendomi che stavo sprecando il mio tempo.

Sostenevano infatti che nel concreto mondo del lavoro, conta cosa effettivamente sai fare, rispetto a cosa dici di saper fare, semplicemente perché avevi superato con successo un esame.

Sottile, ma significativa differenza.

A quei tempi ero, e lo sono tuttora, d’accordo con quei colleghi. Cercavo però di spiegare loro, che io quel determinato prodotto (SQLServer, allora) o quella particolare disciplina (SCRUM piuttosto che PMP, oggi), l’avrei studiata comunque, tanto valeva “agganciarci” la certificazione.

Una questione di puro pragmatismo, insomma.

Oggi però le certificazioni si moltiplicano. Ed ecco che noi, poveri professionisti, ci affanniamo nel capire inanzitutto dove il mercato stia andando (Agile PM? SCRUM? Kanban? SCRUMban? Lean?) per poi decidere se provare o meno la certificazione in quella direzione.

Ed ecco che, anche in queste situazioni, un pò di sano project management applicato alle certificazioni, potrebbe aiutarci:

• Quanto tempo dovremo dedicare ad ognuna?
• Quanto costerà preparaci e perseguirla (libri, corsi, esame, eventuali viaggi)?
• Quali sono i rischi di non riuscirci?
• E quali invece, i nuovi positivi scenari (ROI) o opportunità, che si potrebbero dispiegare davanti a noi?

Attenzione. Potremmo cadere nell’errore di valutare quest’ultimo punto, solo in termini economici.

Il ROI che ne ricaveremmo dalla singola certificazione, lo penserei invece come ad  un insieme di singole componenti appartenenti a due aree specifiche: sfera personale e sfera lavorativa.

Sfera personale:

• Ampliamento esperienza cognitiva derivante dallo studio e dall’apprendimento
• Aumento indiretto dell’autostima
• Aumento delle possibilità di networking

Sfera lavorativa:

• Data la possibilità di praticare organicamente la disciplina, riusciremo a meglio dimostrare il nostro valore sul campo
• Riconoscimento oggettivo della professionalità, derivante dal titolo della certificazione stessa
• Vantaggio competitivo sul mercato

In generale possiamo dire che la semplice esperienza della certificazione, se ben vissuta, potebbe valorizzarci contemporaneamente come persone e come professionisti. Questo, di fatto, ci aprirà “abbastanza“ automaticamente nuove possibilità lavorative.

Ecco spiegata la mia passione, innanzitutto per il project management e poi, perché no, per le certificazioni in quel campo!

—

PS: Quell’abbastanza sopra riportato è virgolettato perché, in un contesto lavorativo in cui la meritocrazia è uno dei pilastri portanti per l’avanzamento di carriera, sarebbe un automatismo e quella parola completamente da eliminare.

E in Italia? Beh, lasciamo perdere

Il PMI e la nuova certificazione “agile”

Qualche giorno fà ho ricevuto una email dal PMI, nella quale l’organizzazione avvertiva la comunità che è in procinto di lanciare una nuova e interessantissima certificazione.

---

Di cosa si tratta? Si tratta di una certificazione riguardante le discipline agili applicate al project management.

Le principali motivazioni che hanno convinto il PMI a prendere la decisione, derivano dalle seguenti considerazioni:

• I prinicipi “agili” sono ormai già ampliamente applicati alla gestione dei progetti.
• Le aziende stanno di fatto già richiedendo ai pm, conoscenze agili per il rilascio veloce dei prodotti.

Viene da chiedersi se non se ne siano accorti un pò in ritardo: un’organizzazione di quel tipo non dovrebbe essere proattiva piuttosto che reattiva?

Beh, sia come sia. Questa rimane comunque una notizia molto interessante.

Premesso che personalmente considero come vero valore di una certificazione, certamente non la spilletta “certified” da attaccarsi alla giacca, quanto invece l’esperienza (studio e pratica) fatta per ottenerla, vediamo un pò più in dettaglio di cosa si tratta .

Nella mail raccontano che la questione è ancora in fase di organizzazione. In questi giorni, infatti, stanno ricercando un primo set di persone disponibili a formare il gruppo pilota che fungerà da “beta-tester” sull’intero processo di certificazione (interessati? Segnalatelo a AgilePilot@PMI.org).

Sempre nell’email è riportato un link  ad una pagina del sito, in cui sono spiegati alcuni importanti dettagli per l’ottenimento della certificazione, che cerco di riassumere brevemente qui di seguito:

• E’ necessario dimostrare di avere sulle spalle almeno 2000 ore negli ultimi 5 anni di “General Project Management Experience” (se siete già PMP certificati, questo requisito è già soddisfatto)
•  E’ necessario dimostrare di avere sulle spalle almeno 1500 ore dedicate negli ultimi 2 anni di “Agile Project Management Experience“
• E’ necessario totalizzare un minimo di 21 ore di formazione specifiche sulle discipline agili di pm

Una volta soddisfatti i requisiti sopra, ci sarà da sottomettere la solita lettera di candidatura con tutti i dettagli del caso.

All’accettazione della candidatura potremo procedere al pagamento (circa 400 dollari) e alla prenotazione dell’esame. Esame che conterà 120 domande da evadere in tre ore.

Sembra che il tutto sarà attivo a partire dal 4 trimestre di quest’anno, ma prendetelo con le pinze. Anche nome e sigla ufficiali della certificazione, verranno comunicati in quel periodo.

Bene, ma quale sarebbe il valore aggiunto di questa ennesima certificazione?

1. Imparare di più rispetto a: scrum, xp, crystal, dsdm, fdd.
2. Dimostrare competenza a chi ci assume/incarica.
3. Aumento della versatilità professionale all’uso di tecniche applicate al pm.

 Vi basta? A me, si