Force Field Analysis: an Agile Version

Everytime we learn something new, a practice, a tool or a technique related to our working activity, we naturally try to understand how that knowledge can be ported into our environment. It happens, indeed, that the most challenging things, even if fascinating and powerful, are often discarded with a superficial statement “it will never work with us”.

Everyone of us do not want to change their habits, do not want to leave their “lovely” comfort-zone, we are accustomed to it, it is familiar.
Even if we know that the old way of doing things doesn’t work anymore and we must change it, we want to approach to it smoothly, gradually, it would be better, indeed, if someone else will do it for us.

This happens every time to people that come from a traditional project management environment who are called to face the new agile discipline: most of the time they know very well the benefits of it, what kind of improvement it can bring and furthermore they know that agile is, above all, about changing their mindsets, their habits.

Initially, they make the error of thinking that agile is primarily a matter of using the right techniques and tools; they start to ask about which tool is better to manage the product backlog, which other tool can be used to write and decompose the user stories or, yet, what tool can be used to manage the task board in an electronic way.

Even in these cases, don’t give up!

Continue to explain the value of managing the user stories with index cards (face-to-face communication, direct negotiation, establishing a sense of trust with the customer), furthermore, that attaching and moving the tasks directly on the taskboard, during the daily meeting, is a ceremony, a moment where the team continue to learn about the project, the product, the other team members.
And, again, go on stressing the fact that the product backlog grooming activity is an important one, which must be done together with the product owner: directly, face-to-face.
What is paramount, in my opinion, is that the team and the other stakeholders, should really and honestly understand that agile is mainly a matter of collaboration and short-feedback and that is better to avoid the use of any remote and asynchronous communication tool, except for particular situations (distributed teams, maybe?).

When they realize that doing agile means, primarily, to change theirselves and how they did things so far, lot of doubts raise and even the better, the more detailed and the more honest explanation, is not able to convice them 100%,

That could be the time to use the Force Field Analysis tool, with some little adjustments to make it funnier.

First of all I ask a representative of the team, better if s/he is the most skeptical, to come at the whiteboard.
Then I ask the whole team to think at the agile transition as a journey, navigating the sea by boat (representing SCRUM) where the team is represented by the sail.
Actually what I ask to the member, is to draw the sea, the boat, the sail and to write on the hull of the boat the name of the agile discipline and on the sail the the name of the team.

Now it’s time for the team to elicit what advantages, benefits, strengths, agile embodies, which they can bring to their workplace, identifying them as the airstreams blowing into the sail, able to push the boat from the start to the finish-line.
These air flows shall be written and drawn on the top left area of the whiteboard (sky).

Then, I ask them to list the drawbacks and the weaknesses of implementing agile in their organization.
These are the contrary forces that work under the hull of the boat as marine drifts; those must be reported on the right bottom area of the whiteboard (sea).

Having this information written on the whiteboard, in front of them, help primarily to find any new advantage or drawback not already written but, more important, allow the team to compare the two groups and really understand how to cope with them.

The final part of the “game” is, to think how to exploit any single strength (opportunity) and for each drawback how to smooth, adjust, avoid or even accept it (risk), in order to let the boat reach the new land of agile where better results are awaiting for them.

Someone could ask: why cannot continue the old way of representing the force field analysis? The one that uses the tabular representation of it?
An explanation is that using metaphores (the journey, the sea, the boat, etc.) help people to better explain their feelings, abstracting from the reality and finally helps the brain in the process of memorization of concepts, emotions and ideas.

Be the the new year, an inspiring one! (AJRX49CFX279)

Risks Identification

Quanto ci possono aiutare sessioni mirate di brainstorming per l’identificazione e esplorazione dei rischi?
Come utilizzare le tecnica Six Thinking Hats di De Bono allo scopo?

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

PMI Emea Global Congress – 1st day

Oggi ho partecipato alla prima giornata del cogresso EMEA del PMI a Milano.

Un evento che aspettavo da alcune settimane con impazienza, curioso di respirare “dal vivo” l’aria pura del project managemet.

L’evento è stato organizzato presso il “Milano Convention Centre” di via Gattameleta, zona vecchia fiera, in una cornice estremamente professionale, accompagnata da un’organizzazione  sin da subito impeccabile.

Munito di badge di riconoscimento e relativo cordoncino io e il mio collega e amico Massimiliano, ci siamo recati al primo dei nostri incontri giornalieri.

Alle dieci erano previsti due diversi incontri organizzati da altrettanti sponsor: Siemens e Oracle.

Il secondo ci ha attirato maggiormente “Benefits of Risk Analyis” e li, ci siamo fiondati.

Un senior product manager di Primavera, di Oracle appunto, ci ha condotto attraverso i basics della risk analysis, snocciolando e approfondendo le tematiche costituenti e creando gli opportuni parallelismi con il loro software di project management.

Ci ha parlato di quanto vincoli e assunti (constraints and assumptions) sia possibile e necessario che diventino eventi, milestones all’interno del nostro reticolato di progetto ai quali poter associare date di accadimento e punti di arrivo di attività precedenti.

Di come creare un risk register, associare per ogni rischio le probabilità di accadimento e una percentuale di impatto su uno o più vincoli di progetto (tempi, costi, qualità, scope), di come associarne quindi una priorità ed un valore; di come poi poter agire in caso di assessment del rischio, mettendo a disposizione soldi per la sua gestione.

Di come ogni singolo rischio definito nel registro sia possibile, doveroso, collegarlo alle attività del reticolato.

Di come sia necessario, obbligatorio, per ogni attività procedere alla sua valutazione in termini di valori Probabile, Ottimistico, Pessimistico.

Di come sia essenziale lavorare sullo schedule attraverso la review dei rischi, ricalcolando l’intero impatto.

Ecco che semplicemente valorizzando lo strumento con un insieme di informazioni “probabili”, il sistema può cominciare a fornire indicazioni tridimensionali: Best case, most likely and worst case.

Non più un solo gantt con la solita e unica stima (spesso over-contingentata), ma un gantt in cui ogni barra di ogni singola attività è in grado di mostrare le tre durate e calcolare le successive in riferimento a queste.

Per finire, abbiamo potuto vedere alcune simulazioni MonteCarlo di impatto dei rischi di un progetto, sui tempi costi e poterne studiare le varianze ipotizzate.

Interessante, sembrava però la presentazione di un prodotto più che una sessione di project management.

Poi è arrivato il momento di John Kao, il personaggio che avrebbe aperto ufficialmente il congresso con il suo intervento dedicato all’innovazione.

Ecco parte della sua biografia riportata nei volantini del PMI:

John Kao is an authority on the intersecting subjects of corporate innovation and transformation, design and the future of business. Dubbed a “serial innovator” and “Mr. Creativity” by The Economist, he has made a career out of helping organisations go from “getting” the importance of innovation to “getting innovation done.” John has worked with a wide range of Fortune 500 companies, startups and government agencies around practical issues of strategic innovation and organisational transformation. Other nicknames he acquired from his clients include “the Innovation Sherpa” and “the Innovation Guru.”

Un intervento interessantissimo, condotto da un personaggio interessante, un visionario, che ci ha spiegato cosa è l’innovazione, quando è possibile trovarla e come creare le condizioni perché questa si manifesti.

Per poi terminare con la sessione “How to Be a Successful Failure” di David Hillson, un personaggio di “peso”, uno tra i maggiori esperti della comunità in quanto a risk management.

Il relatore ha iniziato spiegando quanto successo e fallimento siano, ovviamente direte voi, l’uno l’opposto dell’altro; quando cioé finisce  il primo comincia l’altro e così via, richiamando il concetto di Yin e Yang molto caro agli orientali.

 Ha rimarcato che quando una situazione o un progetto ricade nel fallimento, è solo attraverso la riflessione, l’apprendimento e la persistenza che possiamo riportarlo al successo.

E solo attraverso l’innovazione legata a quanto appreso e il consolidamento di questo nuovo sapere che possiamo permettere al successo di durare. Durare, però, solo sino al momento in cui, vi sarà un cambio delle condizioni attuali. Questo cambio ci metterà nelle condizioni di dover mettere da parte il sapere consolidato a favore della sperimentazione.

Sperimentazione che a causa della sua incerta natura, ci porterà inevitabilmente al prossimo fallimento. E via, si ricomincia.

Ci ha raccontato di quanto poco offra il successo in termini di evoluzione personale in quanto pochi di noi in caso di successo hanno voglia di inventasi nulla (squadra che vince non si cambia) o di sperimentare novità.

Invece il fallimento nasconde opportunità, possibilità di apprendimento e di crescita, ci indica una direzione, in poche parole ci fornisce stimoli nuovi e di sicuro interesse.

Occore ovviamente essere preparati: una buona predisposizione mentale, lavorare il più possibile al fine di minimizzare le possibilità di rischio (risk analysis) e massimizzare il valore del fallimento, qualora esso accada, perché è solo agendo su questo valore che possiamo trarne l’insegnamento che permetta il cambiamento necessario per passare al prossimo successo!

Ed infine eccomi qui, un pò “macinato” ma soddisfatto dell’intensa giornata!

Risk Management Checklist

Riprendiamo un argomento fondamentale per favorire il successo del progetto: la gestione dei rischi. In un precedente post ho descritto un possibile approccio alla definzione dei rischi, in questo post cercherò di evidenziare aclune aree da indagare per abbatterli.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.